QoS API connectionless functional flow

The server and client examples in this topic illustrate qtoq quality of service (QoS) socket APIs written for a connectionless flow.

When the QoS-enabled API functions are called for a connectionless flow requesting that ReSerVation Protocol (RSVP) be initiated, additional functions are initiated. These functions cause the QoS agents on the client and server to set up the RSVP protocol for data flow between the client and server.


Client/server relationship

qtoq flow of events: The following sequence of socket calls provide a description of the figure. It also describes the relationship between the server and client application in a connectionless design. These are modifications of the basic socket APIs.

Server side

qtoq_ioctl() API for a rule marked with no signaling

  1. qtoq_ioctl() API sends a message to the QoS server, asking it to perform admission control on the requested rule.
  2. If the rule is acceptable, it calls a function that sends a message to the QoS server requesting that the rule be loaded.
  3. The QoS server then returns status to the caller indicating success or failure of the request.
  4. When the application has completed using the connection, it calls the qtoq_close() function to close the connection.
  5. The QoS server will delete the rule from the QoS manager, delete the QoS session and perform whatever other action is needed.

qtoq_ioctl() API with normal RSVP signaling

  1. qtoq_ioctl() API sends message to the QoS server, requesting admission control for the requested connection.
  2. The QoS server calls rapi_session() to request a session be set up for the rule and get the QoS session ID to be returned to the caller.
  3. It calls rapi_sender() to initiate a PATH message back to the client.
  4. It then calls rapi_getfd() to get file descriptor in order to wait for QoS events.
  5. The QoS server returns descriptor select(), QoS session ID and status to the caller.
  6. QoS server loads rule when the RESV message is received.
  7. Application issues a qtoq_close() when the connection is completed.
  8. The QoS server will delete the rule from the QoS manager, delete the QoS session, and perform whatever other action is needed.

Client side

qtoq_ioctl() API with normal RSVP signaling

  1. qtoq_ioctl() API calls rapi_session() to request a session be set up for the connection. The rapi_session() function requests admission control for the connection. The connection will only be rejected on the client side if there is a configured rule for the client and it is not active at this time. This function returns the QoS session ID that is passed back to the application.
  2. It calls rapi_getfd() to get file descriptor in order to wait for QoS events.
  3. The qtoq_ioctl() returns back to the caller with the wait on descriptor and session ID.
  4. The QoS server waits for the PATH message to be received. When the path message is received, it responds with the RESV message and then signal the application that the event has occurred through the session descriptor.
  5. The QoS server continues to provide refreshes for the established session.
  6. The client code calls qtoq_close() when the connection is completed.

qtoq_ioctl() API for a rule marked no-signaling

This request is not valid for the client side because no response is required from the client in this case.

Related reference
qtoq_close() API
rapi_session() API
rapi_sender() API
rapi_getfd() API
qtoq_ioctl() API