SocketTools 6.0 will introduce a new component and API framework that is designed to simplify the process of creating TCP/IP server applications. In the Library Edition, this will be included as extension of the existing SocketWrench API, with additional functions designed to create an instance of the server and manage the client session. In the .NET Edition and Visual Edition, it will be included as a new component that has an interface that is very similar to the current SocketWrench component.
Creating a server application is one of the more complex undertakings when it comes to software development, particularly if the server must support more than just a handful of client sessions. As anyone who has used SocketWrench to create a server application, you know that there are a lot of moving parts, with instances of the component created to listen for incoming connections, additional instances created to accept each client session and a lot of “glue code” required to manage the server itself and each of those clients.
The goal for the new Internet Server component was to provide the basic framework for a general purpose TCP/IP server. We wanted to simplify things so that the developer could focus on actually writing the code that has the server do something, rather than struggle with the complexity of building a stable, multi-threaded server that scaled well, supporting a large number of active client sessions. To this end, our requirements were:
1. The interface needed to be similar to our existing components, specifically in terms of SocketWrench. We didn’t want to force developers to re-learn what they already knew, and so it was decided that the server API would be an extension of the existing SocketWrench API. Developers who have are familiar with the current API can continue to use the same functions in combination with the new functions introduced as part of the server framework. For the ActiveX and .NET components, we intentionally made the interface very similar to the SocketWrench component, minimizing any differences as much as possible. There were inevitably some changes that needed to be made, but we’re confident that developers who are familiar with SocketWrench will find the Internet Server component to be very easy to use (in fact, it’s even easier to use).
2. The server framework needed to be multi-threaded and support a reasonably large number of active client sessions. Because of the nature of how Windows Sockets works at a low level, having client sessions isolated in their own thread would make things much easier for developers to implement complex server applications, and it would significantly improve performance overall. By their nature, single-threaded servers (where multiple client sessions are all serviced within a single thread) don’t scale well and can introduce real performance bottlenecks. The trick, however, was how to support multi-threading in a transparent way, so that developers wouldn’t be forced to write thread management code. We accomplished this by adopting a completely event-driven model where all of the server’s working code is implemented as event handlers, and each client session is identified by a unique handle.
3. The server should be resilient, providing protection against common types of denial-of-service attacks, such as flooding. Much of this is handled internally (and transparently) by the server framework, however the developer does have specific control over various aspects of how client sessions are managed. For example, the developer can determine the maximum number of client sessions that will be accepted, the maximum number of clients per IP address, the amount of time that client sessions can remain idle and so forth. This ensures that when the server is deployed, it functions in a real-world environment.
4. The server framework should provided high-level management functions that simplify basic tasks. There are functions that can be used to control the server overall, as well as those designed to manage individual client sessions. For example, stopping the server and gracefully disconnecting the active client sessions can be done in a single method call. We’ve also made it easy to obtain statistical information about the server (such as the number of active clients currently connected to the server), as well as associate private application-defined data with each client session. Client management was designed to be very flexible, while at the same time easy to use. For example, each client session can be given a string moniker, and referenced by that name rather than its numeric handle value.
5. The server should have low overhead, and be usable as both a stand-alone application as well as a Windows service. The server framework has a small footprint, and was designed to use Windows events rather than a message queue for network event notifications. This internal change not only improved overall performance, it eliminated some of the limitations that SocketWrench has when used to create a server application.
We’re excited about the upcoming release of SocketTools 6.0 and SocketWrench 6.0, both of which will include the new Internet Server component. If you’ve used SocketWrench to create an Internet-based server application in the past, or you’re looking at a future project that will require a service, we think that you’ll find this new component to be a fantastic addition.