INFO: When and How Often RESV Confirmation Is Delivered
ID: Q195274
|
The information in this article applies to:
-
Microsoft Win32 Software Development Kit (SDK), used with:
-
Microsoft Windows 2000
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);
REFERENCES
RFC 2205, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
Specification"
Additional query words:
RSVP ResvConf
Keywords : kbnetwork kbAPI kbGQos kbWinOS2000 kbSDKPlatform kbWinOS98 kbWinsock kbGrpNet
Version : WINDOWS:
Platform : WINDOWS
Issue type : kbinfo