QoS API connection-oriented functional flow

 

The server and client examples illustrate qtoq Quality of Service (QoS) socket APIs that are written for a connection-oriented functional flow.

When the QoS enabled API functions are called for a connection-oriented 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 for the data flow between the client and the server.

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

 

Server side

qtoq_accept() API for a rule marked with no signaling

  1. The application calls the socket() function to get a socket descriptor.

  2. The application calls listen() to specify what connections it waits for.

  3. The application calls qtoq_accept() to wait for a connection request from the client.

  4. The API calls the rapi_session() API. If it is successful, a QoS session ID is assigned.

  5. The API calls the standard accept() function to wait for a client connection request.

  6. When the connection request is received, admission control is performed on the requested rule. The rule is sent to the TCP/IP stack. If it is valid, the rule returns to the calling application with the results and the session ID.

  7. The applications for the server and the client perform the required data transfers.

  8. The application calls the qtoq_close() function to close the socket and to unload the rule.

  9. The QoS server deletes the rule from the QoS manager, deletes the QoS session, and performs whatever other actions are needed.

 

qtoq_accept() API with normal RSVP signaling

  1. The application calls the socket() function to get a socket descriptor.

  2. The application calls listen() to specify what connections it waits for.

  3. The application calls qtoq_accept() to wait for a connection request from the client.

  4. When a connection request comes in, the rapi_session() API is called to create a session with the QoS server for this connection and to get the QoS session ID, which is returned to the caller.

  5. The rapi_sender() API is called to initiate a PATH message from the QoS server and to inform the QoS server that it must expect an RESV message from the client.

  6. The rapi_getfd() API is called to get the descriptor that the applications use to wait for QoS event messages.

  7. The accept descriptor and the QoS descriptor are returned to the application.

  8. The QoS server waits for the RESV message to be received. When the message is received, the server loads the appropriate rule with the QoS manager and sends a message to the application if the application requested notification on the call to the qtoq_accept() API.

  9. The QoS server continues to provide refreshes for the established session.

  10. The application calls qtoq_close() when the connection is completed.

  11. The QoS server deletes the rule from the QoS manager, deletes the QoS session, and performs whatever other actions are needed.

 

Client side

qtoq_connect() API with normal RSVP signaling

  1. The application calls the socket() function to get a socket descriptor.

  2. The application calls qtoq_connect() function to inform the server application that it wants to make the connection.

  3. The qtoq_connect() function calls the rapi_session() API to create a session with the QoS server for this connection.

  4. The QoS server is primed to wait for the PATH command from the requested connection.

  5. The rapi_getfd() API is called to get the QoS descriptor that the applications use to wait for QoS messages.

  6. The connect() function is called. The results of the connect() and the QoS descriptor are returned to the application.

  7. The QoS server waits for the PATH message to be received. When the message is received, it responds by sending an RESV message to the QoS server on the application's server machine.

  8. If the application requested notification, the QoS server sends the notification to the application by using the QoS descriptor.

  9. The QoS server continues to provide refreshes for the established session.

  10. The application calls qtoq_close() when the connection is complete.

  11. The QoS server closes the QoS session and performs whatever other actions are necessary.

 

qtoq_connect() API for a rule marked with no signaling

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

 

Parent topic:

QoS APIs
Related reference
qtoq_accept()--Accept QoS Sockets Connection API qtoq_close()--Close QoS Sockets Connection API rapi_session()--Create a RAPI session rapi_sender()--Identify a RAPI sender rapi_getfd()--Get descriptor to wait on qtoq_connect()--Make QoS Sockets Connection API