+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
>