Search code examples
httplong-pollingcometdbayeux

CometD - how estabilish long-polling connection


Just to make sure I do this correctly. I am coding a Bayeux client to cooperate with external CometD server (via long-polling). My client sends requests in the following order: handshake, connect, subscribe, connect. The latter connect is stalled until a message is available. When a message comes, server response. Everything works. Am I doing it correctly?


Solution

  • In general, the client should follow the advice sent by the server in the /meta/handshake and /meta/connect messages.

    Subscription messages should be held by the client until a successful /meta/handshake reply.

    Sending requests in a specific order is not exactly precise, since you would want to use at least two connections.

    Therefore the /meta/handshake request goes first; after a successful /meta/handshake reply, /meta/subscribe and /meta/connect can go in parallel on two connections.

    Whether the first /meta/connect reply is held or not is then irrelevant: your client will have a mechanism to handle /meta/connect messages and influence the server about holding or not the /meta/connect reply.

    In CometD, the first /meta/connect is sent with advice: { timeout: 0 } because the client wants to know if the server is still alive after the handshake (otherwise the first connect may be "lost" and the client could think that it is connected fine with the server when it's not). It also serves to notify client applications on the /meta/connect channel a first time quickly after the handshake.