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’re currently using the SocketWrench control or .NET class for a server application, take a look at the new Internet Server control. It’s included in both SocketWrench 6.0 and SocketTools 6.0, and you can review the online help at go.catalyst.com/help

For professional developers who need security, additional functionality and technical support, we have commercial versions of SocketWrench. Secure connections using SSL/TLS can be easily established, usually with just an extra line of code, and for projects where you need to create a server application, the commercial version also includes the Internet Server component which makes it easy to create custom TCP/IP servers.

For those programmers who are primarily working with native code, such as classic Visual Basic, PowerBasic, C++ and other similar languages, our SocketWrench Secure Edition includes both an ActiveX control and a standard dynamic link library (DLL) that provides an interface that’s similar to the standard Windows API. It can be used with virtually any programming language, and has a great degree of flexibility.

For Visual Basic .NET and C# developers, we’ve designed SocketWrench .NET to really simplify Internet programming beyond what’s included as part of the .NET Framework. Microsoft has a lot of interdependency in their classes where you end up creating a number of different class instances and writing a lot of “glue code” to tie them together. An example of this would be the TcpClient class which uses the NetworkStream class, and then to convert the data read to a string, you’d need to use the System.Text.Encoding class and so on. If you need SSL support, then you’d also need the SslStream class, and write the code to integrate that. All of this functionality is incorporated directly into SocketWrench, which significantly reduces the amount of code that needs to be written. And as every developer knows, the less code you have to write, fewer errors will be in that code. A simple, straight-forward design is one of the cornerstones of reliable software. Give it a try and let us know what you think.

If you are currently using version 5.0, you can upgrade to the current version at a discounted price. Version 6.0 is source compatible with version 5.0 and can be installed side-by-side on the same development system. For more information about what’s new with SocketTools 6.0, please visit our website. If you have any questions, feel free to post in the technical support forum section appropriate for your product.

The SocketTools 6.0 Secure Editions introduce new components that implement the Secure Shell (SSH) protocol, which can be used to establish a secure, encrypted connection with a server. With an interface that is similar to our Telnet components, you can implement an interactive terminal session, or you can specify that you want a command executed remotely and the output returned to your application. SSH does not require complicated certificate management and is widely supported on most servers today. Of course, the SocketTools Secure Editions continue to also support the SSL and TLS security protocols, providing the widest range of options to developers who require security features for their applications.

The SocketTools Secure Editions also support file transfers using the Secure Shell (SSH) protocol, as well as the SSL and TLS protocols. Also commonly referred to as FTP+SSH, the SocketTools file transfer components can be used to connect to an SSH server and upload or download files, obtain directory listings and perform common file management functions. Because support for SFTP is integrated into the existing FTP components, in most cases all you need to do is specify the SSH port number without making any other changes to your code. The same interface is provided for FTP, FTP+SSL and FTP+SSH, making it easy to offer the widest range of options to your users. Another new feature of the File Transfer Protocol components is the ability to verify that the file on the local system is identical to the file on the server using an MD5 hash or CRC-32 checksum, and automatically setting the correct file transfer mode based on the type of file being uploaded or downloaded. Developers can also explicitly verify the contents of a file, and can even register their own custom file types.

One of the most complex tasks in Internet software development is creating a custom server application that can reliably handle a large number of client connections. SocketTools 6.0 introduces a new Internet Server component to simplify the development of custom servers, providing an easy-to-use framework where the only code you need to write is in response to events that are sent to your application. With a single function call, you can create a scalable, multi-threaded, event-driven server that can be used to accept connections from clients anywhere in the world, or just on your local intranet. All of the networking, thread management, synchronization and messaging are handled internally by the framework, allowing you to focus on writing your own code without worrying about the complex details of the server implementation.

Developers who need to create an e-mail application that download and store messages on the local system, the Mail Message (MIME) components and library have been expanded to provide a new storage interface that simplifies the storage, retrieval and management of message. Simply create a new storage file, and begin adding messages to it. When you need to access a stored message, you can reference it by an index number, or you can use functions to search for a particular message that contains a specific header value. For example, you can search the message store for all messages that have been sent by someone with a particular e-mail address. There’s even a compatibility mode where you can import message stores from UNIX mail systems, if needed.

SocketTools 6.0 is fully compatible with both Windows Vista and Windows Server 2008, and is designed to take advantage of new features introduced in Microsoft’s latest operating system. Our developers use Windows Vista and Visual Studio 2008 as their primary development platform, so we don’t simply test under Vista, we work with the operating system every day and understand how it impacts application development in the real world. Of course, SocketTools is also fully supported under Windows XP SP2 and SP3, Windows Server 2003 and Windows 2000. If your users are upgrading to Windows Server 2008 or Windows Vista, then we recommend that you to upgrade to SocketTools 6.0 to ensure compatibility.

For more information, please review the SocketTools FAQ in the support section of our website. We also encourage you to download a free evaluation copy of the SocketTools 6.0 Edition that interests you. The evaluation license is valid for a single development system for 30 days, it is completely functional and can be safely installed side-by-side with earlier versions of SocketTools.

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.

The second section of the tutorial walks you through creating your first Internet application, a web client that will download an HTML source page from a server. We decided to use this as the example because we felt it was simple and easy enough to understand without getting wrapped up in the details of building a more complex application. We’ve also included a companion video tutorial that demonstrates the same basic concepts.

Sometimes we’re asked why a developer should use SocketWrench rather than the classes or components which are already included with Visual Studio, or just using the Windows Sockets API directly. The tutorial answers that question by demonstrating how simple SocketWrench is to use. It’s a component that is useful for developers who are not experts in network programming, and yet it is flexible enough that it can be also be used with very complex applications.

The simplicity of SocketWrench is particularly evident when creating secure applications using SSL and TLS. Establishing a secure connection is a seamless process using the security functionality built into the SocketWrench. It automatically manages all of the complicated encryption and certificate validation, and doesn’t require you to understand any of the lower level implementation details. It also doesn’t require that you to use another class, like the SslStream class in .NET. As the tutorial demonstrates, switching between secure and standard (non-secure) connections only involves setting a single property to true or false.

Our goal with SocketWrench is to provide a component that makes it as easy as possible to Integrate Internet functionality in your own applications using code that is generally no more complex than opening, reading from and writing to a file. If you’re not familiar with Internet programming, we hope this tutorial helps minimize that initial learning curve and gets you started building your first Internet application.

» An Introduction to Internet Programming (PDF)
» SocketWrench Video Tutorial
» Download SocketWrench .NET for Visual Studio

The first release of SocketTools consisted of two versions, a 16-bit version for the Windows 3.1 platform, and a 32-bit version for the Windows 95 platform, which was new at the time. Visual Basic 4.0 had been released, and with it came the new OLE controls which were later renamed to ActiveX. Initially, SocketTools was only available as controls (16-bit VBXs and 32-bit OCXs) and their code was largely shared between the two versions. When the decision was made to release a Library Edition that consisted of standard Windows DLLs, we had to go back to the drawing board to some extent.

There were a fair number of assumptions in the core networking code that worked well when it was in a control targeted for a single language. On the other hand, porting that code to standard DLLs presented a problem because a DLL can be used with virtually any Windows programming language. The solution was to redesign that core code from the ground up, focusing on implementing the DLL interfaces first, and then building the ActiveX controls on top of that API. All of the “inside knowledge” that the ActiveX controls depended on had to be removed and redesigned. The decision was made early on that we didn’t want to create undocumented functions specifically for the controls. Rather than creating our own “shortcuts”, it forced us to use our own code much as any other developer would.

As a result of this re-development, there were two central issues that we had to address. One was support for Unicode, and the other was multithreading. Unicode support was a fairly easy decision to make. We already had to support it internally because 32-bit ActiveX controls use Unicode. And while it wasn’t considered to be a significant issue ten years ago, we knew that it would be in the future. Multithreading support was a bit more problematic. We knew that it was important in a general sense, however Visual Basic was (for all intents and purposes) a single-threaded language and ActiveX controls use single-threaded apartments. In essence, COM made sure that there would only be one object per thread and that fit nicely with the Windows Sockets API which allows only one outstanding blocking socket operation per thread. With a DLL, we couldn’t make any assumptions about the language it would be used with, or how threads would be managed, if worker threads would be created at all.

We decided on two principal design goals when it came to the SocketTools API. One was to make sure it could be used in both a single-threaded and multithreaded program without requiring any special coding on the part of the developer. Every function had to be designed to be thread-safe, but this introduced another fundamental problem: sockets are not inherently thread-safe. In other words, when you have two threads reading and writing on the same socket, there’s no guarantee which thread is actually going to read the data, or in what order the data is going to be written. The developer has to use some synchronization mechanism to ensure that thread A is not reading data that thread B expects to read. That tied into the second design goal, which was to make sure the API wouldn’t provide the programmer with just enough rope to hang himself. After all, SocketTools was specifically designed for developers who don’t have a lot of experience with sockets programming. They just want to be able to add features like downloading files or the ability to send emails, without having to worry about all of the low-level details.

This lead to the decision to implement a threading model in the DLLs that was functionally similar to how COM apartment threading works, but with a bit more flexibility. Whenever a handle to a client session is created, it is associated with the thread that created it. The handles that are used with the SocketTools API are really a kind of pseudo-handle that references some internal data structures, along with I/O buffers and the actual socket handle. Whenever the handle is passed to a function, it is dereferenced internally and certain checks are performed depending on the type of function being called. One of those checks is whether the thread that is calling the function is the same as the thread that created the handle. If they don’t match, the error ST_ERROR_NOT_HANDLE_OWNER is returned to the caller. This check isn’t actually performed on all functions; however, any function that deals with I/O on the socket will check thread ownership. Because it’s possible that the developer would want to have one thread initially create the session, but have another thread do the actual work, a mechanism was added where a thread could assume ownership of a handle created by another thread; this is done using the AttachThread function. In many ways, this provided the best of both worlds. Developers could pass client handles to other threads, but they had to explicitly establish ownership which would prevent inadvertent errors in their code that would prove very difficult to debug.

Over time, we have had some developers express some frustration that handles (or class instances, in the case of the .NET classes) cannot be freely passed between threads. Multithreaded languages have become the rule rather than the exception, and it’s really only the legacy languages like Visual Basic 6.0 which don’t have native support for threading. With that in mind, for SocketTools 5.0 we decided to revisit the issue of the thread ownership model that we use. In the end, we have decided that in the interest of making things safer for developers, our implementation was overly restrictive. If the programmer wants to take responsibility for thread synchronization (which would typically have to be done in most cases anyway), then he should be able to without the additional bookkeeping involved in tracking what thread owns a particular client handle at that point in time.

In SocketTools 5.0, when you create a connection you will be able to continue to use the same threading model used in previous versions, or you can choose to specify a “free-threading” option that tells the class or library that any thread can use that session handle. It is important to keep in mind that if you use this option, you are responsible for synchronizing access to the session yourself. For example, if two threads call the FtpCommand function using the same handle, if you don’t synchronize them you will have no control over which command is actually sent to the server first. This can lead to logical errors in the program which can be very difficult to find in a large program, and it’s often the case that they can’t be reproduced reliably. With the default threading model, you would catch this during testing because one of those threads would get an error indicating that it’s not the handle’s owner. With the free-threading model, that responsibility falls to you. It’s an advanced option we feel will be of benefit to developers; however we recommend that you continue to use the default threading model whenever possible.