+1 for binding to INADDR_ANY, though I suspect there are a number of
ramifications I am not aware about right now. Thanks for pointing out
your package Bill, it looks like a significant improvement over Thomas
Moulard's original.

The multimaster approach is designed to handle all the problems you've
mentioned (apart from #4). Daniel and Jihoon from Yujin will be able
to give better and more up to date answers, as it has been a bit of
time since I've helped out with the code.
 - If your only problem is that you have indicator lights over
rosserial - it might be overkill to switch to the multimaster
approach. It will be easier having a regular ros node interfacing with
your microcontroller using a serial library.   You can then run a
single core on the robot.
 - If you are planning on having multiple user machines talk with your
robot, then the multi-master approach is well suited for you. This
approach should also be better in the long run for dealing with wifi
outages.

If you do use the multi master approach:
 - A single local master + gateway on the robot.
 - The rocon hub can be anywhere. If all of your machines are on the
same network (or in any situation where mDNS/zeroconf/avahi works),
then you should place the hub on machine with the least chance of
network failure. If zeroconf won't work, you'll need it on a machine
with a static IP or a resolvable address.
 - Nothing really changes with multiple users.

I don't know how well wifi outages have been tested on the gateway
framework as of right now, but it is something that will definitely be
done over the next few months.

Best,
Piyush

On Wed, Jan 16, 2013 at 7:03 AM, Michael Gratton <mikeg@cse.unsw.edu.au> wrote:
> On 16/01/13 06:57, Bil Morris wrote:
>> I am not sure why the XML RPC server does not support binding to
>> INADDR_ANY instead of a specific ip address.
>
> Yeah, this would be great from a systems perspective! Why doesn't it do
> that already?
>
>> If the server could be modified to connect to all interfaces and rebind
>> the sockets when the xmlrpc server receives
>> a SIGHUP, then I think you could take something like our upstart scripts
>> [1] and modify them to start ROS on boot and
>> and send SIGHUP to ROS whenever the WiFi interface bounces.
>
> IIRC if you listen on any socket, you don't need to re-bind as
> interfaces come and go, so I don't think even sending a signal would
> even be necessary.
>
> For people that want a robot to "just work" as soon as you switch it on,
> this would make life much easier.
>
> //Mike
>
> --
> Michael Gratton <http://www.cse.unsw.edu.au/~mikeg/>
> UNSW School of Computer Science and Engineering.
>
>
>
> _______________________________________________
> ros-users mailing list
> ros-users@code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>