Investigation of Bosh and Punjab

Bosh(Bidirectional-streams Over Synchronous HTTP) is a protocol designed to support XMPP chat via browsers. As browsers can use HTTP protocol, they can not talk directly to XMPP servers. So there is a need for a layer between browsers and XMPP server. BOSH outlines the specifications for that layer.

Punjab is a connection manager (I will refer it by CM from now on) which acts as a layer between client and xmpp server. Client opens a session with CM. Each session has a unique session id. Once a session is established, client can make requests to the CM, each request having rid (request id). CM creates a stanza corresponding to the request and forwards that to the server. When server responds, the response will be sent to the client.

There must be at least one request always parked with CM so that if any data comes to CM from server for that client, it can send that data to client as response of that request. To make this happen client sends an empty request to the server as soon as it receives a response from the CM.

The technique employed by BOSH achieves both low latency and low bandwidth consumption by encouraging the connection manager not to respond to a request until it actually has data to send to the client. As soon as the client receives a response from the connection manager it sends another request, thereby ensuring that the connection manager is (almost) always holding a request that it can use to ”push” data to the client

Whenever a session is established, client and CM agree on few parameters such as

Parameter specified by client: -

Client specifies a few common parameters as to, version, lang, content, charset but the special parameters are
wait :- this is the maximum amount of time(in seconds) for which CM can hold a request. If no data comes from server the in this time then CM has to send an empty response to the client.
hold :- This is specifies the maximum number of request a CM can hold from a client .If hold is 1 then CM can hold at max one request . If CM is holding one request and client sends another request, then CM will have to send empty response for the first request. If hold is 0, this will be as good as polling.
route :- Client can specify to which server it wants to connect using this param. Suppose it wants to connects to a server called example.com at port 5222, then it will specify route as
route=’xmpp:example.com:5222’
ack :- This is used if client wants to have acknowledgement from CM about the reception of its requests. Punjab does not support ack.



Parameter specified by CM :-

Other then general params like to,version,lang etc CM specifies following

hold :- This is to inform client about the maximum number of requests CM will hold . Its value must be less then or equal to the hold value specified by the client.
polling :- This specifies the minimum time between two consecutive empty requests. This is specified to limit unnecessary polling from client.
inactivity :- If CM does not have any request pending to respond, inactivity is the maximum amount of time CM will wait for any request from client before declaring the session dead. This is very important for detecting a broken connection.
requests :- This is the maximum number of simultaneous requests a client can send. It is recommended to be one more then hold value
maxpause :- If CM accepts pausing the session the it will send maxpause also. This will the maximum limit on the pause attribute specified by the client in some special condition.
accept :- using this CM can specify different encodings it supports.
sid :- CM creates one unique id for each session called sid. All requests for this session will come under this sid and different rids.
window :- it is generally two more then hold. This comes in action in case we use acknowledgements.


All the parameters specified by CM can be configure in Punjab code according to our neeeds.

INACTIVITY
If the connection manager has responded to all the requests it has received within a session and the time since its last response is longer than the maximum inactivity period, then it should assume the client has been disconnected and terminate the session without informing the client. If the client subsequently makes another request, then the connection manager should respond as if the session does not exist. Inactivity should be kept smaller to detect disconnections at the earliest.

PAUSE
If client beforehand knows that it will be disconnect for some time(such as page reload), then it can sent a pause request to CM(only if CM specified maxpause at the time of session establishment). CM will then respond to all pending requests immediately and temporarily set the inactivity to pause specified in request.

TERMINATE
Client can any time send request specifying type as terminate. In that case CM will close the session, discard the session key and will send an closing stream to the server(in case of Punjab).

OVERACTIVITY
There are two cases of inactivity
1) If the number of requests parked with the CM is more then ‘requests’ specified by CM in session starting and last request is not pause or terminate request then CM will terminate the session telling by sending terminate as response and under condition policy-violation.
2) if number of requests parked with CM is equal to ‘requests’ specified by CM, and last request is empty, last request id not pause or terminate, and the last two requests came in a time interval less then polling then also CM will terminate the session telling policy-violation.

In-Order Message Forwarding
When a client makes simultaneous requests, the connection manager might receive them out of order. The connection manager MUST forward the payloads to the server and respond to the client requests in the order specified by the ’rid’ attributes. The client MUST process responses received from the connection manager in the order the requests were made.
The connection manager SHOULD expect the ’rid’ attribute to be within a window of values greater than the ’rid’ of the previous request. The size of the window is equal to the maximum number of simultaneous requests allowed by the connection manager. If it receives a request with a ’rid’ greater than the values in the window, then the connection manager MUST terminate the session

Broken Connections
CM keeps responses it sends to the client in a buffer. The number of responses to non-pause requests kept in the buffer SHOULD be either the same as the maximum number of simultaneous requests allowed by the connection manager or, if acknowledgements are being used, the number of responses that have not yet been acknowledged.