SocketTools includes components and an API framework that are designed to significantly simplify the process of creating TCP/IP server applications. In the Library Edition, it’s an 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 ActiveX Edition, server components provide an interface that is similar to the SocketWrench control.
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.
You can think of the Internet Server control as a server-in-a-box that handles all of the low level details such as accepting incoming connections from clients, keeping track of the active client sessions and processing each of the various network events that can occur for each client. The server is multi-threaded, with each client sessions being isolated in a separate thread and it is completely event driven. When one of the clients interacts with the server, it raises an event that your code handles. Although the events are similar in function to how SocketWrench works with asynchronous sockets, the Internet Server component uses a completely different event mechanism that doesn’t make use of messaging for the event notifications.
Our design goal was to make creating your own custom server as easy as developing a client application. All you need to do is create your event handlers and start the server. Because each of the client sessions are isolated from one another, you can write your event-handling code in a simple, top-down fashion without getting mired in asynchronous callback notifications. You end up with server code that is easier to write, debug and maintain. We’ve also made sure that the various properties and methods in the Internet Server control are as similar to SocketWrench as possible, minimizing your learning curve and allowing you to easily migrate your existing code.
If you’ve used SocketWrench to create an Internet-based server application, or you’re looking at a future project that will require a service, we think that you’ll find the Internet Server component to be much easier to work with.