MICROSOFT_PRESS_EBOOK_PROGRAMMING_WINDOWS_8_APPS_WITH_HTML_CSS_AND_JAVASCRIPT_PDF

Sockets are generally used when there isn’t a higher-level API or other abstraction for your particular
scenario, when there’s a custom protocol involved, when you need two-way communication, or when it
makes sense to minimize the overhead of each exchange. Consider HTTP, a protocol that is itself built
on lower-level sockets. A single HTTP request generally includes headers and lots of other information
beyond just the bit of data involved, so it’s an inefficient transport when you need to send lots of little
bits. It’s better to connect directly with the server and exchange data with a minimized custom protocol.
VoIP is another example where sockets work well, as are multicast scenarios like multiplayer games. In
the latter, one player’s machine, acting as a server within a local subnet, can broadcast a message to all
the other players, and vice versa, again with minimal overhead.
In the world of sockets, exchanging data can happen two ways: as discrete packets/messages (like
water balloons) or as a continuous stream (like water running through a hose). These are called
datagram and stream sockets, respectively, and both are supported through the WinRT API. WinRT also
supports both forms of exchange through the WebSocket protocol, a technology originally created for
web browsers and web servers that has become increasingly interesting for general purpose use within
apps. All of the applicable classes can be found in the Windows.Networking.Sockets API, as we’ll see in
the following sections. Note that because there is some overlap between the different types of sockets,
these sections are meant to be read in sequence so that I don’t have to repeat myself too much!
Datagram Sockets
In the language of sockets, a water balloon is called a datagram, a bundle of information sent from one
end of the socket to the other—even without a prior connection—according to the User Datagram
Protocol (UDP) standard. UDP, as I summarize here from its description on Wikipedia, is simple,
stateless, unidirectional, and transaction-oriented. It has minimal overhead and lacks retransmission
delays, and for these reasons it cannot guarantee that a datagram will actually be delivered. Thus, it’s
used where error checking and correction isn’t necessary or is done by the apps involved rather than at
the network interface level. In a VoIP scenario, for example, this allows data packets to just be dropped if
they cannot be delivered, rather than having everything involved wait for a delayed packet. As a result,
the quality of the audio might suffer, but it won’t start stuttering or make your friends and colleagues
sound like they’re from another galaxy. In short, UDP might be unreliable, but it minimizes latency.
Higher-level protocols like the Real-time Transport Protocol (RTP) and the Real Time Streaming Protocol
(RTSP) are built on UDP.
A Windows Store app works with this transport—either as a client or a server—using the
Windows.Networking.Sockets.DatagramSocket class, an object that you need to instantiate with the
new operator to set up a specific connection and listen for messages:
var listener = new Windows.Networking.Sockets.DatagramSocket();
On either side of the conversation, the next step is to listen for the object’s messagereceived event:
// Event from WinRT: remember to call removeEventListener as needed
listener.addEventListener("messagereceived", onMessageReceived);
676