Differences from MasterSync

= Differences from MasterSync =

This is a comparison with the earlier mechanism used in ROS for bridging multimaster components - mastersync.

Hides Ros Masters

The only way to sync topics/services/actions is if the gateway permits it or is explicitly sharing that topic (think of your lan gateway and port forwarding services)

True Multimaster

It's multimaster, not two-master. Master sync could only 'flip' topics/services to a single other master. The gateway model is aware of all gateways on the hub (i.e. lan) and can direct its flips toward any one of them, or a combination of them.

Public Interfaces

Gateways also have a mode whereby topics/services can be advertised on a public visible interface. Other gateways can then 'pull' these into their local systems.

Auto-Discovery

Uses zeroconf to discover other gateways.

= Under the Hood =

Under the hood it differs from master sync in that it uses a redis server to centralise connection based information and callbacks. This makes it much easier to do multimaster otherwise it would be a right mess of zeroconf and xmlrpc server/clients everywhere.

The one point where it's still weak (master_sync also) is in dictating the transport types. Ideally what we need for multimaster or tablet-robot comms is the ability at the launch level (like remaps) to supply hints to the transport system - e.g. this publisher connection should be 'unreliable', this one 'reliable', that one 'unreliable and compressed'. I'm holding off on that one till ros really starts to move on the transports - there was alot of discussion at roscon and a sig fired up, but inevitably put on hold because of catkin. When that moves, I'll try and provide use case input for that to work out and see if we can then integrate it usefully into the gateway model. Seems much more preferable to doing alot of work adding our own transport layer or hack right now.