Winsock API

Winsock is an API that allows Windows-based applications to access the transport protocols. Winsock in Windows 2000 is a protocol-independent networking API. Winsock is the Windows 2000 implementation of the widely-used Sockets API, the standard for accessing datagram and session services over TCP/IP, NWLink IPX/SPX NetBIOS, and AppleTalk. Applications written to the Winsock interface include File Transfer Protocol (FTP) and Simple Network Management Protocol (SNMP). Winsock performs the following:

• Provides a familiar networking API for programmers using Windows or UNIX.

• Offers binary compatibility between the heterogeneous, Windows-based TCP/IP stack and utility vendors.

• Supports both connection-oriented and connectionless protocols.

Windows 2000 includes Winsock 1.1 support. Winsock 2.0 extends the Winsock 1.1 interface to provide access to networks using protocols other than TCP/IP, such as NetWare and AppleTalk. Winsock 2.0 provides the following enhancements over Winsock 1.1:

• Name registration and resolution.
  Winsock 2.0 provides an interface that applications can use to access many different namespaces, such as Domain Name System (DNS), Novell Directory Services (NDS), and X.500.

• Support for real-time multimedia communications.
  Winsock supports several multimedia enhancements, including Quality of Service (QoS).

• Protocol-independent multipoint and multicast.
  Winsock 2.0 enables applications to take advantage of the multipoint and multicast capabilities of transport stacks.

Winsock Architecture

Winsock 2.0 is a Windows Open Systems Architecture (WOSA)–compliant interface that enables a front-end application and a back-end service to communicate. The Winsock 2.0 interface includes the following components:

• The Winsock 1.1 Application Programming Interface (API)

• The Winsock 2.0 Application Programming Interface (API)

• The Winsock 2.0 Transport Service Providers

• Layered Service Providers

Figure B.11 shows the Winsock 2.0 architecture.

Figure B.11 Winsock 2.0 Architecture

Winsock Files

Table B.1 contains a list of files that Winsock uses to function. The table lists the files in order of the layer that they support and gives a brief description of their function.

Table B.1 Winsock Files

Winsock 1.1 API

Winsock 1.1 API is a thunk layer. A thunk layer translates the output from a component into a form another component can use. Winsock 1.1 layer commands are converted to Winsock 2.0 layer commands to allow backward compatibility for legacy applications.

Winsock 2.0 API

Winsock 2.0 API is the interface for Winsock 2.0. For example, it helps Winsock 2.0 to add new APIs (such as Generic Quality of Service). Winsock 2.0 API is located between the Winsock 2.0 dynamic link library (DLL) and a Winsock 2.0 application.

Winsock 2.0 SPI Transport Service Providers

Transport service providers give applications a consistent interface for accessing multiple transport protocols. Located above the transport service provider, the Winsock 2.0 DLL takes requests from applications and sends those requests to the transport service provider. The Winsock 2.0 DLL also provides traffic management. The transport service provider can support one or more transport protocols.

Layered Service Provider Layer

An optional Layered Service Provider layer can be inserted between the Winsock 2.0 DLL and the underlying protocol stack if required by an application. It can extend the underlying protocol stack by providing additional services such as authentication, encryption, or proxy server services.

Winsock Helper DLLs

Winsock helper DLLs provide specific software components to assist Winsock 2.0. Transport protocols such as TCP, ATM, and IrDA have DLLs that supply the necessary program code to support Winsock.

Winsock 2.0 Name Resolution Providers

Name resolution providers enable server and client applications to use a consistent interface for multiple name services. Services register with the Winsock DLL, and client applications send requests for the names of those services to the Winsock DLL. The Winsock DLL manages registration and loading of name resolution providers and sends name resolution operations to the correct provider. Finally, the provider implements an interface with existing name services, such as DNS.

Generic Quality of Service and Resource Reservation Protocol

Connectionless networks (such as Ethernet networks) make only a best effort to deliver packets to their destination. There is no guarantee that packets will arrive, or that they will arrive in the correct order. Instead, protocols such as TCP/IP were developed to ensure retransmission of lost packets and to ensure that out-of-order packets could be reassembled in the correct order. This is sufficient for most applications, such as e-mail. However, for newer applications, such as real-time audio and video, packets must arrive on time and in order or the transmission might be garbled.

Connection-oriented networks enable applications to request certain levels of service, such as bandwidth and reliability, for specific connections. Additionally, they enable computers to set up several different connections with several different qualities of service. For example, on a connection-oriented network, two simultaneous connections can support both a high-delay low-bandwidth connection to send e-mail and a high-bandwidth, low-delay connection for a videoconferencing application.

Windows 2000 makes different service levels possible through its Generic Quality of Service (GQoS) APIs and its support for the ** Resource Reservation Signaling Protocol (RSVP). Applications can request different network characteristics for a connection. RSVP then handles those requests by attempting to make bandwidth reservations for that connection.

Generic Quality of Service

The GQoS APIs in Winsock 2.0 provide access to most QoS levels of service. The underlying QoS providers make it possible to utilize these levels of service directly from the GQoS APIs. Applications can make calls to GQoS APIs and request attributes such as:

• Peak bandwidth (average or peak bit rate available).

• Latency (the maximum acceptable delay between transmission of a bit and its receipt by the receiver).

• Delay variation (the difference between a packet's minimum and maximum delay).

Figure B.12 shows the architecture of GQoS.

Figure B.12 GQoS Architecture

The GQoS components are:

• RSVP Service Provider
  The QoS component that invokes nearly all QoS functions and services. RSVP Service Provider (rsvpsp.dll and rsvp.exe) starts traffic control and implements, maintains, and handles RSVP signalling for all of Windows 2000 QoS functions.

• Traffic Control API
  A programmatic interface for the traffic control components that regulate network traffic on local hosts. It regulates traffic internally (within the kernel) and on the network. (It also prioritizes and queues packets based on transmission priority.)

• Generic Packet Classifier (GPC)
  Classifies and prioritizes packets, it has the ability to provide lookup tables and classification services within the network stack.

• Afd.sys
  This Winsock Kernel Interface provides access to the TDI transports.

• QoS Packet Scheduler
  This traffic control module regulates how much of the data an application is allowed to transmit at one time, thereby enforcing QoS parameters that are set for a particular flow.

Quality of Service Admission Control Service

The QoS Admission Control Service is responsible for regulating subnet usage for QoS-enabled components.

Figure B.13 illustrates the QoS Admission Control Service architecture.

Figure B.13 QoS Admission Control Service

The QoS ACS administers subnet bandwidth resources that are necessary to ensure QoS transmission of data. The QoS ACS operates on a Windows 2000 Server residing on a subnet. On the shared segments, all QoS reservation messages are routed through the QoS ACS, so subnet clients can share their bandwidth and the administration of bandwidth allocation can be centralized. The QoS ACS sends messages, called beacons , to let other clients on the network know it is present and ready to receive subnet bandwidth reservation requests. QoS Admission Control Service components govern QoS-enabled applications. The QoS ACS must be installed in a server that does not have QoS components present.

The QoS ACS components are:

• Quality of Service Admission Control Service (QoS ACS)
  A QoS component that regulates subnet usage for QoS-enabled applications. The QoS ACS exerts its control over QoS-aware applications or clients by placing itself within the RSVP message path. The QoS ACS intercepts Resource Reservation Protocol (RSVP) and Reservation (RESV) messages and passes the messages with the user information to Local Policy Modules for authentication. RSVP messages are sent to request transmission characteristics and RESV messages confirm that the transmission characteristics can be granted.

• Policy Control Module (PCM)
  Mediates the interaction between the QoS ACS and LPMs. PCMs send user information to each LPM and gathers all the responses, then performs logical checks on the information. The PCM gathers the information and sends it as one response to QoS ACS.

• Local Policy Module (LPM)
  The API that communicates with the QoS Admission Control Service. The LPM API also specifies how LPMs are registered and initialized within the construct of QoS ACS.

• Active Directory
  Provides a single point of management for Windows-based policies, user accounts, clients, servers, and applications. In QoS, Active Directory stores information about the levels of service that GQoS uses.

• Custom Policy Server
  A third-party component that can be used to store policies for GQoS levels of service.

Applications request QoS levels of service. The RSVP signaling provider negotiates with the network for the requested levels of service. The packet classifier and scheduler determine when to send the packets and with what priority. Finally, the QoS-aware router forwards the packets as requested.

For more information about QoS and RSVP, see "Quality of Service" in this book.