Windows* Sockets 2 Application Programming Interface An Interface for Transparent Network Programming Under Microsoft Windowstm revision 2 August 7, 1997
Asynchronous Notification Using Event Objects
Download 1.64 Mb.
|
- Navigate this page:
- 30 Quality of Service
- 31 The QOS Structure
- 32 QOS Templates
- 33 Default Values
29 Asynchronous Notification Using Event ObjectsTo accommodate applications such as daemons and services that have no user interface (and hence do not use Windows handles), the WSAEventSelect() and WSAEnumNetworkEvents() functions are provided. WSAEventSelect() behaves exactly like WSAAsyncSelect() except that, rather than cause a Windows message to be sent on the occurrence of an FD_XXX network event (e.g.. FD_READ, FD_WRITE, etc.), an application-designated event object is set. Also, the fact that a particular FD_XXX network event has occurred is “remembered” by the service provider. The application may call WSAEnumNetworkEvents() to have the current contents of the network event memory copied to an application supplied buffer and to have the network event memory atomically cleared. If desired, the application may also designate a particular event object which is cleared along with the network event memory. 30 Quality of ServiceThe basic QOS mechanism in WinSock 2 descends from the flow specification (or "flow spec") as described by Craig Partridge in RFC 1363, dated September 1992. A brief overview of this concept is as follows: Flow specs describe a set of characteristics about a proposed unidirectional flow through the network. An application may associate a pair of flowspecs with a socket (one for each direction) at the time a connection request is made using WSAConnect(), or at other times using WSAIoctl() with the SIO_SET_QOS/SIO_SET_GROUP_QOS command. Flowspecs indicate parametrically what level of service is required and provide a feedback mechanism for applications to use in adapting to network conditions. The usage model for QOS in WinSock 2 is as follows. An application may establish its QOS requirements at any time via WSAIoctl() or coincident with the connect operation via WSAConnect(). For connection-oriented transports, it is often most convenient for an application to use WSAConnect(), and any QOS values supplied at connect time supersede those that may have been supplied earlier via WSAIoctl(). If the WSAConnect() function completes successfully the application knows that its QOS request has been honored by the network, and the application is then free to use the socket for data exchange. If the connect operation fails because of limited resources an appropriate error indication is given. At this point the application may scale down its service request and try again or simply give up. After every connection attempt (successful or otherwise) transport providers update the associated flow spec structures in order to indicate, as well as possible, the existing network conditions. (Note that it is legal to update with the default values defined below to indicate that information about the current network conditions is not available.) This update from the service provider about current network conditions is especially useful for the case where the application’s QOS request consisted entirely of the default (i.e. unspecified) values, which any service provider should be able to agree to. Applications expect to be able to use this information about current network conditions to guide their use of the network, including any subsequent QOS requests. Note however, that information provided by the transport in the updated flow spec structure is only a hint and may be little more than a rough estimate that only applies to the first hop as opposed to the complete end-to-end connection. The application must take appropriate precautions in interpreting this information. Connectionless sockets may also use WSAConnect() to establish a specified QOS level to a single designated peer. Otherwise connectionless sockets make use of WSAIoctl() to stipulate the initial QOS request, and any subsequent QOS renegotiations. Even after a flow is established, conditions in the network may change or one of the communicating parties may invoke a QOS renegotiation which results in a reduction (or increase) in the available service level. A notification mechanism is included which utilizes the usual WinSock notification techniques (FD_QOS and FD_GROUP_QOS events) to indicate to the application that QOS levels have changed. The basic guideline for a service provider to generate FD_QOS/FD_GROUP_QOS notifications is when the current level of service supported is significantly different (especially in the negative direction) from what was last reported. The application should use WSAIoctl() with SIO_GET_QOS and/or SIO_GET_GROUP_QOS to retrieve the corresponding flow specs and examine them in order to discover what aspect of the service level has changed. Note that the QOS structures will be updated as appropriate regardless of whether FD_QOS/FD_GROUP_QOS is registered and generated. If the updated level of service is not acceptable, the application may adjust itself to accommodate it, attempt to renegotiate QOS, or close the socket. If a renegotiation is attempted, a successful return from the WSAIoctl() function indicates that the revised QOS request was accepted, otherwise an appropriate error will be indicated. The flow specs proposed for WinSock 2 divide QOS characteristics into the following general areas:
31 The QOS StructureThe WinSock 2 QOS structure is defined through a combination of the qos.h and winsock2.h header files. The relevant definitions are summarized here. typedef struct_WSABUF { u_long len; /* the length of the buffer */ char FAR * buf; /* the pointer to the buffer */ } WSABUF, FAR * LPWSABUF; typedef uint32 SERVICETYPE; typedef struct _flowspec { uint32 TokenRate; /* In Bytes/sec */ uint32 TokenBucketSize; /* In Bytes */ uint32 PeakBandwidth; /* In Bytes/sec */ uint32 Latency; /* In microseconds */ uint32 DelayVariation; /* In microseconds */ SERVICETYPE ServiceType; uint32 MaxSduSize; /* In Bytes */ uint32 MinimumPolicedSize; /* In Bytes */
typedef struct _QualityOfService { FLOWSPEC SendingFlowspec; /* the flow spec for */ /* data sending */ FLOWSPEC ReceivingFlowspec; /* the flow spec for */ /* data receiving */ WSABUF ProviderSpecific; /* additional provider */ /* specific stuff */ } QOS, FAR * LPQOS; Definitions: TokenRate/TokenBucketSize A Token bucket model is used to specify the rate at which permission to send traffic (or credits) accrues. The value of -1 in these variables indicates that no rate limiting is in force. The TokenRate is expressed in bytes per second, and the TokenBucketSize in bytes. The concept of the token bucket is a bucket which has a maximum volume (token bucket size) and continuously fills at a certain rate (token rate). If the “bucket” contains sufficient credit, the application may send data; if it does, it reduces the available credit by that amount. If sufficient credits are not available, the application must wait or discard the extra traffic. If an application has been sending at a low rate for a period of time, it clearly may send a large burst of data all at once until it runs out of credit. Having done so, it must limit itself to sending at TokenRate until its data burst is exhausted. In video applications, the TokenRate is typically the average bit rate peak to peak, and the TokenBucketSize is the largest typical frame size. In constant rate applications, the TokenRate is equal to the PeakBandwidth, and the TokenBucketSize is chosen to accommodate small variations. PeakBandwidth This field, expressed in bytes/second, limits how fast packets may be sent back to back from the application. Some intermediate systems can take advantage of this information resulting in a more efficient resource allocation. Latency Latency is the maximum acceptable delay between transmission of a bit by the sender and its receipt by the intended receiver(s), expressed in microseconds. The precise interpretation of this number depends on the level of guarantee specified in the QOS request. DelayVariation This field is the difference, in microseconds, between the maximum and minimum possible delay that a packet will experience. This value is used by applications to determine the amount of buffer space needed at the receiving side in order to restore the original data transmission pattern. ServiceType This is the level of service being negotiated for. Values permitted for level of service are given below. SERVICETYPE_NOTRAFFIC In either Sending or Receiving flowspec, indicates that there will be no traffic in this direction. On duplex capable media, this signals underlying software to setup unidirectional connections only. SERVICETYPE_BESTEFFORT Indicates that the service provider, at minimum, takes the flow spec as a guideline and makes reasonable efforts to maintain the level of service requested, however without making any guarantees whatsoever. SERVICETYPE_CONTROLLEDLOAD Indicates that end-to-end behavior provided to an application by a series of network elements tightly approximates the behavior visible to applications receiving best-effort service "under unloaded conditions" from the same series of network elements. Thus, applications using this service may assume that: (1) A very high percentage of transmitted packets will be successfully delivered by the network to the receiving end-nodes. (Packet loss rate will closely approximate the basic packet error rate of the transmission medium).; and (2) Transit delay experienced by a very high percentage of the delivered packets will not greatly exceed the minimum transit delay experienced by any successfully delivered packet at the speed of light. SERVICETYPE_GUARANTEED Indicates that the service provider implements a queuing algorithm which isolates the flow from the effects of other flows as much as possible, and guarantees the flow the ability to propagate data at the TokenRate for the duration of the connection. If the sender sends faster than that rate, the network may delay or discard the excess traffic. If the sender does not exceed TokenRate over time, then latency is also guaranteed. This service type is designed for applications which require a precisely known quality of service but would not benefit from better service, such as real-time control systems. SERVICETYPE_NETWORK_UNAVAILABLE In either a Sending or Receiving flowspec, this may be used by a service provider to indicate a loss of service in the corresponding direction. SERVICETYPE_GENERAL_INFORMATION Indicates that all service types are supported for this traffic flow. SERVICETYPE_NOCHANGE In either a Sending or Receiving flowspec, this requests that the QOS in the corresponding direction is not changed. This may be used when requesting a QOS change in one direction only, or when requesting a change only in the ProviderSpecific part of a QOS specification and not in the SendingFlowspec or the ReceivingFlowspec. SERVICE_IMMEDIATE_TRAFFIC_CONTROL In either a Sending or Receiving flowspec, this may be combined using bit-wise OR with one of the other defined ServiceType values to request the service provider to activate traffic control coincident with provision of the flowspec. MaxSduSize The maximum packet size, in bytes, that is permitted or used in the traffic flow. MinimumPolicedSize The minimum packet size that will be given the level of service requested. 32 QOS TemplatesIt is possible for QOS templates to be established for well-known media flows such as H.323, G.711, etc. The WSAGetQOSByName() function can be used to obtain the appropriate QOS structure for named media streams. It is up to each service provider to determine the appropriate values for each element in the QOS structure, as well as any protocol or media-dependent QOS extensions. The documentation for WSAGetQOSByName() will be periodically updated with a list of flow specifications and general descriptions as they become well-known. WSAGetQOSByName() can also be used to enumerate the set of known QOS template names. 33 Default ValuesA default flow spec is associated with each eligible socket at the time it is created. Field values for this default flow spec are indicated below. In all cases these values indicate that no particular flow characteristics are being requested from the network. Applications only need to modify values for those fields which they are interested in, but must be aware that there exists some coupling between fields such as TokenRate and TokenBucketSize. TokenRate = 0xFFFFFFFF (not specified) TokenBucketSize = 0xFFFFFFFF (not specified) PeakBandwidth = 0xFFFFFFFF (not specified) Latency = 0xFFFFFFFF (not specified) DelayVariation = 0xFFFFFFFF (not specified) ServiceType = SERVICETYPE_NOCHANGE MaxSduSize = 0xFFFFFFFF (not specified) MinimumPolicedSize = 0xFFFFFFFF (not specified) Download 1.64 Mb. Share with your friends:
|