For those of you with an IPv6 connection, you can test that connection to us using ipv6.catalyst.com. If your IPv6 connectivity is limited to tunneling using Teredo, most browsers will not be able to connect to the site because they won’t resolve a host name to an IPv6 address if Teredo is the only IPv6 interface configured on the local system. Note that SocketTools works a bit differently. If a host name only has an IPv6 address associated with it, it will attempt to connect to the system, even if the only IPv6 interface is a Teredo tunnel.

It’s clear that the transition to IPv6 is really taking on some urgency, and Internet service providers are under increasing pressure to start providing IPv6 connectivity to their customers. While the exact timetable isn’t clear, there’s no question that developers need to plan for these changes and make sure that their software is capable of supporting both IPv4 and IPv6 networks.

It’s predicted that the last of the large blocks of available IPv4 addresses will be allocated by the Internet Assigned Numbers Authority (IANA) early in 2011 and the regional registries will exhaust their pool of new addresses within a few years. The widespread adoption of classless routing (CIDR) and network address translation (NAT) delayed the inevitable exhaustion of IPv4 addresses, but we’re rapidly approaching the point where the transition to IPv6 will be required to accommodate the ever increasing number of devices connected to the Internet.

Fortunately, the transition for developers using SocketTools will be fairly simple. Most of the real complexity in dealing with both IPv4 and IPv6 is handled internally, although there are some important considerations when updating your software.

1. If your application stores IP addresses in a database, configuration file, etc. then you need to make sure that your program will recognize both IPv4 and IPv6 formatted addresses. If your program is written to only recognize IPv4 addresses in dotted notation, this will create problems for you with IPv6 because it uses a completely different format. Instead of a sequence of four numbers separated by periods, IPv6 consists of hexadecimal values separated by colons. So while an IPv4 address looks like 192.168.0.20, an IPv6 address will looks something like fd7c:2f6a:4f4f:ba34::a32 and can be much longer than an IPv4 address. You’ll want to allocate at least 46 characters to store a full IPv6 address.

2. If your application allows the user to input an IPv4 address, then you’ll need to change that code to accept both address formats. If you’re using some kind of masked input that expects four individual numbers that are in the range of 0-255, then that code will need to be rewritten because.

3. Your application uses the SocketTools Library Edition and stores addresses as 32-bit integer values, that code will need to be changed. There are several API functions in SocketTools 6.0 and earlier versions that expect an IP address to be stored in a DWORD (unsigned 32-bit integer) variable. In SocketTools 7, those functions have been changed to use a new type named INTERNET_ADDRESS that is capable of representing both IPv4 and IPv6 addresses.

If your software is designed to work with both host names and IP addresses, and you don’t make any assumptions about the format of the address, then there are few changes that you’d need to make. The SocketTools functions and methods that accept either host names or addresses will automatically recognize the difference in formats and act accordingly. Because a host name can resolve to either an IPv4 or IPv6 address, SocketTools will normally choose the IPv4 address whenever possible. For example, if host name www.company.com has both an IPv4 and IPv6 address assigned to it (which will be common, particularly during the transition period to IPv6) then SocketTools will prefer the IPv4 address for backwards compatibility. However, if that domain only has an IPv6 address, then SocketTools will use IPv6 to establish the connection. There’s also an option that you can specify which will force SocketTools to always use IPv6 if necessary.

Because it’s likely you’ll need to continue to support older Windows platforms, SocketTools will also automatically handle situations where an IPv6 stack is not installed, and it compensates for some internal differences between the various versions of Windows. The most complete support for IPv6 is available on Windows 7 and Windows Server 2008. You can install an IPv6 stack on Windows XP and Windows Server 2003, however it does not come pre-installed. There is also a preliminary version of an IPv6 stack that was made available for Windows 2000, however Microsoft never released it as an official update for the operating system.

We recommend that all developers begin looking into making the change to support IPv6, and you’re welcome to join the SocketTools 7 Beta Test that will be starting in January. If you have any questions about IPv6 support (or any of the other features in version 7) join us on our technical support forums.

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.

With the SSH implementation in SocketTools, there is three basic functions that you can use within your applications to take advantage of the protocol:

1. Interactive terminal sessions. This is similar to how the current TELNET protocol component works, and in fact the interface to the SSH component was intentionally designed to be very similar. Our goal was to make it easy to integrate SSH support into an existing application that already used the TELNET protocol. The Terminal Emulation component can be used to provide a visual interface that supports the standard ANSI and DEC VT100/VT220 escape sequences. Alternatively, the SSH component can be used on the back-end to capture output from an interactive session and filter the data transparently.

2. Remote command execution. This is similar to how the Remote Command component works, in that a command is submitted to the remote host for execution, and the output is returned back to the caller. The SSH component makes this very easy to do, providing a single method that allows you to run a command on the server, and its output is returned in a string variable or byte array that you provide.

3. Secure file transfers. Support for secure file transfers using SFTP has been integrated into the current FTP API and components, making it extremely easy to upgrade existing applications to use SSH/SFTP. We decided to go with this approach, rather than implement SFTP support in a separate component, so that developers would be able to integrate the new protocol with minimal code changes. In most cases, all that’s required is specifying a few additional options.

For those developers who have been using SocketTools for a while, you may be wondering what the difference is between SSH and TLS; SocketTools has supported SSL/TLS for years, and that is still the most common method for securing connections to webservers. However, SSH has become popular for remote terminal sessions and secure file transfers because it’s generally less complex and has a lower cost to administrate. For example, SSH doesn’t use site certificates, so there’s no requirement to register with a certificate authority (such as VeriSign or Thawte), generate certificate signing requests and update certificates on a regular basis. Therefore one of the big differences is that SSH cannot provide information about the server itself in the same way that TLS can. For example, SSH doesn’t provide a way for you to determine what company or organization owns the server and where they are located.

However, it’s important to note that the SSH protocol uses standard public-key cryptography to authenticate the client session, and shares many of the same cryptographic algorithms used with TLS, ensuring that the data is secure. There are now millions of users that regularly depend on SSH for secure terminal sessions and file transfers, and SocketTools 6.0 will allow you to easily integrate support for the protocol in your own applications.

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

Because greylisting temporarily rejects the first email message from a sender that it does not recognize, it forces the sender’s mail server to retain the message and queue it for another delivery attempt. The interval at which messages are resent depends on its configuration, and can be anywhere from ten minutes up to several hours. This can present a problem to businesses that depend on email, particularly with anything that is of a time-sensitive nature. Neither the sender nor the recipient have any direct control over the amount of time that the server will wait before resending the message. To avoid the delay, the sender can be whitelisted, however this typically requires some action on the part of an administrator. While greylisting can help reduce spam, it also inherently reduces the reliability of email.

Another problem with greylisting is how some mail servers handle the initial rejection. If the recipient’s mail server doesn’t recognize the sender’s email address, it will respond with a 450 error (or another status code in the 400-499 range). This should tell the sender’s mail server that it cannot accept the message at that time, and it should attempt to resend the message at some point in the future. However, some mail servers will treat that error as a permanent rejection. Instead of resending the message, the server considers the email to be undeliverable and bounces it back to the sender. As a result, the sender will typically think that the email address is no longer valid.

Greylisting also imposes additional workload and storage requirements on the sender’s mail server. It is forced to establish twice the number of connections to deliver the message, and it’s required to store that message until redelivery completes. For individuals or smaller organizations, that’s not a significant problem. But for companies that have a very high volume of mail, greylisting can cumulatively increase the CPU time, network bandwidth and disk space required to deliver messages. If greylisting could be used instead of filtering, there’s no question that the net result would be a reduction in resource utilization on the sender’s mail server. However, because filtering will still be required, both methods are used and the result is an overall increase in resource utilization.

Ultimately, greylisting works by taking advantage of a deficiency in how most spamware is currently written, but it’s not a long-term solution. As greylisting becomes more widespread, the spammers will adapt to it. More and more of the programs that they use to deliver their spam will have the ability to queue and resend messages, which means that in the long run it has simply increased the amount of time and network traffic required to send an email message.