This post is mainly talking about the Windows Sockets API, which can be shortened to WSA and Winsock. After reading this post, you can know its definition, background, technology, as well as implementations.
Definition to Winsock
What is Winsock? In computing, Winsock is a technical specification used to define how Windows network software should access network services, especially TCP/IP. It is called Winsock because it is an adaptation of the Berkeley UNIX socket interface to Windows. A socket is a special agreement used to connect with and exchange data between two program processes on the same computer or network.
Winsock is the abbreviation of the Windows Sockets API (WSA). It defines the standard interface between Windows TCP/IP client applications (such as FTP clients or Web browsers) and the basic TCP/IP protocol stack.
Related post: Use Netsh Winsock Reset Command to Fix Windows 10 Network Problem
Background of Winsock
The Windows Sockets API was proposed by Martin Hall of JSB Software (later Stardust Technologies) in the “BoF” (Bird of a Feather) discussion on the CompuServe BBS network in October 1991.
The first version of the specification was written by Martin Hall, Mark Towfiq of Microdyne (later Sun Microsystems), Geoff Arnold of Sun Microsystems, and Henry Sanders and J Allard of Microsoft with the help of many others.
There were some discussions on how to best resolve copyright, intellectual property, and potential antitrust issues, and consideration of work through the IETF or the establishment of non-profit foundations. In the end, it was decided that the specification should only be copyrighted by five (unaffiliated) authors.
All participating developers refused to abbreviate the name to simply Winsock for a long time because there was a lot of confusion between the API and the DLL library file (winsock.dll), which only exposed the general WSA interface to the application above it. It is generally believed that only ensuring that the DLL file exists on the system can provide complete TCP/IP protocol support.
Technology of Winsock
The Windows Socket API specification defines two interfaces: API used by application developers, and SPI that provides a method for network software developers to add new protocol modules to the system. Each interface represents a contract.
The API guarantees that conforming applications can run normally with any network software vendor’s conforming protocol implementation. The SPI contract guarantees that conforming protocol modules can be added to Windows so that they can be used by API-compliant applications.
Although these contracts were important when Windows Sockets was first released, they are only of academic significance now because the network environment requires multi-protocol support. The Windows Sockets API version 2.0 includes the function of using IPX/SPX, although this protocol was almost obsolete when WSA 2.0 left the factory.
The Windows Sockets code and design are based on BSD sockets, but additional features are provided to allow the API to conform to the conventional Windows programming model.
The Windows Sockets API almost covered all the features of the BSD sockets API, but there are some inevitable obstacles, which were mainly caused by the fundamental differences between Windows and Unix (although the difference between Windows Sockets and BSD sockets was less than the difference between the latter and STREAMS).
However, the design goal of Windows sockets was to make it relatively easy for developers to port socket-based applications from Unix to Windows. It was not enough to create APIs that were only useful for newly written Windows programs.
Therefore, Windows Sockets contained many elements designed to facilitate porting. For example, Unix applications could use the same errno variable to log network errors and errors detected in standard C library functions.
Since it cannot be implemented in Windows, the Windows Sockets introduced a special function, WSAGetLastError(), to retrieve error information. Such a mechanism was very helpful, but application porting was still extremely complicated.
Many primitive TCP/IP applications have been implemented by using system features specific to Unix (such as pseudo terminals and fork system calls), and it was problematic to reproduce this function in Windows. In a relatively short time, porting gave way to the development of dedicated Windows applications.
Implementations of Winsock
- Microsoft did not provide an implementation of Winsock 1.0.
- Version 1.1 of Winsock was provided in an add-on package (called Wolverine) for Windows for Workgroups (code named Snowball).
- Winsock version 2.1 was provided in an add-on package for Windows 95.
- The latest version of Winsock 2.x has been provided with the new Windows version or as part of a service pack.
- Winsock 2 can be extended through a mechanism called Layered Service Provider (LSP).