.NET Networking APIs for UWP Apps

www.spiroprojects.com

System.Net.Sockets

With Windows 10 and .NET Core 5, System.Net.Sockets has been added into the API surface for UWP app developers. This was a highly requested API for Windows Store apps (it was already available for Windows Phone Silverlight apps) and includes types such as System.Net.Sockets.Socket and System.Net.Sockets.SocketAsyncEventArgs, which are used by developers for asynchronous socket communication. The current API surface of System.Net.Sockets in .NET Core is based on that of Phone 8.1 Silverlight and continues to support most of the types, properties and methods (some APIs that are considered obsolete have been removed). Moving forward, we plan to expand the API surface to support more types from this namespace – please see the Looking ahead section below.

The implementation underneath the System.Net.Sockets API has been significantly changed to eliminate dependencies on APIs that are not part of .NET Core, as well as to use the same underlying threading APIs as other WinRT APIs. Our goal is to ensure functional parity between the previous implementation and the new .NET Core version. Please send us your feedback on GitHub if you see any differences in behavior or performance as you port your Sockets code to UWP.
System.Net.Http gets HTTP/2

Developers writing UWP apps on Windows 10 and .NET Core 5 will get HTTP/2 support in System.Net.Http.HttpClient. HTTP/2 is the latest version of the HTTP protocol and provides much lower latency in web access by minimizing the number of connections and round-trip messages. Adding this support into the HttpClient API means that server responses come back much faster, leading to an app that feels more fluid at the same network speed. And the best part is – this feature on by default, so there is zero code change required to leverage this. For more details on how HTTP/2 provides faster web access to apps, see this talk from Build 2015. The talk also features a simple photo downloading app that shows approximately 200% improvement in latency upon switching to HTTP/2 (demo video).

The following code snippet shows how to query the HTTP version preference on the client as well as the actual HTTP version being used for the connection: var myClient = new HttpClient();
var myRequest = new HttpRequestMessage(HttpMethod.Get, "http://www.contoso.com");
// This property represents the client preference for the HTTP protocol version.
// The default value for UWP apps is 2.0.
Debug.WriteLine(myRequest.Version.ToString());
var response = await myClient.SendAsync(myRequest);
// This tells if you if the client-server communication is actually using HTTP/2
Debug.WriteLine(response.Version.ToString());

Notes:

Setting the Request.Version property to 2.0 is not supported on other .NET platforms and will throw a System.ArgumentException when trying to send such a request. The default version on .NET platforms other than UWP is 1.1.

The Request.Version property represents the client API preference to use HTTP/2. The actual HTTP version used will depend on the client OS, server and intermediate proxies. HTTP/2 is a negotiated protocol that will automatically fall back to HTTP 1.1 if the server or intermediaries do not support HTTP/2.

System.Net.Http

In Windows 8.1, the implementation of HttpClient was based on a managed HTTP stack comprising of types such as System.Net.HttpWebRequest and System.Net.ServicePointManager. In .NET Core for UWP apps, this has been replaced by a completely new, lightweight wrapper on top of native Windows OS HTTP components such as Windows.Web.Http, which is based on WinINet. This allows us to leverage all the latest features (e.g. HTTP/2) from the OS and we are able to provide these new features much faster to .NET developers than we previously could. It also helps lower the memory consumption of .NET apps running on Windows 10, thereby giving the user a more fluid experience running multiple apps simultaneously. The available set of APIs from System.Net.Http documented here remains unchanged.
The new implementation has been tested to ensure functional parity with the previous Windows 8.1 implementation so that you, the developer, do not see any differences in API behavior as you port your HTTP client code to UWP. However, if you do see any issues/bugs, please file a bug on GitHub.

System.Net.Requests

This library contains types related to System.Net.HttpWebRequest and System.Net.HttpWebResponse classes that allow developers to implement the client role of the HTTP protocol. The API surface for .NET Core 5 is the same as that available for Windows 8.1 apps and is very limited compared to the surface in the .NET Framework. This is intentional and we highly encourage switching to the HttpClient API instead – that is where our energy and innovation will be focused going forward. Other parts of .NET Core 5 such as Windows Communication Foundation (WCF) have already migrated to HttpClient in their .NET Core implementation as well, as outlined here.
This library is provided purely for backward compatibility and to unblock usage of .NET libraries that use these older APIs. For .NET Core, the implementation of HttpWebRequest is actually based on HttpClient (reversing the dependency order from .NET Framework). As mentioned above, the reason for this is to avoid usage of the managed .NET HTTP stack in a UWP app context and move towards HttpClient as a single HTTP client role API for .NET developers.

SPIRO THE TECH GURU