Datagram Socket Communication in Windows Phone 8


New to Windows Phone 8 is the Windows.Networking.Sockets namespace. This namespace is also used in the Windows Store app development environment, which makes it convenient for developers who wish to port networking applications to both targets. 

Windows.Networking.Sockets is the replacement for the older System.Net.Sockets namespace used in the Windows Phone 7 network model.  System.Net.Sockets is provided for Windows Phone 7 compatibility purposes and is not recommended for new Windows Phone 8 projects.

This blog includes a Windows Phone 8 sample sockets application, Datagram Demo.

Datagram Demo implements UDP Datagrams (Unicast and Multicast), and demonstrates direct phone-to-phone communication using WiFi.

Procedure

  1. Download and unzip the project file found at the end of this blog.
  2. Obtain two Windows Phone 8 devices. Compile and then deploy the sample application to both phones.
  3. Connect both phones to the same WiFi access point. The access point must support DHCP in order to automatically assign IP addresses to the phones.
  4. Launch the application on both phones.
  5. Touch the Multicast Inquire button on one phone, to discover other phones on the local WiFi access point, by transmitting a Multicast UDP packet (“WhoIsThere”).  All phones (including the inquiring phone) respond by sending a Unicast UDP packet (“AckHereIam”)  back to the phone that made the inquiry. The inquiring phone will report the IP address of each received AckHereIam packet to the main screen of the app.
  6. The user can then choose and tap an IP address on the screen in order to communicate with that phone.
  7. A second screen appears, “Communication Log”.  Touch the Ping button. This will send a Unicast UDP packet (“Ping”) message to the chosen phone. The chosen phone will receive that message and respond by sending a unicast UDP Packet (“Pong”) back to the inquiring phone that originated the communication.

Responses from a multicast inquiry may include packets from seemingly unexpected sources.

If you run the app in the emulator, a multicast inquiry will return multiple devices. In fact the responses come from the same emulator instance. The emulator has more than one IP address assigned to it. An IPaddress of 127.0.0.1 is the local loopback (local host) address of the PC. An IP address starting with 169.254… is a Link-Local address. The app filters out those addresses. If you wish to see all the addresses you may comment out the filtering code.

If you run the app in a real phone, the IP addresses of interest typically begin with 192.168… on a standard WiFi network. However if your phone is connected to your mobile cellular service, on your inquiry screen you may also see an IP address corresponding to the cellular service. The IP address may begin with 10.  That address does not appear to be useful for multicast inquiries.

UDP or TCP?

This sample demonstrates User Datagram Protocol (UDP) sockets. UDP has no built-in handshaking dialogs to guarantee packet delivery, which means that it is up to you, the developer to accommodate any unreliability in the network.  Nor does it guarantee the order in which packets are received.

When using UDP socket connections, consider including your own mechanisms to properly order packets and retry sending packets etc. as needed, depending on your particular scenario and reliability requirements of your application.

You can leverage Transmission Control Protocol (TCP) to automatically provide reliable and correctly ordered delivery of a stream of data.  Since only UDP supports multicasting, you can use UDP initially in order to discover other devices or computers to communicate with, and then establish a TCP connection using the StreamSocket and StreamSocketListener classes.

Some earlier phone brands did not properly detect multicast packets. If you find that multicasting is not working in a specific physical phone device, make sure the phone has the latest operating system version.  

You can update the phone via Settings->system->phone update.

Happy networking!

--Mark

 

Additional resources

Sockets for Windows Phone

Code Project: DNS resolving and Parsing IP Address in Metro Style Applications(WinRT)

MSDN: How to detect network changes for Windows Phone

MSDN: How to get connection information about a socket for Windows Phone

Wikipedia: User_Datagram_Protocol

Channel 9: Building Apps for Windows Phone 8 Jump Start: (11) Network Communication

MSDN Developer Code Samples (Phone + networking)

 

Follow us on Twitter @wsdevsol!

DatagramSocket.zip

Comments (5)

  1. P.Padiyar says:

    Hi Mark,

    We are working on a multicast application on Windows RT using DataGramSockets.

    We have a necessity to re-use the same port shared across other applications.

    I see that, the option that we have in Windows desktop , i.e. SO_REUSEADDR is not available in Win-RT.

    Is there a way to enable port sharing in DataGramSocket?

    The ‘BindEndointAsync()’ does not succeed if I am trying to bind to an already bound port.

  2. Hi, for Windows Store apps it appears the answer is no, and WP8, if anything is generally even more restrictive. More info:

    social.msdn.microsoft.com/…/2e4cc209-843c-484e-982f-d434d663eca0

    -Mark

  3. My question isn't really related to the your demonstration of DataGramSocket, but is more related to thread safety around your sample. I'm really just learning to get into asynchronous programming these days. And obviously all the API's, and usage models we're dealing with nowadays are really pushing further in this direction. One of the things I find myself wondering is how much I need to worry about thread safety around operations to things like a DataGramSocket. As an example, I've seen your code create a new DataGramSocket on page load, assign your callback to receive messages, etc. And I've also seen your TearDownSockets routine to dispose and null out your DataGramSocket. One thing I notice is no where are you locking around these actions.

    Is there a reason I should not be worried of the potential that an incoming message could result in the triggering of my message callback, at the same time that I might be disposing and nulling out my DataGramSocket in something like a TearDownSockets method? My gut feeling is to lock these types of code sections, and provide checks for null to ensure I don't end up with a null reference exception. Yet, in all the code samples I seem to find around asynchronous programming with sockets these days, I don't see any of this being done. (Your sample being just one of many…)

  4. Mike says:

    You don't mention how to add the windows.networking namespace – I simoly can't find it anywhere  when I go to add the reference…. Where is it?  And if its not a standard one can I suggest you mention this – believe me, it's not always obvious to everyone!

  5. Naveen says:

    Hi Mark,

    I downloaded your sample, built the source and deployed it on a Lumia 620 and Lumia 820 (Nokia developer Phone).

    Both have their OS updated to 8.0.10517.150.

    However, when I run the app by connecting to same Wi-Fi access point and follow the steps as you mentioned in your Procedure, the apps don't display any other IP than its own.

    Can you help us out? I want to do a multicast for my game to support multiplayer and I was looking how to achieve this.

    I haven't been able to find one which works on Phones yet.

    Thanks for your help.

Skip to main content