Sockets are the most powerful networking mechanism available in .NET—HTTP is layered on top of sockets, and in most cases WCF is too. Sockets provide more or less direct access to the underlying TCP/IP network services—they effectively let you speak the native language of the network. This can offer some flexibility and performance benefits over HTTP-based communications, but the downside is that you need to do more work. Also, in corporate environments, communication with the outside world with ad hoc use of sockets is often blocked, as firewalls may be configured to let through only the traffic they understand and expect. But in cases where those restrictions do not apply, and if the flexibility or (relatively small) performance benefits are worth the effort, sockets are a useful tool.
The basic idea of a socket has been around for decades, and appears
in many operating systems. The central concept is to present network
communication through the same abstractions as file I/O. We already saw
something like that with
Stream support. However,
those streams are concerned with the body of an HTTP request or response.
With sockets, the streams are at a lower level, encompassing all the data.
(If you used a socket-based stream to connect to a web server, you’d see
all of the details of the HTTP protocol in the stream, not just the
Besides the file-like abstraction, socket APIs also have a standard set of operations for establishing connections, and ...