To better understand presence events, the connection cycle must first be understood. When a client subscribes it connects to the server with a UUID parameter which uniquely identifies it. For example, the HTTP URL request of a client subscribing with UUID 123-456 may look like this:
When the initial subscribe request is made, the server will detect the provided UUID parameter value and fire a
join event for this UUID. Once connected, there are three circumstances under which the client will disconnect:
Explicit disconnect, server-induced, occurring after message push or 320-second server timeout. The client, upon receiving new message, will be disconnected by the server. The client will then reconnect with the current timetoken (part of the received message payload) and await the next series of messages. If no messages were received during a 320-second waiting period the server will tear down the connection automatically. The client is expected to reconnect again with the previously used timetoken. No Presence events are fired, as the client reconnects quickly after either a server timeout occurs or after successfully receiving a message from the server.
Failure to reconnect after a server timeout or message receipt. The client knows to resubscribe to the channel and reconnect when either a server timeout occurs, or when a message is received.
timeoutevent triggers when the client does not reconnect after a server-induced disconnect.
Explicit disconnect upon either a graceful client disconnect (programmatically) or due to network loss. In this scenario, the client disconnects before the 320 second server timeout AND before a message was received. The
leaveevent triggers in this scenario as the client has initiated a disconnect (graceful or not).