Network Computingwww.networkcomputing.com

When it was introduced, WinSock was a major leap forward for users and application vendors alike. But compatibility problems have followed it. Some protocol stack vendors add proprietary calls to their WINSOCK.DLL (Microsoft Corp. is one). Application developers finding these extra features have exploited them. But when an application is run with a WINSOCK.DLL other than the one it was written for, problems arise. For example, large ISPs, such as America Online, have wreaked havoc when their install routines overwrote any WINSOCK.DLL located on the system--often rendering unusable working applications. Just as bad, many applications install their own WINSOCK.DLL files on the system. Depending on which WINSOCK.DLL the system found first, the applications might not work.

WinSock 1.1 has been very successful--proof is in the thousands of applications available commercially and those availab le as freeware and shareware.

WinSock 2 was born in May 1994 when work began to expand the usefulness of the WinSock 1.1 specification. Engineers from Intel Corp., Microsoft, Motorola, FTP Software, Novell and others have come together with a number of goals in mind to pave the way for the WinSock 2 specification. For example, they wanted to add filters to some Internet protocols--such as a filter for Web traffic to keep kids out of pornographic chat rooms. In addition, they wanted WinSock to use more than just the TCP/IP protocol.

Version 2 met these goals--and exceeded them. Among the new features are quality of service (QoS) or bandwidth reservation, protocol-independent name resolution, protocol-independent multicast and multipoint support, and conditional acceptance.

WinSock 2 provides the same basic programming techniques set forth in version 1.1, and developers can use these to design applications based on other protocols, such as IPX/SPX. WinSock 2 also provides a method for locating services in a protocol-independent manner. Additionally, through the use of WinSock's conditional acceptance, applications such as FTP or HTTP can "peek" into the network address of a connecting party and permit or deny access based on a predefined set of rules. This allows a higher grade of security for servers.

Although single-protocol backbones are all the rage, most networks run more than one transport protocol. With WinSock 2, applications can be written to the API, independent of the underlying transport. Pre-version 2 implementations provided support for IPX/SPX, but a standard means to use this API did not exist. Don't expect to see many applications make use of the transport-independent feature of the WinSock 2 spec. In-house development efforts will most likely benefit--developers will need to learn only one programming specification.