| Platform SDK: Quality of Service |
QOS-enabled connections are unidirectional. To enable a connection with service guarantees for both sending and receiving from a host, two individual QOS-enabled flows are required. Whether the QOS-enabled flow is for sending or receiving, the initial process of invoking the RSVP SP usually includes the use of one of the following Windows Sockets 2 APIs:
Each of these functions invokes the RSVP SP on the application's behalf, and begins the process of establishing Quality of Service between the receiver and sender. Each of these functions includes a parameter that provides the application with the capability of providing QOS-specific parameters. These QOS-specific parameters are provided through the QOS structure, which is included as a parameter of each of the three preceding functions (WSAAccept generally implements the QOS structure through the callback function provided in its lpfnCondition parameter).
Whenever an application calls the WSAConnect function, the WSAJoinLeaf function, or the WSAAccept callback function with a non-NULL pointer to the QOS structure, QOS functionality is implicitly invoked. This invocation includes enlistment of any other QOS components' services (such as traffic control or RSVP signaling) by the RSVP SP on behalf of the application.
QOS technology and parameters are unidirectional, enabling different transmission parameters for sender and receiver. Additionally, RSVP semantics are receiver-centric, in that resources aren't reserved until the receiver sends out a RESV message. Due to this unidirectional approach, differences exist in the behavior of the receiver and the sender. These differences are outlined in the Receiving QOS-Enabled Data and Sending QOS-Enabled Data sections.