+1 for any work in this direction!
The idea of doing the ip address resolution on a DNS server sounds
elegant! It decouples the network issues and ros a bit.
However, in such environments there is another nuisance that regularly
occurs: Some student's computer name may not be in the local DNS server
(or worse, not in all the /etc/hosts files). We've spent hours of
debugging just to find out that we had to set ROS_IP in those cases. At
least in the past, roswtf didn't point that out. After a year or so we
switched to dnsmasq - which publishes those hostnames on its dns server.
But not everybody has that running. It is an implicit assumption that
ros makes about the network infrastructure.
My suggestion is, that roscore uses the hostname of the node and stores
it's ip address, maybe in a map (hostname -> ip). Only if a lookup fails
then it uses the stored ip address. In combination with the dynamic DNS
solution / multiple A record solution, this should work anywhere and
should remove the need for using ROS_IP in most cases. I'm aware of the
fact that this is a complication of roscore, but I think it's well worth it!
Cheers,
Ingo
On 17/01/13 09:01, Bil Morris wrote:
> On 01/16/2013 06:20 PM, Benjamin Johnston wrote:
>> I'm just speculating here, and I'm sorry if I've misunderstood the discussion, but my understanding of the ROS XMLRPC interfaces is that this could be a little more complex than just binding to INADDR_ANY...
>>
>> I don't believe there's anything that would prevent a ROS master itself from binding to any address. However, when nodes register themselves with the master, they need to give a 'return' address so that other nodes can find them. The problem is that pubs or subs from the local machine need to be registered with the master using a public address so that other external nodes can locate it. Even though the master could use INADDR_ANY, whenever the public IP address changes (e.g., new wifi connection), then any topics that have a pub or sub from the local machine would need to be reregistered with the master (or the master would need to "cleverly" adjust any such pubs/subs from the local machine).
> One option would be use Dynamic DNS and/or for nodes to offer a hostname
> that returns multiple A records, then the node could be located locally
> or remotely by trying to connect to a series of ip addresses.
>
> _______________________________________________
> ros-users mailing list
> ros-users@code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>
(text/plain)