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.
- Download and unzip the project file found at the end of this blog.
- Obtain two Windows Phone 8 devices. Compile and then deploy the sample application to both phones.
- 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.
- Launch the application on both phones.
- 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.
- The user can then choose and tap an IP address on the screen in order to communicate with that phone.
- 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.
Follow us on Twitter @wsdevsol!