One of the most common requests that we’ve heard from our developers is that they want to use SocketTools in their project, but they really only need support for a particular protocol. The SocketTools Toolbox components meet that need by providing libraries and components for the most commonly used application protocols in the SocketTools suite. They’re exactly the same components that are included in the SocketTools Editions, packaged individually at a reduced cost.

There are eight SocketTools Toolbox packages available:

SocketTools FTP Toolbox
SocketTools HTTP Toolbox
SocketTools IMAP Toolbox
SocketTools MIME Toolbox
SocketTools POP3 Toolbox
SocketTools SMTP Toolbox
SocketTools SSH Toolbox
SocketTools Telnet Toolbox

Each of these products are self-contained and include components which can be used with virtually any Windows programming language, along with examples and technical reference documentation. Each Toolbox package includes the following component types:

A managed .NET class for development with Visual Basic .NET and C#, or any other language which can target the .NET Framework. Assemblies are included for use with Visual Studio .NET 2003, Visual Studio 2005 and Visual Studio 2008. They are also supported with the current beta release of Visual Studio 2010 and the .NET Framework 4.0.

An ATL-based ActiveX control for development with classic Visual Basic, Visual FoxPro, PowerBuilder and any other language which supports the use of ActiveX/COM components. The ActiveX controls can also be used as automation objects with scripting languages such as VBScript.

A Windows dynamic link library (DLL) that can be used with most programming languages. These libraries provide a standard SDK style interface that is very similar to the Windows API. Class wrappers, header files and import libraries are provided for Visual C++ and Borland C++, along with constants and function declarations for languages such as Visual Basic and PowerBASIC.

Each of the networking components supports secure connections, using the Secure Sockets Layer (SSL), Transport Layer Security (TLS) and/or Secure Shell (SSH) protocols. For example, the SocketTools FTP Toolbox package can be used to establish a standard FTP connection, a secure connection using SSL/TLS (FTPS) or a secure connection using SSH (SFTP). Because you don’t need multiple components to support the different types of security protocols, your code is simplified and the amount of time you spend implementing file transfer functionality in your application can be significantly reduced. The different SocketTools Toolbox packages can also be combined, if your application needs support for more than one Internet protocol.

For more information, please visit our website at go.catalyst.com/toolbox where you can get an overview of each of the products, along with pricing and download links for a free 30-day evaluation.

Here is a brief overview of just a few of the major changes that will be coming in the next release. Additional information about SocketTools 7 can be found in the Frequently Asked Questions document on our website.

Native support for 64-bit Windows applications. The SocketTools 7 .NET and Library Editions will include 64-bit editions that can be used to build native 64-bit versions of your applications. Of course, we will continue to offer our 32-bit components as well, allowing developers to target the platforms of their choice.

Support for Internet Protocol version 6 (IPv6). Commonly known as the next generation Internet protocol, IPv6 is designed to eventually replace the current version. IPv6 addresses many of the problems with the current version of the protocol, and adds a number of improvements in terms of routing, network configuration and overall performance. While most of the Internet still uses IPv4, offering support for IPv6 ensures the long-term compatibility of your application software.

Support for Quality of Service functionality. The ability to negotiate and manage the bandwidth allocated to a connection is known as Quality of Service (QoS). This allows an application to prioritize network traffic for mission-critical applications, as well as obtain statistical information about the connection.

Support for the Really Simple Syndication (RSS) protocol. A new library and component will be included that provides a simplified interface to download and parse RSS feeds. RSS has become common place in providing updates to frequently changing content on the Internet, and can also be used programmatically. For example, your application could check an RSS feed to determine if it is running the current version, or if the user should be notified of a new release.

Support for Short Message Service (SMS) text messaging. This component and library enables developers to send short text messages, typically 160 characters or less, to a mobile device. All you need to know is the cell phone number and provide the text that you wish to send. A method for specifying an alternate email gateway server, typically needed for providers outside of the United States, can also be specified if needed.

Support for very large file transfers. Currently, file transfers using protocols like FTP and HTTP are limited to 4GB. In SocketTools 7, these limitations will be removed, enabling applications to upload and download very large files that exceed 4GB.

Support for automatic management of background file transfers. This will enable your application to queue file transfers in the background, without interfering with the current thread of execution. For example, you could have a number of files that you want your software to download at one time. With this option enabled, you request the files as you normally would and the data transfer begins in the background, executing in a separate thread and control is immediately returned to your program. An event is used to signal when the transfer has completed. There’s no need for you to worry about managing multiple threads or worry about writing complex inter-process communication code.

Network protocol improvements and extensions. SocketTools 7 will also include improvements to many of the network protocols, such as support for HTTP compression, Integrated Windows Authentication support and improved session logging and debugging features.

Of course, one of the most common concerns for developers is code compatibility. SocketTools 7 will continue to include all of the components and libraries in the current version and will be source compatible to ensure that upgrading is as easy as possible. This includes continuing support for ActiveX controls and Visual Basic 6.0 (Classic VB). We will continue to support all of the current Windows platforms from Windows 2000 and later, including the new release of Windows 7 in October, 2009. As with previous versions, SocketTools 7 will support side-by-side installation. You can safely install the new version on the same system that already has a previous version of SocketTools installed.

SocketTools 7 is currently under development, and there will be phased beta testing similar to how the beta test for version 6.0 was managed. If you’re a current beta tester, you’ll automatically be invited for the first round of testing. We’ll then open up testing to other developers who are interested in working with the new release. We currently plan on releasing SocketTools 7 in Q1 2010, although this is subject to change based on the testing process and feedback from developers.

For example, in Visual Basic the code could look like this:

  SecureShell.HostName = "remote.server.net"
  SecureShell.UserName = "username"
  SecureShell.Password = "password"

  Dim strResult = SecureShell.Execute("/bin/ps -ef")
  If strResult.Length = 0 And SecureShell.LastError > 0 Then
      MessageBox.Show(SecureShell.LastErrorString)
      Exit Sub
  End If

  TextBox1.Text = strResult

In this example, the typical property values are set for the SSH server domain name or IP address, the user name and password required to authenticate the session. The Execute method is then called, providing the command to execute as a parameter, and the output from the command will be returned to a string value. In this case, we’re connecting to a UNIX based system and listing all of the running processes using the /bin/ps command.

If an error occurs, then the return value will be an empty string and the LastError property will be set to a value which identifies the error condition. In this case, we simply display a message box that shows a human-readable description of the last error code and then exit the subroutine.

As with an interactive terminal session, the entire operation is encrypted over the network, including the command that is sent and the output that it returns. For this reason, using SSH is preferred over the old rexec protocol which would send both the user credentials and the command as plain text. If you’re currently using the Remote Command class in your applications, it’s recommended that you consider rewriting your code to use the SSH component as a secure alternative.

SocketTools 6.0 is fully compatible with Windows 7 and it is recommended that developers download the current service pack update. For those developers who are using older versions of SocketTools, we recommend upgrading to the current version of SocketTools to ensure compatibility with the Windows 7 operating system. Customers who have purchased the SocketTools Subscription can download the latest version using the download link provided when they purchased the subscription. More information about SocketTools 6.0 is available on our website.

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.

Although the class makes developing server applications significantly easier, there are a few important things to keep in mind when using this class:

Although the code that you’ll write will look like typical single-threaded code that responds to events, it’s actually a multi-threaded application, with each client session isolated in its own thread. When network events are raised, they are being raised within the context of the thread that’s generated them. For example, this means that when the OnRead event fires, it’s not firing within the thread that created that instance of the InternetServer class (e.g.: the main UI thread). Any code that you have inside that event handler is executing in the context of the thread that’s managing that specific client session.

Because network events are being raised in the context of the client session threads, this means you cannot update user interface controls directly from within the event handlers. .NET does not allow one thread to modify a control that was created in another thread (usually the main UI thread). This is an absolute rule, and if you break it, your program is either going to hang or throw an exception. If you want to change any property values or call methods in a control, you need to create a delegate and marshal the call to the UI thread to using the Invoke method. Both the VB.NET and C# examples show how to do this; in the example, it’s used to update a ListBox control. Frequently updating the user interface from within an event handler can have a very negative impact on the overall performance of your program. Marshalling calls across threads to those UI controls is an expensive operation, and while you’re doing it, you’re not servicing network events like OnRead. You should keep it to a minimum, only updating the UI when absolutely necessary.

Another important consideration is that you should never modify shared objects without first synchronizing access to that object. In VB.NET it’s typically done using the SyncLock statement; in C# it’s done using the lock statement. The VB.NET and C# examples show to do this using a shared instance of a Hashtable class which is used to keep track of the number of bytes echoed by the server. While our lower-level API provides thread-safe queuing functions (InetServerEnqueue, InetServerDequeue, etc.) this doesn’t exist in the .NET class, largely because it would be redundant. If you want to use a queue, then you use the .NET Queue class, but the same rule applies; make sure that you synchronize access to the queue. While the InternetServer class does have Lock and Unlock methods, you should never use it for general purpose synchronization in your program. Calling the Lock method will cause every single client thread to block, and so while using Lock and Unlock would seem to be the easiest approach, it’s not a good idea for performance reasons.

The InternetServer class provides two general forms of many methods which are used to exchange data with the clients, ones which requires a handle to the client socket, and ones that do not. It’s not required that you specify a client handle if your code is inside an event handler (or in a function that’s being called by an event handler); the class knows which client raised the event and calls to Read and Write will work with that client (referred to as the “current client” in the documentation). However, if you want to exchange data with a client outside of an event handler, or with a client other than the current client, then you must specify a handle. Also, certain properties only return meaningful results from within an event handler. For example, the ClientAddress property (which returns the IP address of the client) should only be referenced from within an event handler such as OnConnect. The documentation notes when a property or method should only be used inside an event handler.

Finally, while it is possible to exchange data in an event handler with a client other than the one that generated the event, it’s not recommended. This is a case where you should use the Lock method to ensure that you’re the only thread that is attempting to read or write on that socket at the time. Two threads that attempt to read or write data on the same socket has undefined results; there’s no guarantee which thread would “get there first”, and the end result can be really unpredictable behavior by your program. One way to think about this is to think of your server program as a house, with each client connection being a room inside that house. You can do pretty much anything you want inside your own room (from within the event handler code that you write). However, if you want to go into another room and start rearranging the furniture, you need to make sure that every other thread is locked out while you do that. When you’re done and back in your own room, then you unlock the server and continue on.

The file verification is performed using one of several methods, depending on what features the server supports. There are three general options available when performing file verifications using FTP: an MD5 hash, a CRC-32 checksum or a file size comparison. If the server supports the XMD5 command, then this is used to generate an MD5 hash and compare it against the local file; if the hash value matches, then the contents of the file are identical. If the server doesn’t support this feature, a CRC-32 checksum can be generated in a similar fashion using the XCRC command to determine if the file contents are the same. If the FTP server doesn’t support either MD5 or CRC-32, then a simple file size comparison can be performed.

By default, SocketTools will give preference to the MD5 hash, falling back to a CRC-32 checksum. If neither feature is supported by the server, then it will compare file sizes. Naturally, a file size comparison is the least reliable, so developers can specify if they only wish to use the MD5 and/or CRC-32 methods to determine if the file contents match.

Using the storage API is very simple, with methods that create or open an existing storage file, store new messages, retrieve old messages and search for specific messages. For example, you can search the message store for all emails that have a certain subject or were sent by a particular individual. The API itself is independent of the various email protocol components, and can be interfaced with any of them to provide local storage capability for the email messages that you’re processing.

The SocketTools Library Edition includes the message store API as part of the MIME API, with new functions such as MimeOpenMessageStore and MimeFindStoredMessage. The SocketTools Visual Edition includes the new functionality as part of the current MailMessage control, while the SocketTools .NET Edition includes it as part of the SocketTools.MailMessage assembly.

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.