Control Message Structure

Update 2022-01-19: This page is somewhat out of date. Please check out the more detailed information available in the Tech docs either here on GitHub pages or via the link in any uibuilder node.

---

This page is to be used for design notes around the control channel.

The control channel is a separate Socket.IO channel to the data channels (The server channel sends from the server to the client, the client channel goes from the client to the server). Each instance of a uibuilder node gets it own Socket.IO session and you can limit messages to specific clients by using the _clientId (delete it if you want to send a message from a specific client to all clients connected to a node instance).

The control channel is there to keep control information separate to the general data.

The general structure of a control message is:

{ "uibuilderCtrl": "<text>" }

But other properties can be added as required.

Initially, only 2 control messages were used. Three more have now been added. Each of these is (v0.4.8+) copied to output port 2 - you will need debug nodes to show the whole msg as msg.payload is not used. msg.topic is also added from the last input msg or from the node itself.

• uibuilderCtrl = server connected (server -> client): Sent when Socket.IO connects to client.

  Additional properties:

  • "cache-control": "REPLAY" - to be used with the companion node node-red-contrib-infocache. This will trigger a replay of all cached messages for this client.
  • "debug": <boolean> - tells the client whether uibuilderfe.js should use debug mode or not
  • "_socketId": socket.id - ensures control msg only sent to the correct client

• uibuilderCtrl = shutdown (server -> client): Sent when the node instance is either redeployed or removed from Node-RED.

• uibuilderCtrl = client disconnect (server only)

  Additional properties:

  • "_socketId": socket.id - so we know which client disconnected
  • "reason": <string> - The disconnection reason

• uibuilderCtrl = socket error (server only)

  Additional properties:

  • "_socketId": socket.id - so we know which client errored
  • "error": <string> - The error

• uibuilderCtrl = ready for content (client -> server): Indicates the browser client is ready to receive messages from the server.

  (uibuilderfe v0.4.8+) By default, this is sent when the browser's window.load event fires indicating that the DOM is fully loaded as are all of the external resources. For some front-end libraries, even this may be too soon. So you can turn off the default with uibuilder.utoSendReady(false) and then send this message yourself - possible at the end of the FE libraries "mounted" event.

  Additional properties:

  • "cache-control": "REPLAY" - to be used with the companion node node-red-contrib-infocache. This will trigger a replay of all cached messages for this client.
  • "_socketId": socket.id - so we know which client (re)loaded & is ready for messages.

You can also send messages manually from the client to the server by using uibuilder.sendCtrl(msg) (uibuilderfe v0.4.8+).

Notes:

• If you reload a connected client page, you get a disconnect msg followed by a connect but they have different client ids because Socket.IO assigns a new one on connect.
• On first loading or on reloading a page, you will get a 'ready for content' control message sent from the client after the servers 'connected' message.

What to use control messages for

Some ideas

• Send standard information to new client connections
• Keep track of utilisation of your web app (analytics, charging, ...)
• Send alerts if too many clients connect (or too few)

Questions, thoughts and ideas for future design

Questions

Please add any questions you want answering here - please start them with your initials

• JK: Should the server have a 2nd output port for passing on control messages? OR should they be passed out of the standard port. If using the standard port, should there be an option to turn them on/off?

  CDL: I suggest the 2nd output port solution. I can't see any reason to not do that, and if the user wants to use the messages then it is simpler if they appear on a different port.

  JK: Thanks Colin, I agree.

Ideas

Please add any ideas you have here for further discussion and design. Please start with your initials.

NOTE: I've moved the comments on caching to its own page.