Microsoft KB Archive/195274

{|
 * width="100%"|

INFO: When and How Often RESV Confirmation Is Delivered

 * }

Q195274

-

The information in this article applies to:


 * Microsoft Win32 Software Development Kit (SDK), used with:
 * Microsoft Windows 98
 * Microsoft Windows 2000 Advanced Server
 * Microsoft Windows 2000 Server
 * Microsoft Windows 2000 Professional

-

SUMMARY
When you write a GQoS (Generic Quality of Service) enabled Winsock application, you can have the receiving application request that a reservation confirmation be delivered to it.

A reservation is established using the Resource ReSerVation Protocol (RSVP) through the exchange of RSVP PATH and RESV messages. The sending application causes a PATH message to be sent by the QOS service provider and the receiving applications accepts the reservation by causing the QOS service provider to send an RESV. The receiving application can request to receive confirmation that the reservation has actually been established.

MORE INFORMATION
When you are requesting reservation confirmation, it is important to remember the following:


 * A receiving application requests delivery of an RSVP reservation confirmation by including a RSVP_OBJECT_RESERVE_INFO object in the provider-specific buffer of the QOS structure and setting the ConfirmRequest field of that object (please see sample code later in this article).
 * Standard RSVP refresh messages (periodic PATH and RESV messages exchanged between a sending and receiving application to keep an RSVP session alive) do not result in an RSVP reservation confirmation request being sent for each RESV sent. Once the receiving application that requested the reservation confirmation receives confirmation, the QOS service provider no longer sends the RSVP_OBJECT_RESERVE_INFO object to request confirmation.
 * Only one RSVP RESV Confirm-Request/RSVP RESV Confirm pair per SIO_SET_QOS occurs per RSVP session.
 * If a new RSVP session is started (because a previous session is torn down), the application sending the RESV must explicitly request reservation confirmation using the RSVP_OBJECT_RESERVE_INFO object for the new session.
 * The RSVP protocol specification (please see, RFC 2205, Section 2.6) indicates that receipt of a reservation confirmation is not a guarantee that an end-to-end reservation is actually in place (primarily for the multicast wildcard/shared-explicit case).

After requesting reservation confirmation, the receiver must await notification either by registering interest in the FD_QOS notification event (if you are using WSAAsyncSelect or WSAEventSelect) or by calling WSAIoctl(SIO_GET_QOS). A reservation confirmation results in the receipt of a RSVP_OBJECT_STATUS_INFO object (assuming your provider-specific buffer is large enough to accommodate this object) with a status code set to WSA_QOS_REQUEST_CONFIRMED.

The following sample code demonstrates how a receiver can request RSVP reservation confirmation:

Sample Code
  QOS               Qos; RSVP_RESERVE_INFO RsvpResv; DWORD            cbQosLen;

// Set flowspecs. Qos.ReceivingFlowspec = app_specific_receiving_flowspec; Qos.SendingFlowspec  = default_notraffic;

// Fill in RSVP_OBJECT_RESERVE_INFO to request RESV confirmation. ZeroMemory((char *)&RsvpResv, sizeof(RsvpResv)); RsvpResv.ObjectHdr.ObjectType = RSVP_OBJECT_RESERVE_INFO; RsvpResv.ObjectHdr.ObjectLength = sizeof(RsvpResv); RsvpResv.Style = RSVP_DEFAULT_STYLE; RsvpResv.ConfirmRequest = 1; RsvpResv.NumPolicyElement = 0; RsvpResv.PolicyElementList = NULL; RsvpResv.NumFlowDesc = 0; RsvpResv.FlowDescList = NULL; Qos.ProviderSpecific.len = RsvpResv.ObjectHdr.ObjectLength; Qos.ProviderSpecific.buf = (char *)&RsvpResv;

// Size of overall QOS structure to set varies based on any "objects" // added to the provider-specific buffer. cbQosLen = sizeof(QOS) + Qos.ProviderSpecific.len;

// Set QOS on socket and request RESV confirmation. nRet = WSAIoctl(my_socket, SIO_SET_QOS, (LPVOID)&Qos, cbQosLen,           NULL, 0, &dwBytes, NULL, NULL);