CommTest

This application facilitates testing of the CRSocket component, using default configuration settings. It consists of a controller/responder app pair that are identical, except that they are initiated with "controller" and "responder" clientRoles respectively.

Note that the accessToken must be a non-empty string of Ascii printable characters.

Functionality

JavaScript Console logging

All state changes and events transmitted from the CRSocket object and its internal CREventReceiver and CREventSender objects can be logged in the JavaScript console. Each log entry includes time in millisecs since the previous entry.

Low level server management

The app displays the number of "open", "error" and "message" events received by the internal CREventReceiver object (ServerIn) and events sent to the server by the CREventSender object (ServerOut). Message events are divided by type. All message event types are included except "crEvent".

Except for the clientid generator resource, all communication from the server passes through the eventsource resource. All communication to the server goes through the sendevent resource which is unidirectional and does not return any information. This means that all low level server managements are handled by these events.

Things to look out for:

• "error" events should only occur when the network connection between client and server is broken.
• "alive" events should only be sent when there are no other incoming events.
• "alive" and "close" events should immediately trigger "closed" and "alive" events respectively at the server.

Communication management events between CRSocket clients

The app displays the number of communication management events transmitted between clients (PartnerIn and PartnerOut).

Things to look out for:

• The number of PartnerOut events should correspond to the number of PartnerIn events at the partnerClient and vice versa.
• When a crClient enters the "passive" state for some reason, it should transmit an "inactive" event to its partnerClient if possible.
• When a controller attempts to pair with a responder which is already connected to another controller, the responder should respond with a "reject" event. Pairing attempts from responders and from clients with equal roles or mismatching appId"s should also be rejected.

EventReceiver timing

The app displays the amount of millisecs the CREventReceiver object spends in "connecting", "open" and "closed" states and the round trip time of "alive" events.

Things to look out for:

• Amount of time spent in the "connecting" state should not differ too much from round-trip time of "alive" events. Both indicate mimimum transmission delays between client and server.
• Amount of time spent in the "open" state should normally correspond the max execution time setting at the server.
• When the crSocket is in the "active" meta state, the amount of time spent in the "connecting" state should be close to zero.

State monitoring

Current states and subStates of the CRSocket object, and its internal CREventReceiver and CREventSender objects. When the CRSocket object is not interacting with a partnerClient, subStates will in most cases reflect the reason why.

Socket properties

Core properties currently assigned to the CRSocket object:

• clientId
• accessToken
• partnerClientId

Socket configuration

Assignment of the core CRSocket properties.

Please note:

• The clientId should be automatically generated by the server. When it is cleared a new clientId should immediately be generated.
• The "Resume" and "Pause" buttons forces the crSocket to enter the "passive" state and "active" metaState respectively. The socket can also be passivated by unloading the page, or making it invisible or offline. When passivated, the socket should immediately try to disconnect from its eventsource and send an "inactive" event to its partnerClient (if assigned). When activated and assigned an authToken, it should try to reconnect. If successfully connected and assigned an a partnerClientId it should also reach out and try to interact with its partnerClient.
• The authToken must be a non-empty string of printable Ascii characters.
• The "interacting" state should only be reached when a clientId of a responder, in the 'readyToPair' state, is assigned as partnerClientId in a controller client.

Event transmission

The app can be used to test reception rate, delays and content accuracy of custom CREvent objects transmitted between crSockets. Using this functionality to send crEvents belonging to the communication protocol is not recommended.

Events can be sent by filling in the Event out fields and pressing the "Send button". Note that this will only be possible when the crSocket is in the "interacting" state. Events must always contain an eventType. In addition it is possible to assign a subType and toggle the buffered, logged and interceptable event flags. For single events it is also possible to assign up to two parameters.

To send multiple events, specify a count > 1, and min/max secs between events (must always be > 1). The param1 and param2 fields will automatically be set to the current event number and the current delay to the next event in millisecs.

Things to look out for:

• Event reception should be reflected in the Event in fields of the partnerClient.
• If the 'logged' flag is true (green) the events should be logged at the server.
• If the 'buffered' flag is true (green) and the sender crSocket client is offline, the events should be buffered and then transmitted with one sec delay between each event when it becomes online.