-
Notifications
You must be signed in to change notification settings - Fork 15
Resource Host Discovery Requirements
Unbound resource hosts are resource hosts that are not part of a peer. These resource hosts may be newly created or may have been removed from a peer previously. Either way, they MUST announce their availability as unbound resource hosts.
Unbound resource hosts MUST automatically discover peers existing on their LAN willing to accept them, and request to join them. Approval of the resource host join request is at the discretion of the peer administrator and not within the scope of this feature's requirements.
Resource hosts can be thought of as having different roles:
- Unbound: not part of a peer
- Bound: part of a peer
- Peer: part of a peer and hosting the peer management container
Different events can change the role of a resource host:
- the import of a management container (Unbound -> Peer)
- joining a peer (Unbound -> Bound)
- leaving a peer (Bound -> Unbound)
Since the role can change, the agent running on the resource host MUST first identify its role before taking any action. The agent MUST check to see if a management container has been installed on it to see if it is in the peer role. It MUST also check to see if the resource host it runs on is already participating in a peer to see if it is available.
Based on its role the agent will take different actions.
- If unbound the agent announces availability
- If bound the agent does nothing
- If a peer the agent responds to availability announcements
The availability announcement MUST contain the unique cryptographic identity (PGP fingerprint) of the resource host. This way peers know if they've previously rejected the join request from the resource host before, and can ignore its announcements for availability.
Once a resource host becomes unbound it SHOULD announce availability on the LAN using a lightweight UDP broadcast. Unless answered directly by a peer, it MUST repeat the broadcast periodically. To avoid unnecessary traffic the time between announcement broadcasts SHOULD increase exponentially until some maximum limit is reached.
I.e. Cheap bit shifts, with powers of 2, can be used to raise the period from an initial 8 seconds until the it reaches an upper limit of 4096 seconds.
Unbound resource hosts MUST continue to broadcast availability until their role changes. When their role changes they no longer broadcast their availability.
Peers should respond with a lightweight unicast UDP message to the announcing resource host. The unique cryptographic identity (PGP fingerprint) of the peer (not its resource host) should be sent with the response. Upon receiving the response, the unbound resource host should send a REST request to join the peer which a peer MAY reject.
Peers that previously rejected or abandoned a resource host MAY choose not to respond to subsequent availability announcements by unbound resource hosts. This is why the availability announcement should carry the unique identifier of the unbound resource host: the PGP fingerprint.
Peers MAY in the future have some automated rules for resource hosts joining. They may check the fingerprint for trust relationships, or even compute whether or not to accept the request. These things are beyond the scope of discovery.
Although considered not "robust" enough for the enterprise, UPnP could be used here even in the enterprise. We can use a limited subset of UPnP. The protocol part uses UDP broadcasts on port 1600 for search requesets. The search response is a unicast UDP message back. This fits our needs very well. There's also a lot of Golang UPnP libraries to chose from.
Later on this could be used for more than just discovery: i.e. port mapping requests to UPnP Gateway Devices for resource host connectivity.