Windows* Sockets 2 Application Programming Interface An Interface for Transparent Network Programming Under Microsoft Windowstm revision 2 August 7, 1997
Download 1.64 Mb.
|
34 Socket GroupsReserved for future use with socket groups: WinSock 2 introduces a number of function parameters, data types, structure members, and manifest constant values that are reserved for future use in grouping sockets together. As of the version 2.2.1 of the specification, the intended future use of these items is fully described, however, none of the group-related parameters is interpreted in software releases corresponding to the version 2.2.1 specification. Since a client always has the option to elect not to use socket groups, there are always default values and behaviors defined for group-related definitions. It is simple for an application that does not wish to use socket groups to use default values in such a fashion that the application will not be harmed if and when socket groups are “turned on” in the future. Definitions related to socket groups are marked in version 2.2.1 specification with the phrase: “Reserved for future use with socket groups” preceding the description of the intended future use. WinSock 2 introduces the notion of a socket group as a means for an application (or cooperating set of applications) to indicate to an underlying service provider that a particular set of sockets are related and that the group thus formed has certain attributes. Group attributes include relative priorities of the individual sockets within the group and a group quality of service specification. Applications needing to exchange multimedia streams over the network are benefited by being able to establish a specific relationship among the set of sockets being utilized. As a minimum this might include a hint to the service provider about the relative priorities of the media streams being carried. For example, a conferencing application would want to have the socket used for carrying the audio stream be given higher priority than that of the socket used for the video stream. Furthermore, there are transport providers (e.g. digital telephony and ATM) which can utilize a group quality of service specification to determine the appropriate characteristics for the underlying call or circuit connection. The sockets within a group are then multiplexed in the usual manner over this call. By allowing the application to identify the sockets that make up a group and to specify the required group attributes, such service providers can operate with maximum effectiveness. WSASocket() and WSAAccept() are two new functions used to explicitly create and/or join a socket group coincident with creating a new socket. Socket group IDs can be retrieved by using getsockopt() with option SO_GROUP_ID. Relative priority can be accessed by using get/setsockopt() with option SO_GROUP_PRIORITY. 35 Shared SocketsWSADuplicateSocket() is introduced to enable socket sharing across processes. A source process calls WSADuplicateSocket() to obtain a special WSAPROTOCOL_INFO structure for a target process ID. It uses some interprocess communications (IPC) mechanism to pass the contents of this structure to a target process. The target process then uses the WSAPROTOCOL_INFO structure in a call to WSPSocket(). The socket descriptor returned by this function will be an additional socket descriptor to an underlying socket which thus becomes shared. Note however, that sockets may be shared amongst threads in a given process without using the WSADuplicateSocket() function, since a socket descriptor is valid in all of a process’ threads. The two (or more) descriptors that reference a shared socket may be used independently as far as I/O is concerned. However, the WinSock interface does not implement any type of access control, so it is up to the processes involved to coordinate their operations on a shared socket. A typical use for shared sockets is to have one process that is responsible for creating sockets and establishing connections, hand off sockets to other processes which are responsible for information exchange. Since what is duplicated are the socket descriptors and not the underlying socket, all of the state associated with a socket is held in common across all the descriptors. For example a setsockopt() operation performed using one descriptor is subsequently visible using a getsockopt() from any or all descriptors. A process may call closesocket() on a duplicated socket and the descriptor will become deallocated. The underlying socket, however, will remain open until closesocket() is called with the last remaining descriptor. Notification on shared sockets is subject to the usual constraints of WSAAsyncSelect() and WSAEventSelect(). Issuing either of these calls using any of the shared descriptors cancels any previous event registration for the socket, regardless of which descriptor was used to make that registration. Thus, for example, it would not be possible to have process A receive FD_READ events and process B receive FD_WRITE events. For situations when such tight coordination is required, it is suggested that developers use threads instead of separate processes. 36 Enhanced Functionality During Connection Setup and TeardownWSAAccept () allows an application to obtain caller information such as caller ID, QOS, etc., before deciding whether or not to accept an incoming connection request. This is done via a callback to an application-supplied condition function. User-to-user data specified via parameters in WSAConnect() and/or the condition function of WSAAccept() may be transferred to the peer during connection establishment, provided this feature is supported by the service provider. At connection teardown time, it is also possible (for protocols that support this) to exchange user data between the endpoints. The end that initiates the teardown can call WSASendDisconnect() to indicate that no more data is to be sent and cause the connection teardown sequence to be initiated. For certain protocols, part of this teardown sequence is the delivery of disconnect data from the teardown initiator. After receiving notice that the remote end has initiated the teardown sequence (typically via the FD_CLOSE indication), the WSARecvDisconnect() function may be called to receive the disconnect data (if any). To illustrate how disconnect data might be used, consider the following scenario. The client half of a client/server application is responsible for terminating a socket connection. Coincident with the termination it provides (via disconnect data) the total number of transactions it processed with the server. The server in turn responds back with the cumulative grand total of transactions that it has processed with all clients. The sequence of calls and indications might occur as follows:
Note that step (5’) must follow step (5), but has no timing relationship with step (6), (7), or (8). Download 1.64 Mb. Share with your friends:
|