We interviewed David Haney, creator of SimplSockets for .NET about TCP programming in the modern age.

InfoQ: These days most people seem to be using HTTP rather than a lower level protocol such as TCP. Why do you think TCP and UDP are still important?

HTTP is an excellent communication protocol for many purposes and applications. It makes communication very simple by handling message framing, error codes, and other aspects of low level network communication for you. However, this ease of use comes with a substantial amount of overhead which is introduced by the HTTP protocol specification (which builds on top of the TCP protocol). While most applications can benefit greatly from the simplicity of HTTP, some applications deem network performance as absolutely critical to success. These applications aim to squeeze every single spare cycle out of their code in order to maximize throughput, and the overhead of the HTTP protocol and its related headers just doesn't make sense for their needs. Examples of such applications are search engines, distributed caching solutions, and video streaming services. For these sorts of applications, the performance of TCP or UDP simply cannot be matched by HTTP. Though more complex to implement, TCP and UDP offer substantial increases to throughput that allow applications to be as performant as possible.

InfoQ: What does SimplSockets offer over .NET’s built-in socket libraries?

SimplSockets does not aim to reinvent the already well-working wheel that is .NET sockets; it instead builds upon them. When implementing a custom communication protocol over sockets, there are many boilerplate or "classic" problems that must be addressed which are not trivial to solve. For example, you cannot control how a TCP socket delivers your message. It may choose to deliver it in one packet, or ten packets, or even fifty packets, and you must do the manual work of recombining these packets of information into the original message yourself. On top of that, TCP does not tell you how many bytes of the message remain to be received, so you must devise a custom protocol header that lets your receiver know how many more bytes it needs to wait for before the message is complete... And then what happens if you receive some of the message and the sender disconnects? You can't wait forever for the message to be received, and so you must create a timeout or failure system... And so deeper and deeper down the rabbit hole you go as you unwind and resolve more and more issues related to creating a custom protocol.

Why solve all of these problems yourself when everyone else who uses TCP sockets needs to solve them too? That's precisely what I feel open source libraries are for! Therefore, I built SimplSockets to fill that gap and solve these classic TCP sockets problems in a way that anyone can use and re-use. The custom protocol that it uses comes with an 8 byte overhead per message (not per packet), but I feel that is an excellent tradeoff for the benefits it delivers. One major benefit is client multiplexing: a single open connection to a server can be used by multiple threads in an entirely thread-safe way. This helps to prevent port exhaustion and connection setup/teardown overhead. On the server side, the implementation is entirely asynchronous and takes advantage of completion threads and proprietary object pooling/re-use to enable your application to remain incredibly performant.

SimplSockets aims to make .NET sockets better and easier to use, not different and proprietary.

InfoQ: Does SimplSockets offer async/await or IObservable support?

SimplSockets does not offer async/await or IObservable support, and this is by design. I wanted SimplSockets to be available to people who are not using .NET 4.5 since it does not truly depend upon any of .NET 4.5's introduced features. The targeted framework version is .NET 4.0 to allow more people the ability to use it, though I may introduce an async/await enabled version for .NET 4.5 in the future.

InfoQ: With any open source project licensing is important. Why did you choose GPL 3 for the SimplSockets license?

I believe that sharing knowledge is important in learning and growing as both a developer and human being. Having said that, I also believe that you should be paid for work that you do which others profit from. As a result, I chose GPLv3 to balance my philosophies: other open source or free projects can use it for free, while those who plan to profit from it must pay their dues in the form of a commercial license.

InfoQ: What do you have planned for future versions of SimplSockets?

The next version will include a more robust communicaton timeout system with configurable timeout intervals. On top of that, I hope to release a version of SimplSockets that operates on the .NET Micro Framework so that .NET driven low level embedded systems can take advantage of it as well. Beyond that roadmap, I plan to entertain any and all suggestions from users of the library and would love to discuss potential improvements; I do not believe for a second that I have all of the answers or have thought of all of the angles!

Is your profile up-to-date? Please take a moment to review and update.

Email Address

Note: If updating/changing your email, a validation request will be sent

Company name:

Keep current company name

Update Company name to:

Company role:

Keep current company role

Update company role to:

Company size:

Keep current company Size

Update company size to:

Country/Zone:

Keep current country/zone

Update country/zone to:

State/Province/Region:

Keep current state/province/region

Update state/province/region to:

Subscribe to our newsletter?

Subscribe to our architect newsletter?

Subscribe to our industry email notices?

You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.

We notice you're using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.