Windows Sockets: The Next Generation Winsock 2.0 may make it easy for applications to intercommunicate across diverse platforms in multi-protocol networks.

July  1995

Hoping to ride on the coattails of popular Winsock 1.1, Windows Sockets 2.0 promises to enlarge the market possibilities for network-aware applications and cure some developers' headaches. With the Winsock 2.0 API in its final stages of development, a new generation of products is poised to emerge -- products that can provide better intercommunication among applications in a uniform manner on several of the most popular networking protocols. But Winsock 2.0 will also create a few problems.

Mail this article to a friend

As Po, Cain's Master from the old TV series Kung Fu, might have said, "Unity is harmony with all others." Such a promise of unity is hinted at within the Windows Sockets 2.0 (Winsock 2.0) standards. Winsock largely fulfills the dreams of application developers who seek to create platform-neutral communication between two systems.

Originally released in 1991, the current popular incarnation (version 1.1) has grabbed the attention of PC TCP/IP programmers as well as those using other network protocols. In its latest incarnation, other protocols have been added to further ease developers' burden of writing good portable network software for the Windows family.

The provisional release of the Windows Sockets 2.0 standards on May 12 brought forth a new standard for programmers, letting them create network applications using a fixed API set that could be transferred to other systems in the Windows family -- even those using networking software from different vendors. At the same time, Winsock 2.0 allows networking software vendors to create an implementation of their network protocols that would cleanly fit into the Windows Open Systems Architecture (WOSA), the latest herald of standards for the Windows family of products.

With the development of the Winsock 2.0 API in its final stages, companies are gearing up to release a new generation of products that can provide better intercommunication between applications in a uniform manner on several of the most popular networking protocols. Winsock 2.0 now formally supports the current version of TCP/IP known as IPv4 (version 4), the next generation of IP known as IPv6 (version 6), the Novell IPX/SPX, Digital Equipment Corp.'s DECnet, the ISO's Open Systems Interconnect (OSI), and Apple Computer's AppleTalk protocols.

In addition to these network protocols, Winsock includes provisions for network hardware technology including ISDN, wireless networking, and (in the future) asynchronous transfer mode (ATM). Older and more proprietary protocols such as IBM's Systems Network Architecture (SNA) and the Banyan's Vines protocols have been left behind deliberately; the implementors determined that there would not be enough demand for such protocols. (The actual reasons behind their exclusion may be hidden within the minds of the standards developers. Whether they wished to promote open protocols or simply reduce their own competition are motives known only by Microsoft, Novell, and the others with vested interests in the network operating system market.)

Neutral layers
The new standards create two neutral layers between the application and the actual stack that communicates with the Network Interface Card drivers: the Application Programming Interface (the Winsock 2.0 API) and the Service Provider Interface (the Winsock 2.0 SPI) (see below).

• Microsoft will include a TCP/IP stack for Winsock 2.0 in Windows95 and newer releases of Windows NT. I doubt Microsoft will do the same for its current Windows 3.1 and Windows for Workgroups.
• Intel suggested it may write a stack to support all Intel-based PCs, including the mass of DOS and Windows 3.1 users who can't or won't upgrade to Windows95.
• Novell, a key member of the Windows Sockets consortium, is reportedly considering an IPX/SPX stack.
• DECnet and AppleTalk stacks are still up in the air. If anyone tackles these projects it'll be their progenitors, Digital and Apple, respectively.
• IPv6 stacks are also undecided today. The newness of IPv6 is a problem in itself. Today's IPv6 trials are of limited scope and routers for this new protocol are barely out of the labs. It may take a while before the IPv6 stack nears the end of the experimental trials and is deployed.
• The fate of the ISO stack is anyone's guess. An experimental software trial may take place, but despite support from many stalwarts, the commercial viability for OSI dwindles.

Certified vs. compliant
The Winsock 2.0 API supports the current favorite version, 1.1. This maintains backward compatibility with the host of programs that have been converted from their proprietary APIs to the Windows Sockets formula. As it stands, Winsock 2.0 will solve and create a few problems. Certified "Winsock compliant" applications will have no problems transferring to the new system. The majority of applications, however, are "Winsock compatible" rather than compliant, indicating that while they do use the Winsock-standard API calls, they have not been certified or completely tested for any misuse of loopholes or disregard for the API. Nonetheless, a number of these compatible programs will survive. Other compatibility problems could arise in programs that use proprietary IPX implementations of Winsock 1.1, such as one from Spry, and those requiring raw IP (raw sockets) services. A better solution would be to rewrite the application according to the new 2.0 standard. Many of the function calls at the API layer have been retained and expanded to include other services. In addition, newer function calls have been added. Others have become obsolete and exist only to retain backward compatibility. Usually, this occurs when a new function can provide the same services as the older one in addition to other services. For the sake of optimization, it might also be necessary to examine current Winsock 1.1 programs in the light of the 2.0 API standard.

Multiprotocol support
Although most applications programs use only one protocol for communications with one another, there is no good reason that they should limit themselves to one. Ideally, applications would use the most available or efficient protocol that supports the needed services. A programmer can query the system for the protocols and types of services that it can support. If, for example, you have an X Window server that needs to communicate via TCP/IP with Unix hosts while at the same time running as a NetWare client, you could effectively minimize the traffic on the network by using one protocol or the other only. (Note there are X Window servers for IP as well as IPX.) Alternatively, the X Window server could use TCP/IP to communicate with the Unix host directly; if this fails, the X server can seek out an IPX-to-IP gateway on a NetWare server elsewhere on the network, thus allowing a fallback mechanism through a less direct method. This kind of strategy can be applied broadly. For example, SMTP e-mail can be rerouted by an intelligent mail agent over NetWare MHS in case of failure. Multiprotocol support requires skill on the part of the development team, but provides a much more robust application capable of withstanding more than simple protocol or network failure.

Turning heads
The success of Windows Sockets 1.1 in the marketplace has turned quite a few heads. It is not often that a multi-vendor effort gains so much positive attention. Part of the success may be attributed to the fact that project leadership was provided principally by technical developers with few management units. Winsock 1.1 also benefits from being a standard freely available for developers without ignoring vendors' interests. However, as soon as Winsock 1.1 became popular, problems began to appear; it became a label that was attached to any piece of network software using TCP/IP -- and even some other protocols -- although some of the applications developed still partially used proprietary mechanisms. Others were clamoring for the adoption of Winsock to their own protocols. This, combined with increased vendor interest in the standard, inspired Winsock 2.0. With version 2.0, Winsock's expanded capability enlarges the market possibilities for networked applications development. In addition, it reduces the burden on the part of the user or system administrator who has to install such services. It does, however, create problems for programmers who have been developing software using other APIs, such as the NetWare implementation of the Transport Layer Interface (TLI), the AppleTalk programming interface, and the like. Attempts to overcome their inertia and convert these programmers to a new discipline may cause headaches and possibly even (programmer) tribal disputes. Depending on the outcome, Winsock 2.0 may be left primarily within the realm of Windows TCP/IP developers with very few other converts. I hope, however, that Windows Sockets 2.0 will become more than just a ballyhooed buzzword and emerge as a staple of Windows-based network developers of all sorts, everywhere. I believe Winsock 2.0 offers a bright glimpse at a more unified and less hacked-together system that we call Windows. Then again, maybe I've watched one too many reruns of Kung Fu.

If you have technical problems with this magazine, contact webmaster@sunworld.com

URL: http://www.sunworld.com/swol-07-1995/swol-07-connectivity.html
Last modified: