> That's good news.
>
> I suspect the difficult problem will be understanding and
> characterizing various clients' implicit assumptions about bandwidth,
> latency, reliability, quality of service, etc.
>
> We need to understand what kinds of transport protocols will satisfy
> which specific robotics applications.

Hi,

Yes I agree with that.

Another thing I forgot to mention is that I've always only considered
alternative transport for topics, assuming that XML-RPC, services and
params could still stay on TCP.

This is definitely a use-case, but I see at least 2 use case that do
not get covered:
- making ROS connection through a secure connection, or through a HTTP
layer across a firewall. This case would be much harder to implement,
given how TCP connections are at the core of ROS. Maybe this should
not be a ROS problem but should only be solved through some kind of
VPN.
- Making ROS connection through another kind of medium without an IP
stack, for instance ZigBee or CAN. I would tend to advocate for
specialised node and a multi-master solution in this case, but sharing
parameters could be complicated.

Should we move this discussion to the RosNG sig mailing list, or is it
of general interest?
-- 
Cedric Pradalier