Concert Framework/Gateway Concept

= Gateway Concept =

Multimaster is primarily a means for connecting autonomously capable ros subsystems. It could of course all be done underneath a single master - but the key point is for subsystems to be autonomously independant. This is important for wirelessly connected robots that can’t always guarantee their connection on the network.

What the Gateway Model is:


 * Peer to peer ros system discovery on the local network
 * Opening up a subset of the internal ros api and making them available to other ros systems (public interface)
 * Flipping ros api to remote systems and/or pulling ros api from remote systems.
 * Connection health monitoring between ros systems

What the Gateway Model is not:


 * Ros system discovery across the internet (perhaps later)
 * Higher level linking and co-ordination of multiple ros subsystems (this would be built on top of the gateways)
 * Differences from MasterSync - if you're familiar with MasterSync, then Gateway is like MasterSync v2.

https://docs.google.com/drawings/pub?id=1R7Pu_BZkNU70Jn4l4GpDC95iZevK8sLDJx-UKj3lcw0&w=726&h=477&.png

= Terminology =


 * : a single topic/service/action
 * : a single topic/service/action or a collection of such for a node or launched system.
 * : your regular library/python module functional api.
 * : the object connecting local and remote ros systems.
 * : reference to a gateway (or component thereof) on another ros master
 * : making a connection available to be freely pulled by remotes (put on the public interface).
 * : directed tunnelling of a local connection through a specific remote gateway
 * : registering a remote public connection on the local ros master
 * : the set of connections offered by a gateway for others to use.
 * : gateway name & list of connections flipped to that gateway
 * : list of gateway-connection pairs pulled to the local system.
 * : list of gateway-connection pairs available locally (pulled plus accepted flips)

= Components & Workflow =

The Hub
The hub is responsible for gateway discovery, unique identification and connection.

https://docs.google.com/drawings/d/1-qRpo-p7WVnkhwqj1KK41In_TNUUTUB2txO9xOyd9wc/pub?w=426&h=327&.png

Flipping
This is important for when you want to control where your topics are delivered.


 * Contact a remote gateway.
 * Request to put local connections on the remote system
 * The remote gateway can block or accept the request
 * If the remote gateway accepts, it passes them on to the master to register.

https://docs.google.com/drawings/d/1uvaoAI-G3IXbBi0togs-LefKND3Oy5VXJetHsde7djo/pub?w=574&h=337&.png

Advertising/Pulling
For when you'd like to make some of your local connections freely available for anyone to use.

Advertising

 * Put the set of connections you wish to expose on your public interface.
 * Remote gateways can then freely retrieve them (see pulling below).

Pulling
Request to pull connections from remote gateways and make available locally (opposite of flipping).


 * Browse a remote gateway's public interface.
 * Register desired connections on the local master.

https://docs.google.com/drawings/d/14GTqHBcsPemx3HKGV21o_LXUq7ZWubGSoMllum7kn9A/pub?w=589&h=326&.png