Winsock Programmer’s FAQ
Section 1: General Winsock Information
“Winsock” is short for Windows Sockets, referring to the BSD Sockets API it is derived from.
Aside: You may find old or pedantic material using the original camel-case form, WinSock. Microsoft spells it “Winsock” these days, and this FAQ has done so since I took on the maintenership role.
The Winsock specification defines a network programming interface for Microsoft Windows which is based on the “socket” paradigm popularized in BSD Unix. It encompasses both familiar Berkeley socket style routines and a set of Windows-specific extensions:
Winsock 1 apps can ask Winsock to send notifications in window messages. This allows your program to handle both the network, UI issues, and background processing without having to worry about concurrency.
Winsock 2 adds many features. See below for details.
Winsock 2.x defines two interfaces: an application programming interface (API) which shields application developers from underlying layers, and a service provider interface (SPI) which allows transparent extensions to a Winsock stack. Through proper use of the API, a Winsock application can work over various network transport protocols and Winsock implementations.
(By the way, most people just say “Winsock 2” when speaking of the current version of Winsock, because the newer versions just contain edits and clarifications to the original spec.)
Networks are made of several layers. Network people talk about those layers in terms of the OSI network model.
TCP/IP is a network protocol, meaning that it is at layers 3 through 4 in the OSI model. A network protocol provides services like addressing, data transport, routing, and logical connections across a network. Two computers must use the same network protocol if programs running on those computers are to communicate. Other common network protocols include Novell’s IPX, 3Com/IBM/Microsoft’s NetBIOS and Apple’s AppleTalk. TCP/IP is the most popular network protocol today: virtually all computers support it.
Winsock is an API that lets a Windows program send data over any
network transport protocol. There are several functions in Winsock
that only work with TCP/IP (e.g.
gethostbyaddr()), but there
are newer generic versions of all these in Winsock 2 which allow you
to use other transports.
One of the most important new features is official support for multiple transport protocols. Although Winsock 1.1 was not actually limited to TCP/IP, that was the only protocol that had official support written into the spec. There was no standard way for a vendor to add support for another transport protocol, though a few vendors did do proprietary implementations of other protocols. With Winsock 2, official support for OSI, Novell IPX/SPX and Digital’s DECNet exists in the spec, and it’s now possible to add support for other protocols in a standard way. More importantly, a program can be written to be transport-independent, so that it works with all of these protocols, without change.
Winsock 2 also adds support for technical initiatives like quality of service (QoS) and multicasting. These technologies will become increasingly important as bandwidth requirements become more regimented and intense. For example, QoS allows a videoconferencing program to reserve a certain amount of bandwidth so that a sudden file transfer, for example, doesn’t cause its video to begin breaking up due to a lack of bandwidth. Multicasting allows that videoconferencing application to send audio and video streams to many participants without duplicating data any more than absolutely necessary.
Winsock 2 works with Win32’s high-efficiency overlapped I/O mechanism. Since this is handled entirely in the kernel in modern versions of Windows, there are significant speed advantages over the more traditional I/O styles supported by Winsock 1.1.
Winsock 2 also allows for “Layered Service Providers.” This enables many neat things, such as security plug-ins: drop in, say, an SSL service provider, and all of a sudden your data is automatically encrypted.
There are a number of other additions to the spec. You can get a complete list of them on sockets.com’s Winsock 2 Overview page.
For reasons I discuss elsewhere, there is no longer a need for new Winsock specifications. The current specification for Winsock is simply “whatever Microsoft stacks do today.” Microsoft now documents these things in the MSDN Library, not a separate spec. (Of course, Windows has undocumented features, too.)
Winsock is not the only place Microsoft adds new networking functionality. Sometimes they create entirely new APIs, like IP Helper, or the Internet Explorer ActiveX control. These complement Winsock without directly affecting it. Sometimes, they aren’t even based on Winsock, instead talking to lower-level APIs like the TDI or NDIS layers.
Winsock 1.1 only had support for TCP/IP in the spec. Several vendors’ Winsock 1.1 stacks did have support for other transports, but the point is that this was never standardized in the Winsock 1.1 specification.
Winsock 2 standardized support for DECNet, IPX/SPX and OSI transports, and the spec defines a standardized way for adding support for additional transports.
||Information for New Winsockers >>|
|Updated Mon Sep 22 2014 20:57 MDT||Go to my home page|