Quality of Service
The basic Quality of Service (QOS) mechanism in Windows Sockets 2 descends
from the flow specification as described in RFC 1363, dated September 1992.
Following is a brief overview of this concept:
Flow specifications describe a set of characteristics about a proposed,
unidirectional flow through the network. An application can associate a pair of flow
specifications 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. Flow specifications indicate
parametrically what level of service is required and provide a feedback
mechanism for applications to use in adapting to network conditions.
This is the usage model for QOS in Windows Sockets 2. An application can
establish its QOS requirements at any time with
WSAIoctl or coincident with the connect operation with
WSAConnect. For connection-oriented transports, it is often most convenient for an
application to use the
WSAConnect function because any QOS values supplied at connect time supersede those
supplied earlier with the
WSAIoctl function. If the
WSAConnect function completes successfully, the application knows that its QOS request
has been honored by the network. 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 can
scale down its service request and try again, or it can give up.
Transport providers update the associated
flowspec structures after every connection attempt (successful or otherwise) in order
to indicate, as well as possible, the existing network conditions. (Updating
with the
Default Values will indicate that information about the current network conditions is not
available.) This update from the service provider about current network
conditions is especially useful when the application's QOS request consists entirely of
the default (unspecified) values, which any service provider should be able to
meet.
Applications expect to use this information about current network conditions
to guide their use of the network, including any subsequent QOS requests.
However, the information provided by the transport in the updated flowspec structure
is only an indication. It might be little more than a rough estimate that only
applies to the first hop and not to the complete, end-to-end connection. The
application must take appropriate precautions in interpreting this information.
Connectionless sockets can also use the
WSAConnect function to establish a specified QOS level to a single designated peer.
Otherwise, connectionless sockets use the
WSAIoctl function to stipulate the initial QOS request, and any subsequent QOS
renegotiations.
Even after a flow is established, conditions in the network can change or one
of the communicating parties might invoke a QOS renegotiation that results in a
reduction (or increase) in the available service level. A notification
mechanism is included that utilizes the usual Windows Sockets notification techniques
(FD_QOS and FD_GROUP_QOS events) to indicate to the application that QOS levels
have changed.
A service provider generates FD_QOS/FD_GROUP_QOS notifications when the
current level of service supported is significantly different (especially in the
negative direction) from what was last reported as a basic guideline. The
application should use the
WSAIoctl function with SIO_GET_QOS and/or SIO_GET_GROUP_QOS to retrieve the
corresponding
flowspec structure and examine them in order to discover what aspect of the service
level has changed. The QOS structures will be updated where appropriate.
regardless of whether FD_QOS/FD_GROUP_QOS is registered and generated.
If the updated level of service is not acceptable, the application can 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 specifications proposed for Windows Sockets 2 divide QOS
characteristics into the following general areas:
Source Traffic Description
The manner in which the application's traffic will be injected into the
network. This includes specifications for the token rate, the token bucket size, and
the peak bandwidth. Though the bandwidth requirement is expressed in terms of a
token rate, a service provider need not implement token buckets. Any traffic
management scheme that yields equivalent behavior is permitted.
Latency
Upper limits on the amount of delay and delay variation that are acceptable.
Level of service guarantee
Whether or not an absolute guarantee is required as opposed to best effort.
Providers that have no feasible way to provide the level of service requested are
expected to fail the connection attempt.
Cost
This is a placeholder for a future time when a meaningful cost metric can be
determined.
Provider-specific parameters
The flow specification itself can be extended in ways that are particular to
specific providers.
- Software for developers
-
Delphi Components
.Net Components
Software for Android Developers
- More information resources
-
MegaDetailed.Net
Unix Manual Pages
Delphi Examples
- Databases for Amazon shops developers
-
Amazon Categories Database
Browse Nodes Database
