Motivation

To allow client connections from behind restrictive network firewalls that block persistent socket connections but allow HTTP communications, Union should allow multiuser communications to be transported via standard HTTP requests. Client connections should be identified by a session ID, and messages should be delivered and received over non-persistent HTTP requests/responses.

Architecture

The "Constant-Contact" Communication Model

To allow the server to contact the client any time new messages become available, the client will always keep at least one HTTP request to the server open. When the client receives any response from the server, it checks how many responses are pending. If there are no responses pending, the client makes a generic HTTP request for the latest updates. The server keeps the request open until updates become available. The longest possible delay between a client's request for updates and the server's response is dictated by the application-configurable heartbeat rate.

Implementation:

When a server response is received, if no other request is pending, the client sends a new request for server updates. If the client is configured to queue messages, the request also includes all currently queued messages, and the client begins a countdown to the next batched message delivery.

Optional Client Message Queuing

To reduce the number of HTTP requests per second required for realtime multiuser communications, client-to-server messages can be queued and sent in batches at a configurable "client request rate" (by default every 300 milliseconds). Applications that require realtime responsiveness should opt for more frequent message delivery, or disable the message queue entirely, opting instead for immediate message delivery. Note, however, that overly frequent message delivery can degrade server performance, and can result in client-side errors when the maximum number of simultaneous open HTTP requests is exceeded. Applications that require a reduced server load should opt for less frequent message delivery. Note, however, that infrequent message delivery reduces realtime responsiveness.

Implementation:

When code in the client API attempts to send a message, if the countdown to the next batched message delivery has not yet expired, the message is queued. Otherwise, the message is sent immediately.

When the countdown to the next batched message delivery expires, if there are queued messages they are sent in a batch to the server via an HTTP request. If there are no messages in the queue, no request is sent to the server.