WinRT sockets provide a low-level socket interface for use with TCP and UDP sockets. The features are exposed in the
Windows.Networking.Sockets namespace. WinRT sockets also use classes in the
Windows.Networking namespace to provide access to managed
EndPoint classes. WinRT sockets are needed if other higher-level WinRT networking APIs (web access, Atompub, JSON, and background HTTP/FTP transfer) don't meet the requirements of your app. WinRT sockets are the building blocks a developer can use to build apps that use TCP or UDP protocols to access services or peers. Some typical examples might be Voice over IP (VoIP), instant messaging, mail clients (IMAP, POP, SMTP), and database clients. A very simple example using sockets might be an app that sends status messages to an SMTP server or an app that logs status to a SYSLOG server.
The WinRT API for sockets provides a simple API for sockets programming with three primary classes:
StreamSocket: A TCP stream socket.
DatagramSocket: A UDP datagram socket.
StreamSocketListener: A listener for incoming network connections using a TCP stream socket.
DatagramSocket classes implement the core TCP and UDP sockets. The
StreamSocketListener class is a helper class that implements a TCP listener. Once a connection request is received and accepted, a
StreamSocket object is created.
Associated with each of these classes are related
Information classes that provide socket control data and information for each of the primary classes. All WinRT socket methods are designed to be asynchronous and not block the UI thread. They even have
Async appended in the method name to make this clear.
Developers should be aware of some limitations placed on Windows Store Apps using sockets in Windows 8:
- TCP and UDP sockets are supported. Raw sockets and other types of sockets are not supported. So, for example, you can't write a ping tool that needs access to ICMP or ICMPv6.
- Sandboxing prevents a Windows Store app that uses sockets from accessing IPv4 or IPv6 loopback addresses on the device. This limitation is removed for apps running under the Windows debugger in Visual Studio to allow testing of client/server apps on the same device.
StreamSocketclass has built-in support for SSL for client apps, but not for servers. It would be much more difficult to implement a TCP server that uses SSL because the app would need to implement all the SSL protocols.
- When a networking app using WinRT sockets loses focus, the app can't continue to send or receive packets. There are some special features (
Windows.Networking.Sockets.ControlChannelTrigger) that can be used to support background networking with a
StreamSocket, but they are complex.
Windows Store Apps and Lifetimes
There are some important implications when developing apps using WinRT. Each Windows Store app is run in sandbox by the OS for security and protection. This prevents a rogue app from accessing data or information from another app except through controlled mechanisms that require approval of the apps. The sandbox prevents apps from sharing sockets.
Windows Store apps must declare in a manifest what capabilities they plan to use. Several of these capabilities deal specifically with network access (Internet client, Internet client/server, or Intranet client/server). When the app is installed, the user must approve the use of these capabilities.
Windows Store apps operate under a very different app lifecycle model than Windows 8 desktop apps (and applications on Windows 7 and earlier). When a Windows Store app loses focus (that is, gets dragged away from the foreground and replaced by another app), the app is not multitasked as on previous versions of Windows. The app doesn't get any more CPU cycles and may be purged from memory. Before the OS switches to the new app, the existing app gets notified and has a short time to save state before it is cut off from further execution. Many network operations often take time to complete. So this app lifecycle model for Windows Store apps has important implications for the design and implementation of network apps. Also, when used on mobile devices, network connectivity may be lost. Caching network content becomes an important feature to include.
High Performance Winsock and Registered I/O
At the other end of the Winsock continuum, Windows 8 and Windows Server 2012 introduced new APIs for Winsock registered I/O (RIO) extensions. These APIs, which are usable only by desktop apps, are a set of Winsock extensions designed to lower latency and jitter and improve the network performance of network servers. While these APIs can be used by both clients and servers, network performance improvements, when compared with using traditional Winsock APIs, are likely to occur only on heavily-loaded network servers. The greatest improvements would be on servers that handle a large number of small network packets (~1K), which is typical of database servers and some applications used in the financial services industries.
The goal of Winsock and network stacks on other operating systems has always been to minimize data copying. For sends and receives, the regular Winsock APIs and the core TCP/IP stack use network buffers that must be pinned and unpinned by the system. The OS management of these buffers used by Winsock requires CPU cycles and user-mode to kernel-mode transitions to lock and unlock the buffers in memory. There are also CPU cycles associated with the methods used for I/O completion.