Pushlets - Protocol Specification
The Pushlet protocol facilitates publishing and streaming of data on top of the standard HTTP protocol This section introduces the main Pushlet protocol concepts.
As a start, below is an example of Pushlet protocol exchange between a client and a server (various details omitted).
The above example shows a client starting a session through a join request. This request is acknowledged with an XML event join-ack. Subsequently a data stream is opened using the listen request. The listen-ack is returned followed by the data events over the data channel.
Concepts used in the Pushlet protocol are somewhat similar to those used in the Real-Time Streaming Protocol (RTSP).
Like RTSP the Pushlet protocol provides both a control channel and a data channel. The client uses the control channel to start/stop sessions (join/leave), subscribe/unsubscribe to/from subjects, publish data etc. The actual streaming of data is transmitted out of band over a separate (HTTP) connection.
Since the HTTP protocol is request/response oriented, data streaming is achieved similar to audio/video streaming over HTTP, i.e. as a very long response. Since not all clients may support long-lived HTTP responses, data streaming may also be conducted in the so called pull and poll modes as controlled by the client or enforced by the server. In these latter modes the server will end the HTTP response document after one or more events are returned and instruct the client to wait and renew (refresh) the data streaming request.
Protocol control and data messages exchanged between client and server are called events. Pushlet events are currently defined as a flat set of name/value pairs. The Pushlet protocol reserves names starting with p_ to discern protocol-specific names from user-supplied names.
Note: future versions of the protocol will introduce a more versatile event structure in which applications may use arbitrary payload data.
Control events to the server can be specified as HTTP query parameters when using GET or as XML in a POST body.
The Pushlet protocol provides a simple form of session management. A client starts with creating a Pushlet session using a join request. This request is acknowledged by the server through a join-ack response. Within the response a session id ( p_id) is returned that the client should supply in all other requests in this session. Note that Pushlet session management is independent from the standard HTTP session management (often with cookies) as to be independent of specific server implementations or (browser) client settings.
Since not all applications may require session management, the join-listen service is supplied that allows clients to join, subscribe and listen in one request. This allows for very simple clients (like even Unix telnet) to receive data without the need to keep state.
After a client has created a Pushlet session or even while streaming data, it can subscribe to and unsubscribe from topics, historically called subjects.
After a client has created a Pushlet session or even while streaming data, it use the publish service to send data events to the server. The server will route the event to those clients with a matching subscription (multicast). The event may also be directed to one specific client by supplying that client's session id.
Pushlets - Protocol Specification