.NET Networking Classes

The .NET Framework classes for networking in the System.Net namespace greatly improve on the networking interfaces built in the past without imposing proprietary formats or APIs. Programming with these classes provides a consistent programming model that the programmer can access at many different levels. These classes come in a form that assumes a client/server relationship.

Productive Network Development

With the classes in the System.Net namespace, the programmer can quickly bring an application online using high-level classes. If it is required, the application can be easily modified to use lower-level functionality while adhering to the same application-specified protocol. Details that the programmer need not deal with are handled “correctly.” In other words, most properties have “reasonable” defaults that are not explicitly set.

Layered Networking Stack

It is possible to work from the lowest level to a high level. You can program down at the lowest Socket level where you have a great deal of freedom to modify the application functionality. You can also work at a high level such as with a WebClient that is easy to use and provides a great deal of functionality but is targeted at a specific function.

Target Client and Server-Side Scenarios

TcpClient, TcpListener, WebRequest, and WebResponse target a client/server scenario. The standard APIs that start a server listening and a client connecting have been encapsulated into these classes with little overhead.

Extensible

Classes can be overridden. All of the classes can be used as a base class so that a user can override/replace certain functionality. For example, what if the user must get at the underlying Socket in the TcpClient class? To do this, you need to build a class that uses TopClient as a base class and simply return the “internal” Socket from a new method. It would look like this:

class MyTcpClient : TcpClient
{
    Socket GetSocket()
    {
        return Client;
    }
}

Standards Based

Little in System.NET is proprietary to Microsoft. Almost all of the classes support established standards such as TCP, UDP, HTTP, and SOAP. Using these standards allows your .NET application to communicate with any other program as long as it also supports the same standard. Specific examples of where a standard is not being used would be something like NT LanMan (NTLM) authentication or using the binary formatter for serialization. These exceptions are few and can be either avoided or segregated out so that the entire application does not become dependent on something that is not an established standard. Communicating by using a standard is becoming a requirement.