SDK Hardware Authentication Scenarios
Exhibit Online |
Normal Gumband Cloud connectivity | Once the exhibit SDK has initialized, it will use hardware list (ie. connected hardware from the web UI) to know which If the exhibit SDK does not yet have the hardware list when hardware connects, those hardware connections are added to a "Waiting for Auth" queue. |
Exhibit Offline |
No Gumband Cloud connectivity | Once the exhibit SDK has initialized, it will use hardware list to allow future connections to those |
Exhibit Offline Mode |
No Gumband Cloud connectivity | Once the exhibit SDK has initialized, it will use the |
SDK “Waiting for Auth” Queue
Had to add a “waiting for auth” state where hardware sockets would connect, but the exhibit hasn’t received the connected hardware list from the platform yet (noInternetConnection: false). When it does, it would send the message to ask for auth on that client. If it doesn’t, it will disconnect is 10s and then assuming the hardware would try to reconnect and repeat the cycle until it connects.
TODO: If the SDK disconnects due to no hardwareID in this queue, it should respond per the updated MQTT spec.
{
"text": "id"
}
How Two MQTT Connections for the Same Hardware ID Respond
If two connections try to authenticate with the same hardwareId, the SDK responds whether or not the existing connection is authenticated. If that case is true, then the new hardware connection is rejected. If the existing connection is not authenticated (ie. in the “Waiting for Auth” queue), then that connection will be severed and the new connection will be accepted.
SDK HARDWARE_ONLINE & HARDWARE_OFFLINE Callbacks
The exhibit SDK emits a HARDWARE_ONLINE event with the after a hardware connection is established and successfully authenticates. It also emits a HARDWARE_OFFLINE event if the MQTT heartbeat for a particular harwareId connection isn’t received within 20 seconds. Both events contain the following payload
{
hardwareId: 123,
name: 'Exhibit Gizmo'
}