Re: [rc-hackers] Decentralized YARP

[Paul F. <pau...@li...>]

Dear Anne, Juan,

Answering an easy question first - the "conflict management" issue Anne 
asks about isn't a problem in the modular robotics case.  Conflicts can 
occur if you try to have two yarpservers managing ports on the *same 
machine*, drawing from the same pool of port numbers.   Dedicating one 
yarpserver to each machine doesn't have this problem.

Juan's suggestion to use yarpserver3 is an interesting one.  Since in 
yarpserver3 the database is externalized, stored in two standard sqlite 
files, it is easy to move that data around.  For example, I live in the 
US, and receive a copy of the name server database of an iCub in Italy 
by email every day for debugging/optimization purposes.  Then when I run 
yarpserver3 locally, I can see all of that iCub's port registrations.

The main problem would be merging databases from modules that have been 
disconnected for some time, and have made independent changes.  I could 
imagine a fairly simple sql script to do this merge, if modules stuck to 
registering/unregistering ports on their own IP.  This could be done 
periodically, or (better) live and incrementally.  If you read from the 
yarpserver port, you get notifications of additions/deletions of ports, 
and this could be used as a callback for propagating their registration 
to peers.

There are lots of alternatives.  For example, at the beginning of all 
your programs, you can call:
   yarp::os::Network::queryBypass()
and direct it to your own custom implementation of how name lookups 
should work.

Another possibility: you can create and connect to ports without using a 
name server at all, if you are willing to supply your own hostnames and 
port numbers.  I can provide tips on doing this.  For some applications, 
a name server just gets in the way.

Cheers,
Paul

On 06/25/2010 05:42 AM, Juan G Victores wrote:
> Hello Robotcub people:
> One solution I thought about a while ago for modular robotics was
> using yarpserver3 (not compiled by default, but can be set easily on
> ccmake). It keeps a persistent database, which, I suppose, could be
> accessed externally throughout all the modules of the network, so they
> could keep a copy at all times.
> Do you think this could be a path towards a solution (Anne, Paul, etc)?
>
> 2010/6/25 Anne van Rossum<an...@al...>:
>    
>> Dear all,
>>
>> For the iCub robot YARP is I think the best thing that happened to it. As
>> Paul corrected me, there does exist process management in the form of
>> yarprun. Yarprun allows for the remote creation, suspension, etc. of
>> processes. To implement process management it is necessary to have a yarprun
>> process running on each device in the network (like explained here). So, it
>> is inherently decentralised.
>>
>> Now, we have a type of hardware that is different from the humanoid iCub. It
>> is modular robotics. Robot organisms can be formed by connected robot
>> modules to each other (see http://replicator.almende.com). The problem with
>> this type of hardware is that at one time we can have a yarpserver in your
>> local LAN (in this case an organism), but as soon as this module
>> disconnects, we loose the yarpserver. The centralised approach of standard
>> YARP is a bit of a problem here...
>>
>> So, I was wondering about the implementation details, to figure out if this
>> can be solved within YARP. So, what kind of white page / yellow page /
>> directory management is done exactly by the yarpserver? What kind of
>> conflict management is there in place for the port namespaces (warning)?
>> Where can I read more about this (besides the code itself of course)?
>>
>> And most important, is it perhaps quite straightforward to combine code from
>> yarprun and yarpserver to implement a decentralised YARP version? Or, even
>> better, is there already an attempt somewhere to implement a decentralised
>> version of YARP?
>>
>> Kind regards,
>>
>> Anne
>>
>> ------------------------------------------------------------------------------
>> ThinkGeek and WIRED's GeekDad team up for the Ultimate
>> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
>> lucky parental unit.  See the prize list and enter to win:
>> http://p.sf.net/sfu/thinkgeek-promo
>> _______________________________________________
>> Robotcub-hackers mailing list
>> Rob...@li...
>> https://lists.sourceforge.net/lists/listinfo/robotcub-hackers
>>
>>
>>      
>
>
>