Uploaded image for project: 'GPII - Global Public Inclusive Infrastructure'
  1. GPII - Global Public Inclusive Infrastructure
  2. GPII-2421

Consider approaches in the Nexus for reacting to loss of connection with client

    Details

    • Type: New Feature
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Nexus
    • Labels:
      None

      Description

      In the current implementation, if a Nexus client WebSocket connection is dropped, the connection will be cleanly lost and the bound peer will be unaffected.

      For the Science Lab and the Co-Occurrence Engine, we are interested in dynamically adapting to connection and disconnection of devices (such as a pH sensor). When a device is connected, we construct a peer, and when a device is disconnected, we destroy the peer. Given the WebSocket implementation described in the first paragraph above, we need to trap error conditions in the client and ensure that delete requests are sent to the Nexus. For example, if the process handling a pH sensor connection is terminated, we have a signal handler that fires on process termination and sends a Nexus request to delete the pH sensor peer.

      This approach works as long as clean error handling is possible. However, there are situations that would be harder to handle, such as sudden loss of power, or sudden loss of network. In these cases we would not have an opportunity handle the condition in the client.

      We could consider adding configuration to the Nexus to allow peer lifetimes to be synchronized with the lifetime of a WebSocket connection. We likely wouldn't want this to be the default behaviour (the current implementation is probably the right default – to be tolerant of connection losses). In this proposal, if a WebSocket connection is lost, we would destroy the peer that the connection was with. There will be details here to think through such as multiple WebSocket connections to the same peer (probably at most 1 has this special lifetime relationship).

      Or tie a peer lifetime to the time since an update was last received. For example, if an update is not received for 1 minute, delete the peer.

      This could be potentially expressed as a configurable set of conditions for each peer that describes each peer's requirements to stay alive.

        Attachments

          Activity

            People

            • Assignee:
              simon Simon Bates
              Reporter:
              simon Simon Bates
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated: