Protocol

States

Descriptions of internal class states can be found here: CREventReceiver states and CREventSender states

When a CRSocket object has been activated, it will always be in one of the following states:

passive
Entered when the enclosing client is inactive (invisible, offline, paused, or unloading) or the crSocket has not been assigned a clientId.
readyToConnect
Entered when the crSocket is active, but has not connected to an eventSource, either because it has not been assigned an accessToken or because a previous connection attempt has been aborted by the server.
connecting
Entered when the crSocket is active, has been assigned an accessToken and the internal eventReceiver is trying to connect to an eventSource.
readyToPair
Entered when the crSocket is active, the internal eventReceiver has connected to an eventSource, but does not have a partnerClient, either because it has not been assigned a partnerClientId or because a previous pairing attempt has been rejected.
searching
Entered when the crSocket is active, has connected to an eventSource, has a partnerClient, but has not received any events from the partnerClient within partnerActiveMaxEventInDt millisecs or has received an inactive event from the partnerClient.
interacting
Entered when the crSocket is active, has connected to an eventSource, has a partnerClient, has received at least one event from the partnerClient within partnerActiveMaxEventInDt millisecs, and has not received an inactive event from the partnerClient.

Metastates

The states above are grouped into the following metaStates

active
The set of states implying that the enclosing client is active (visible, online, not paused, and not unloading) and has been assigned a clientId.
Includes readyToConnect, connecting, readyToPair, searching and interacting
connected
The set of states implying that the crSocket is active and connected to an eventSource
Includes readyToPair, searching and interacting
paired
The set of states implying that the crSocket is active, connected, has been assigned a partnerClient and has not been rejected by this partner.
Includes searching and interacting
State machine overview
State machine overview

Communication management

Pairing and communication monitoring is managed by means of the following crEvents:

ping
Will be sent to the client identified by the currently assigned partnerClientId with regular intervals when the sender is paired and signify that the sender is ready to interact with the receiver as a partnerClient.
For controller crSockets, the partnerClientId must be assigned by the enclosing client. For responder crSockets, the partnerClientId can either be assigned by the enclosing client or by a controller crSocket. If no partnerClientId has been assigned, responder crSockets will assign the sender of the first ping event sent from a controller client with matching appId, as partnerClient.
unassign
If the partnerClientId of a controller crSocket is unassigned, it must send an unassign event to the previously assigned partnerClient. If this client had the originating client assigned as partner, it will unassign it.
inactive
Will be sent to the current partnerClient when a crSocket client enters the passive state.
If the recipient client is in the interacting state, it will immediately enter the searching state without waiting for a partner inactive timeout.
reject
If a crSocket has been assigned a partnerClientId and receives a ping event from a client with a different clientId, it will respond with a reject event with subType assignedToOther. If a ping event is blocked by a server resource, this resource must respond with a reject event with a subType explaining why the ping event was rejected.
When a crSocket receives a reject event, it will flag the currently assigned partnerClient as rejected. This will lead to an exit from the paired state, which in turn will stop the outgoing ping sequence. The flag will be removed when the clientId is reassigned or another clientId is assigned as partnerClient.

Invalid event handling

Events with mismatching appIds and clientRoles will always be blocked by the server and crSockets will only forward crEvents from their currently assigned partnerClient to their enclosing client. With the exception of ping events, both server resources and crSockets will ignore invalid events without responding to them.