4.2 Server States in Pipelined Mode

The following figure shows the server states and sequencing.

WMS HTTP 1.1 caching proxy server states and sequencing

Figure 2: WMS HTTP 1.1 caching proxy server states and sequencing

Understanding the server states diagram:

  • All requests illustrated in the diagram are sent by the client to the server in the context of an HTTP request message by using one of the following: the GET method, the POST method, or the OPTIONS method. All server responses are in the context of an HTTP response message. For more information about the request types and the associated methods, see section 2.2.2.2.

  • Requests that loop back on a state indicate that the request is sent by the client to the server on the same TCP connection. The response to the client is not returned until the previous request is terminated by the server.

  • The presence of a caching proxy server introduces an additional state, indicated by the dotted box in the preceding server states diagram. This state is not applicable during direct server and client interaction. For more information, see section 4.12.

  • A TCP connection is initiated with a server when a client issues its first Describe request containing a Request-URI ([RFC2616] section 5.1.2) corresponding to the virtual publishing point for content on the server. (The content can be stored or live.) This first Describe request initiates the server Idle state.

  • In response to the initial Describe request, a client-id token value is created by the server and is used by the client throughout that individual streaming session. However, the server can send a new client-id that is subsequently used by the client.

  • By default when the pipelined mode of the protocol is used, the TCP connection created with the initial Describe request is kept open. If the server closes the connection, it notifies the client by including a Connection: Close header with the response. For more information about Connection: Close header, see HTTP 1.1, as specified in [RFC2616]. A TCP Disconnect causes the server to change from its current state to the Idle state; however, TCP connections are not required to be disconnected for the protocol to be in the Idle state. A transition from the Idle state to Final state occurs when the session state is deleted as described in section 3.2. For example, see section 3.2.6.2.

  • The server stays in the Streaming state while it is sending $D and $E packets to the client.

  • When the server receives a higher-layer event that indicates that the new ASF header is available, as defined in section 3.2.4.2, then the server transitions from the Streaming state to the Waiting for PlayNextEntry state.  This transition is referred to as Change Notification in the diagram.  The server then remains in that state until a PlayNextEntry request or Stop request is received, or until the TCP connection is closed.  A PlayNextEntry request causes a transition back to Streaming state, while a Stop request causes a transition to Idle state.  If the TCP connection is closed, it also causes a transition to the Idle state.

  • In an auto-reconnect scenario, the server maintains the session state. The client maintains the point or offset from which to resume playback. This offset is sent in the stream-offset token on the Pragma header with the next Play request. The server does not expect a new Describe request because it has already sent the $H (Header) packet for the media stream. Also, the server does not need to conduct the packet-pair experiment again to determine the bit rate of the new connection. The sequence is identical to a server resuming from a Pause state. For more information, see section 4.8.

For more information about sequencing associated with the various server states, see section 3.2.