While HTTP programming in .NET continues to become easier year after year, Microsoft hasn’t been giving much attention to socket-based programs. This where open source projects such as Kerry Jiang’s SuperSocket comes into play.
InfoQ: Before we get into the details of SuperSocket, let’s talk about sockets in general. These days all of the news is about HTTP-based protocols, especially REST/JSON. Aside from legacy systems, why would anyone want to work directly with TCP or UDP?
Kerry Jiang: Yes, HTTP is more popular. Sometimes, I also suggest my users to use http directly instead of raw socket in some cases. But in some other cases, HTTP doesn’t work. For example, the server want to push some messages to client actively. HTTP was not designed for duplex real-time communications, but with a raw socket you can design your own protocol which can support real-time. HTTP is also a little heavy for some use cases. Nowadays, the Internet of thing are developing very fast. Some devices just want to send/receive several bytes for lower power and network usage. The header and the text encoding of HTTP consume more resources, so it cannot satisfy this requirement.
InfoQ: What are the main problems that you see in .NET’s built-in socket APIs?
Kerry Jiang: SuperSocket is not going to replace .NET’s built-in socket APIs. Instead, SuperSocket is base on it. SuperSocket wraps the socket communications’ details, and let you focus on your business layer. It also is a server engine that includes lots of best practices of socket server developing. TCP application protocol resolving always be a complicated work for junior developers. How to know whether you have receive a full message? How to handle the case you get multiple messages in one piece of receive buffer? SuperSocket provides a unified processing model and a convenient protocol resolving library with high performance. Based on SuperSocket, you can develop your own protocol socket server with stable performance easily. It really make the complicated socket server developing work simpler.
InfoQ: Many of our readers don’t have experience working with TCP. Often they have to pick it up because they need to communicate with some obscure service, often hosted by another company. For their benefit, can you explain what it means to have a partial message or multiple messages in the receive buffer?
Kerry Jiang: TCP is a stream base protocol, the binary data transferred over it doesn’t have boundary in transfer layer. On the other hand, all routers, switches, senders and receivers in the network have different buffer size. So they cannot forward the data in the same chunk size. If you send 100k data to the other end in one chunk over TCP, the other endpoint probably will receive this 100k data in many chunks. In the same rule, if you send the 100k data in many chunks, the other endpoint may receive all of the data in one chunk. That’s the reason why you probably have partial message or multiple messages in one piece of receive buffer. That’s also the reason we need an application level transport protocol over TCP to define each message’s boundary.
InfoQ: Why did you choose to support Mono and Linux?
Kerry Jiang: Apparently, Linux+Mono has lower cost and it is very easy to support Mono/Linux for a pure .NET application. Some higher .NET version like .NET 4.5 requires Windows Server 2008 r2 at least, which is expensive for normal users. But in Linux, you can install latest version of Mono to support it.
InfoQ: Did you run into any problems when implementing the Mono version? Or was that covered by Mono’s implementation of .NET’s built-in socket APIs?
Kerry Jiang: Yes, there are some minor differences between .NET and Mono.
For example:
a) some socket api in Mono is missing overload methods that are in .NET
b) performance counter’s instance names have different format between Mono/Linux and .NETGenerally, they are easy to fix them by runtime detection or conditional compilation symbols.
Of course, if you use runtime detection, you can ensure binary level compatibility instead of providing two different assemblies for different platforms.
InfoQ: The big thing these days is asynchronous programming. Does SuperSocket support async/await and if so what does that look like?
Kerry Jiang: Yes, SuperSocket’s socket sending and receiving always be async. But it doesn’t support async/await keywords for now. In the future version, I’ll add it. For now, we need support .NET 4.0 and I don’t want to create too many branches to make the project complicated.
SuperSocket is available under the Apache License 2.0.
To suggest other open source projects that should be highlighted on InfoQ, contact Jonathan Allen at jonathan@infoq.com.
