4.1 Server States in Non-Pipelined Mode
The following diagram shows the server states:
Figure 1: WMS HTTP 1.0 Caching proxy server states and sequencing
Understanding the server states diagram:
All requests illustrated in the diagram, with the exception of Change Notification, are sent by the client to the server in the context of an HTTP request message using either the GET or POST methods. All server responses are in the context of an HTTP response message.
Requests that loop back on a given state indicate that the request is sent by the client to the server on a separate TCP connection. These requests do not interrupt other requests or sessions and can be sent multiple times without changing the server state.
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 must be subsequently used by the client.
TCP Disconnect occurs when the connection used for the Play request and server response is closed. The server may close the TCP connection after sending the response or because of an error or time-out that occurred on the server. Clients may also close the TCP connection in stop and resume scenarios. For more information, see section 4.7. A TCP Disconnect causes the server to change from its current state to the Idle state.
Change Notification, which contains the $C (Stream Change Notification) packet, is sent by the server on the same TCP connection as the Play request. The Change Notification causes the server transition from streaming state to Waiting for SelectStream state. A client usually sends Describe, Log, SelectStream, and KeepAlive requests on separate connections. A TCP Disconnect on one of these separate connections does not cause a state transition. 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 188.8.131.52.
The server remains in Waiting for SelectStream state until a SelectStream request is received, or until the TCP connection is closed. A SelectStream request causes a transition back to Streaming state. If the TCP connection is closed, it causes a transition to the Idle state.
By default when the non-pipelined mode of the protocol is used, TCP connections are not reused. Therefore, the connection used for the Describe request is closed by the server when the server sends its response. However, the client can keep this connection open by including a Connection: Keep-Alive header with the request. If the server can comply, it notifies the client by including a Connection: Keep-Alive header in response. In this case, the client can send subsequent requests, such as the Play request, on the same connection. The presence of the Connection: Keep-Alive header does not trigger a state transition or otherwise change the state of the protocol. The Connection: Keep-Alive header is described in Hypertext Transfer Protocol 1.1, [RFC2616].
For more information about sequencing associated with the various server states, see section 3.2.