Windows* Sockets 2 Application Programming Interface An Interface for Transparent Network Programming Under Microsoft Windowstm revision 2 August 7, 1997
Making Transport Protocols Available To WinSock
Download 1.64 Mb.
|
- Navigate this page:
- 15 Layered Protocols and Protocol Chains
- 16 Using Multiple Protocols
- 17 Multiple Provider Restrictions on select()
14 Making Transport Protocols Available To WinSockIn order for a transport protocol to be accessible via WinSock it must be properly installed on the system and registered with WinSock. The WinSock 2 DLL exports a set of APIs to facilitate the registration process. These include creating a new registration and removing an existing one. When new registrations are created the caller (presumed to be the stack vendor’s installation script) supplies one or more filled in WSAPROTOCOL_INFO structs which contain a complete set of information about the protocol. Please refer to the SPI document for details on how this is accomplished. Note that transport stacks that are thus installed are considered to be WinSock service providers, and hereafter are referred to as such. The WinSock 2 SDK includes a small Windows applet called SPORDER.EXE that will allow the user to view and modify the order in which service providers are enumerated. Using this applet, a user may manually establish a particular TCP/IP protocol stack as the default TCP/IP provider if more than one such stack is present. The functions that this applet uses to reorder the service providers are exported from a DLL (SPORDER.DLL). As a result, installation applications may use the interface of SPORDER.DLL to programmatically reorder service providers, to suit their needs. Please refer to the Service Provider Interface document for a detailed description of the interface. 15 Layered Protocols and Protocol ChainsWinSock 2 accommodates the notion of a layered protocol. A layered protocol is one that implements only higher level communications functions, while relying on an underlying transport stack for the actual exchange of data with a remote endpoint. An example of such a layered protocol would be a security layer that adds protocol to the connection establishment process in order to perform authentication and to establish a mutually agreed upon encryption scheme. Such a security protocol would generally require the services of an underlying reliable transport protocol such as TCP or SPX. The term base protocol refers to a protocol such as TCP or SPX which is fully capable of performing data communications with a remote endpoint, and the term layered protocol is used to describe a protocol that cannot stand alone. A protocol chain is defined as one or more layered protocols strung together and anchored by a base protocol. This stringing together of one or more layered protocols and a base protocol into chains can be accomplished by arranging for the layered protocols to support the WinSock 2 SPI at both their upper and lower edges. A special WSAPROTOCOL_INFO struct is created which refers to the protocol chain as a whole, and which describes the explicit order in which the layered protocols are joined. This is illustrated in Figure 3. Note that since only base protocols and protocol chains are directly usable by applications, only these protocols are listed when the installed protocols are enumerated with WSAEnumProtocols(). 
Figure 3 Layered Protocol Architecture 16 Using Multiple ProtocolsAn application may use WSAEnumProtocols() to discover which transport protocols and protocol chains are present and obtain information about each as contained in the associated WSAPROTOCOL_INFO struct. In most instances, there will be a single WSAPROTOCOL_INFO struct for each protocol or protocol chain. Some protocols however, are able to exhibit multiple behaviors. For example the SPX protocol is message-oriented (i.e. the sender’s message boundaries are preserved by the network), but the receiving end may choose to ignore these message boundaries and treat the socket as a byte stream. Thus there could reasonably be two different WSAPROTOCOL_INFO struct entries for SPX, one for each of these behaviors. Whereas in WinSock 1.1 there is a single address family (AF_INET) comprising a small number of well-known socket types and protocol identifiers, the focus will shift for WinSock 2. The existing address family, socket type and protocol identifiers are retained for compatibility reasons, but many new address family, socket type and protocol values will appear which are unique but not necessarily well known. Not being well known need not pose a problem since applications that desire to be protocol-independent are encouraged to select protocols for use on the basis of their suitability rather than the particular values assigned to their socket_type or protocol fields. Protocol suitability is indicated by the communications attributes (e.g. message vs. byte-stream oriented, reliable vs. unreliable, etc.) contained within the protocol’s WSAPROTOCOL_INFO struct. Selecting protocols on the basis of suitability as opposed to well-known protocol names and socket types allows protocol-independent applications to take advantage of new transport protocols and their associated media types as they become available. In terms of the well-known client/server paradigm, the server half of a client/server application will benefit by establishing listening sockets on all suitable transport protocols. The client, then, may establish its connection using any suitable protocol. This would enable, for example, a client application to be unmodified whether it was running on a desktop system connected via LAN or on a laptop using a wireless network. A WinSock 2 clearinghouse has been established for protocol stack vendors to obtain unique identifiers for new address families, socket types and protocols. FTP and world-wide web servers are used to supply current identifier/value mappings, and email is used to request allocation of new ones. At the time of this writing the world-wide web URL for the Windows Sockets 2 Identifier Clearinghouse is http://www.stardust.com/wsresource/winsock2/ws2ident.html 17 Multiple Provider Restrictions on select()In WinSock 2 the FD_SET supplied to the select() function is constrained to contain sockets associated with a single service provider. This does not in any way restrict an application from having multiple sockets open using multiple providers. When non-blocking operations are preferred the WSAAsyncSelect() function is the solution. Since it takes a socket descriptor as an input parameter, it doesn’t matter what provider is associated with the socket. When an application needs to use blocking semantics on a set of sockets that spans multiple providers, the recommended solution is to use WSAWaitForMultipleEvents(). The application may also choose to take advantage of the WSAEventSelect() function which allows the FD_XXX network events to be associated with an event object and handled from within the event object paradigm (described below). Download 1.64 Mb. Share with your friends:
|