4,391 Posts served

10,712 Conversations started

Local network discovery done correctly

By Ylian Saint-hilaire (Intel) (246 posts) on December 8, 2009 at 8:59 am

I am currently working on two projects, the Mesh and the Developer Tools for UPnP Technologies. In both cases, they rely on local network discovery. basically you want to multicast that you are looking for something and get unicast responses back from nodes that match the query. Well, may sound simple but there is a few things I learned in the process of building discovery software.

IPv4 and IPv6

First, when it comes to local discovery, IPv6 is a big improvement over IPv4. Users don't have to have an IPv6 internet connection to benefit, in fact, Microsoft Vista and Windows 7 both use plenty of IPv6 network discovery for finding other computers, share drives, printers, etc. Users don't realize it but most home network have lots of IPv6 packets running on them today. What makes IPv6 better is "Link local" addresses. Basically, you take a MAC address and put it into your IPv6 address and you got yourself an IP address you can use immediately. Just plug two computers together with a network cable and discovery is reliable and instant. By the way, with gigabit Ethernet there is no longer any need for cross-over cables (in fact they slow you back down to 100mb/sec). With IPv6, you plug and it works.

Multicast

Both my projects use multicast to send discovery messages. You should avoid using the older "broadcast" and just use the much better multicast which will reach across routers. Also, broadcast does not exist in IPv6 anymore, so no using it. One thing I have learned when implementing SSDP is to never ever send out any data using a multicast socket. In other words, once you created a socket and it joins the multicast group and starts receiving packets, don't ever use that socket to send any data at all. You have to create a separate socket, bind it to any port and use that for all outgoing packets (outgoing unicast or multicast). Now, why is that? Well, if you bind many applications to the same UDP port to receive data only received multicast packets will "multicasted" to all applications. An incoming unicast may be directed to only one of the applications.

So you have many applications bound to the SSDP port (UDP 1900) and each time the computer receives a multicast, all listening apps sharing the port get it. If the computer receives a unicast packet, only one app may get it, and it may not be your app. Since when you send out a multicast search the response is unicast. You want to make sure you sent the multicast on a socket you own outright so you get all the responses directed back to your app.

Conclusion

Network discovery is really useful. Makes applications just work better for the user. Probably the best way to build such an application is to download the Developer Tools for UPnP technologies and use the code generator to do all the work for you. The result are compact stacks that you can use to advertise network services or search and make use of them.

Ylian

Categories: Open Source
Tags: discovery, IPv6, Mesh, multicast, Open Source, ssdp, Tools, upnp, Ylian

For more complete information about compiler optimizations, see our Optimization Notice.

Comments (6)

December 8, 2009 10:44 AM PST Hansen

Tried to use your upnp discovery from a C# program and the mechnism seems to work well and find expected units. Simply using this command: scp = new UPnPSmartControlPoint(new UPnPSmartControlPoint.DeviceHandler(HandleAddedDevice)); But a few problems: 1) it uses almost 100% cpu (tried on two PC's) 2) I can't find a way to kill the discovery once first launched - only by closing the program! /h

December 8, 2009 10:53 PM PST Ylian Saint-hilaire (Intel) Total Points: 20,222 Black Belt

Hi. I have not seen that 100% CPU yet, but I will try to make it happen on my computer. Please let me know what OS you are using and if you are using 32 or 64 bit OS. As for discovery, UPnP will keep adding and removing devices as they show up on the network, discovery is not supported to stop. Of course, it is also not supposed to take 100% of the CPU. - Ylian

December 9, 2009 12:12 AM PST Ylian Saint-hilaire (Intel) Total Points: 20,222 Black Belt

Ok, I found the 100% CPU problem. In SSDP.cs you can add this second line: SSDP_EXPIRATION = Expiration; if (SSDP_EXPIRATION < 5) SSDP_EXPIRATION = 5; <---- Add this line int MinVal = (int)((double)SSDP_EXPIRATION * 0.25 * 1000); int MaxVal = (int)((double)SSDP_EXPIRATION * 0.45 * 1000); Right now, SSDP is just looping with an expiration of zero. I will send out a fix, probably tomorrow. - Ylian

December 9, 2009 1:08 AM PST Hansen

Thanks for the update. I did the change and it did bring the cpu load down to like 10-40% usage. (2ghz laptop with XP) Still belive a pause/stop feature would be good as not all network admins like a multicast mechanism running 24/7 in their network and some apps simply only need an initial discovery and then do it in intervals of hours. Just my 5 cents! /h

December 9, 2009 10:34 AM PST Ylian Saint-hilaire (Intel) Total Points: 20,222 Black Belt

Ok, I just updated the tools released on the web site. I am surprised you still get 10-40%... Can you open Device Sniffer and look, I am guessing you must have lots of SSDP traffic on your network.

January 9, 2010 1:23 PM PST wes

Hey Ylian I also get the near-100% CPU usage. I'll try adding that line you mentioned. It's so intense my cursor even lags! I'm running XP Pro SP3 32-bit, VS2008... and I have 2 UPnP servers constantly feeding to my PS3, so maybe it's traffic related =)

Trackbacks (0)

Leave a comment