System Architecture

System Architecture

Before getting into the system architecture, it is important to mention that applications should not rely on the specific details mentioned in this chapter (names of drivers, DLLs, etc.) as they may change in future releases. Instead, applications should be concerned with the Winsock specification—but it is also important to have a general understanding of the overall system design. The following section pertains mainly to the Windows NT–based operating systems. At the end of this section, we will note some of the differences between Windows NT and Windows 95, Windows 98, and Windows Me.

The majority of the Winsock API is implemented in WS2_32.DLL and is declared in WINSOCK2.H. The only exception is for the Microsoft–specific Winsock extensions (such as TransmitFile, AcceptEx, etc.), which are located in MSWSOCK.DLL. These extensions are not a part of the formal Winsock specification but have been added by Microsoft. Also, because these are Microsoft-specific extensions and are not part of the formal Winsock specification, some of the extension APIs are available only on certain versions of Windows. Chapter 6 covers these APIs in detail.

When an application calls into the Winsock API, it calls into WS2_32.DLL. The Winsock DLL performs some parameter validation and then determines which protocol service provider the call should be routed to. There may be multiple providers installed in the Winsock catalog and WS2_32.DLL determines which provider should handle the call.

There are two types of providers: base and layered. A base provider sits on top of a transport protocol, such as Microsoft TCP/IP and UDP/IP providers or the Resource Reservation Protocol (RSVP) provider, which implements QOS (Chapter 10). The Microsoft base provider consists of MSAFD.DLL and MSWSOCK.DLL, but actually exposes one or more providers for the individual protocols of TCP/IP, IPX/SPX, NetBIOS, AppleTalk, etc. Later in this chapter we'll describe how to programmatically enumerate the providers available on the system.

A layered provider sits below WS2_32.DLL and above a base provider and can intercept and manipulate the Winsock calls. That is, if an application creates a socket from the layered provider, the layered provider will intercept all Winsock calls using that socket. The layered provider may block, modify, or pass the call unmodified to the underlying provider. Also, there may be numerous layered providers installed, one on top of another. Layered service providers are covered in detail in Chapter 12.

Once a Winsock call makes it to the base provider, the base provider will in turn make calls to the Winsock kernel mode component. Unlike some other operating systems, the Windows NT transport protocols do not have a Winsock-like interface that applications can use to directly talk to them. Instead, they implement a much more general API called the Transport Driver Interface (TDI). The generality of this API allows the Windows NT subsystems to free themselves from being tied to a particular version-of-the-decade network-programming interface. The sockets emulation is provided by the Winsock kernel mode driver (currently implemented in AFD.SYS). This driver is responsible for the connection and buffer management related to providing a sockets-like interface to an application. AFD, in turn, talks TDI to the transport protocol driver (see Figure 2-1).

For Windows 95, Windows 98, and Windows Me, the overall architecture is similar to Windows NT except for the kernel mode components. Since Windows 95, Windows 98, and Windows Me implement drivers within VXDs, there is no AFD.SYS or TCPIP.SYS. Instead, the drivers are AFVXD.VXD, WSOCK2.VXD, WSOCK.VXD, and so on. Of course, as we stated earlier, applications should not concern themselves with the actual filenames of drivers or system components. The Winsock API is a specification that is available across all versions of the Windows operating system.

Figure 2-1 Winsock system architecture