3.1.4.1.39 Robust Connection Support

  • Article

The term Robust Connection Support refers to a capability of the server to cache responses to recently received requests, allowing the client to fetch the cached response data even if a network outage interrupts the original TCP connection.

A server SHOULD implement Robust Connection Support for each ResourceURI that refers to a Custom Remote Shell or to a CIM object.<99>

A client indicates support for Robust Connections on a per-request basis by including the <wsmv:OperationID> element in the request. When a client request omits the <wsmv:OperationID> element, the server MUST process the request as if the client does not implement Robust Connection support.

A server that does not support Robust Connections for the given ResourceURI MUST ignore the <wsmv:OperationID> element in the request and MUST omit the <wsmv:OperationID> and <wsmv:SequenceID> elements from response messages related to that request.

A server that supports Robust Connections for the request ResourceURI operates as follows.

The server MUST include a <wsmv:OperationID> element with the same value in all response messages related to that request. Client requests can include a <wsmv:OperationID> element as well. A value of true for the mustUnderstand attribute of a <wsmv:OperationID> element in a client request indicates that the request is a retransmission of a previous request.

If the client request includes a <wsmv:OperationID> element and the mustUnderstand attribute is set to false, or the client includes a <wsmv:OperationID> element and the mustUnderstand attribute is set to true and the OperationID value for the request does not exist in the OperationMessages table, the server MUST perform the following steps:

  1. If the mustUnderstand attribute is set to false, check whether the OperationID value of the request already exists in the OperationMessages table. If so, the server MUST fail the operation with a wsa:InvalidMessageInformationHeader fault.

  2. If the SequenceId element received from the client does not have a value of 1, the server MUST fail the operation with a wsa:InvalidMessageInformationHeader fault.

  3. If any rows of the OperationMessages table have the same PrimaryConnection value as the current request's connection, the server MUST delete all state associated with those rows.

  4. Create a new row in the OperationMessages table. If the ResourceURI refers to a CIM object, and the __MI_CallbackRegistration option is present and has the 0x04 bit set, then the server MUST set StreamingOutput to true. Otherwise, the server MUST set StreamingOutput to false.

  5. Start the Connection KeepAlive Timer, with a period set to the lesser of 1 minute and 70% of the client request's w:OperationTimeout value.

  6. Process the request. The operation's output MUST be delivered according to the rules specified in section 3.1.6.6.

If the client request includes a <wsmv:OperationID> header and the mustUnderstand attribute is set to true, then the request is a retransmission of a previous request and the options specified in section 2.2.10 MUST be the same as those in the original request; otherwise, server behavior is implementation-dependent. However, if the OperationId for the request does exist in the OperationMessages table, the server MUST perform the following steps:

  1. Find the row in the OperationMessages table that has the OperationID value from the request, and set the incoming request's connection as the Primary Connection for that row in the table.

  2. If the SequenceId element received from the client does not have a value of 1, the server MUST fail the operation with a wsa:InvalidMessageInformationHeader fault.

  3. Suspend the Response Retention Timer.

  4. If the ResourceURI refers to a CIM object, and the __MI_CallbackRegistration object is present and has the 0x04 bit set, the server MUST set StreamingOutput to true. Otherwise, the server MUST set StreamingOutput to false.

  5. Send the HTTP headers of the response. The Transfer-Encoding header MUST be set to "chunked".

  6. Set ResponseBegun to true.

  7. Start the Connection KeepAlive Timer, with a period set to the lesser of 1 minute and 70% of the client request's w:OperationTimeout value.

  8. Send an Acknowledge message indicating the number of messages received so far from the client.

  9. Send each message in the Messages table as data in the body of the HTTP response using HTTP chunked encoding.

  10. When the output is complete, set ResponseComplete to true and send the final zero-length HTTP body chunk.