WebSocket

This class contains the server side of Tsugi notification web sockets

The primary purpose of this class is to provide secure, isolated socket notification spaces for each link_id in Tsugi. With those spaces, the tool can also have a set of named rooms.

WebSockets and frameworks like SocketIO that build atop WebSocket connections allow for a very rich way of developing multi-browser low-latency interactions.

Tsugi cannot make that rich fabric available in a reliable way, so we provide a simple, generic service that works across all tools reliably that does not compromise the integrity or memory footprint of a single shared socket server. So Tsugi only provides a single broadcast notification service. All the browsers in a particular link in a particular course have a secure and isolated space.

The application can make "rooms" within that space using whatever room naming convention it likes. The rooms are isolated by room name through security-by-obscurity. To get a notification socket, the pplication makes the following call in JavaScript when it is loaded:

var global_web_socket = tsugiNotifySocket("place_42");

This will return false if web sockets are not enabled on the Tsugi server. But you won't know that the web socket can be used until the onopen() method is called or the readyState attribute is OPEN. A failure to open might be due to bad token or missing server.

For a simple example of how to use this functionality in a tool see:

https://github.com/tsugiproject/socket-test

For a more complex tool that uses but does not require the notification service please see:

https://github.com/tsugitools/michat

This tool keeps message and presence information in database tables and uses the notification service to avoid a slow and costly polling approach. But the application falls back to the slow/costly polling approach so it works with or without WebSockets. If it has Web Sockets it is both quicker and performs better.