Anonymous publish/subscribe

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Anonymous publish/subscribe

Philipp Robbel
Hi,

I have a small question regarding YARP's feature set.

>From Carmen's IPC stuff and other libraries I am used to writing a
client program that listens on a certain channel. As soon as a server
sends out a packet on that same channel, my client will receive it.
The server can go offline and online as much as it wants (my client is
agnostic to that), as soon as it sends data on that specific channel,
my client will be able to grab it. Is my understanding correct that
YARP requires explicit connection handling on the client side, i.e.
needs to be aware of when the server is offline in order to re-connect
later? I have been using YARP just fine with automated tcp
reconnections (using PortReport notifications to automatically ::sync
and (re)::connect to the server) but that does introduce complexity in
the client that I didn't have to deal with in Carmen's IPC model.

Can that be avoided? A question that came up in one of our group meetings..

Thanks a ton,
Philipp

------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Robotcub-hackers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/robotcub-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Anonymous publish/subscribe

paulfitz
Administrator
Philipp Robbel wrote:

> >From Carmen's IPC stuff and other libraries I am used to writing a
> client program that listens on a certain channel. As soon as a server
> sends out a packet on that same channel, my client will receive it.
> The server can go offline and online as much as it wants (my client is
> agnostic to that), as soon as it sends data on that specific channel,
> my client will be able to grab it. Is my understanding correct that
> YARP requires explicit connection handling on the client side, i.e.
> needs to be aware of when the server is offline in order to re-connect
> later? I have been using YARP just fine with automated tcp
> reconnections (using PortReport notifications to automatically ::sync
> and (re)::connect to the server) but that does introduce complexity in
> the client that I didn't have to deal with in Carmen's IPC model.
>
> Can that be avoided? A question that came up in one of our group meetings..
>  

Hi Philipp,
YARP doesn't really have a notion of server and client, just a bunch of
peers talking to each other.  It is usually fairly easy to approximate
the server/client behavior you want, but as you note it takes some extra
effort.

For your case, if you want to keep complexity out of your clients, you
could move it to the server.  If you named the ports associated with the
clients with a common prefix (e.g. "/subscribe/info/machine1/pid1230",
"/subscribe/info/machine2/pid9123", ...) then you could have the server
query all names with that prefix and connect to them on startup.  
Disconnections and connections while the server is running would be
handled by YARP as normal.  Here's some example code, for a server
called "/info":

#include <yarp/os/all.h>
using namespace yarp::os;
int main() {
  Network yarp;
  BufferedPort<Bottle> server;
  server.open("/info");
  Bottle query, response;
  query.addString("bot");
  query.addString("list");
  query.addString("/subscribe/info");
  yarp.write(yarp.getNameServerName().c_str(),query,response);
  if (!(response.get(0).asString()=="ports")) {
    printf("Unknown response from name server\n");
  }
  for (int i=1; i<response.size(); i++) {
    Bottle *port = response.get(i).asList();
    if (port!=NULL) {
      if (port->check("name")) {
    ConstString portName = port->find("name").asString();
    printf("adding subscriber: %s\n", portName.c_str());
    yarp.connect(server.getName().c_str(),portName.c_str());
      }
    }
  }
 
  // server runs...
}

You can test getting port lists on the command-line as follows:
  echo "bot list /subscribe/info" | yarp rpc /root
Replace /root with whatever you call your name server, type "yarp
namespace" to check if you are not sure.

There are other possible solutions with different trade-offs.  There's a
gui floating around for maintaining persistent connections, and various
scripting solutions.  It might be worth offloading some of this work
onto the name-server in a systematic way, if someone had a good idea for
what the desired behavior would be.

Hope this helps,
Paul



------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Robotcub-hackers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/robotcub-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Anonymous publish/subscribe

Giorgio Metta
Hi Philipp,
Let me add to the discussion. Yarp was written with control systems in mind
for which dropping a connection is quite bad (and typically appropriate
corrective actions should be taken on whatever side of the connection
detects the problem).

For example, if the server (controlling some piece of hardware) goes down,
it's good practice for the client to acquire complete state information anew
in case the server is restarted (to guarantee consistency of state
information). In many cases this requires a complete reset of the client
anyway.

Otherwise, the solution Paul proposes is perfectly ok.
Cheers,

Giorgio Metta <[hidden email]>           Assistant Professor
 
LIRA-Lab, DIST                            University of Genova
Viale Causa, 13                           16145 Genova, Italy
Ph: +39 010 353-2946                      Fax: +39 010 353-2948

URL: http://pasa.liralab.it


> -----Original Message-----
> From: Paul Fitzpatrick [mailto:[hidden email]]
> Sent: Monday, March 02, 2009 5:33 PM
> To: Philipp Robbel
> Cc: robotcub-hackers
> Subject: Re: [rc-hackers] Anonymous publish/subscribe
>
> Philipp Robbel wrote:
> > >From Carmen's IPC stuff and other libraries I am used to writing a
> > client program that listens on a certain channel. As soon as a server
> > sends out a packet on that same channel, my client will receive it.
> > The server can go offline and online as much as it wants (my client
> is
> > agnostic to that), as soon as it sends data on that specific channel,
> > my client will be able to grab it. Is my understanding correct that
> > YARP requires explicit connection handling on the client side, i.e.
> > needs to be aware of when the server is offline in order to re-
> connect
> > later? I have been using YARP just fine with automated tcp
> > reconnections (using PortReport notifications to automatically ::sync
> > and (re)::connect to the server) but that does introduce complexity
> in
> > the client that I didn't have to deal with in Carmen's IPC model.
> >
> > Can that be avoided? A question that came up in one of our group
> meetings..
> >
>
> Hi Philipp,
> YARP doesn't really have a notion of server and client, just a bunch of
> peers talking to each other.  It is usually fairly easy to approximate
> the server/client behavior you want, but as you note it takes some
> extra
> effort.
>
> For your case, if you want to keep complexity out of your clients, you
> could move it to the server.  If you named the ports associated with
> the
> clients with a common prefix (e.g. "/subscribe/info/machine1/pid1230",
> "/subscribe/info/machine2/pid9123", ...) then you could have the server
> query all names with that prefix and connect to them on startup.
> Disconnections and connections while the server is running would be
> handled by YARP as normal.  Here's some example code, for a server
> called "/info":
>
> #include <yarp/os/all.h>
> using namespace yarp::os;
> int main() {
>   Network yarp;
>   BufferedPort<Bottle> server;
>   server.open("/info");
>   Bottle query, response;
>   query.addString("bot");
>   query.addString("list");
>   query.addString("/subscribe/info");
>   yarp.write(yarp.getNameServerName().c_str(),query,response);
>   if (!(response.get(0).asString()=="ports")) {
>     printf("Unknown response from name server\n");
>   }
>   for (int i=1; i<response.size(); i++) {
>     Bottle *port = response.get(i).asList();
>     if (port!=NULL) {
>       if (port->check("name")) {
>     ConstString portName = port->find("name").asString();
>     printf("adding subscriber: %s\n", portName.c_str());
>     yarp.connect(server.getName().c_str(),portName.c_str());
>       }
>     }
>   }
>
>   // server runs...
> }
>
> You can test getting port lists on the command-line as follows:
>   echo "bot list /subscribe/info" | yarp rpc /root
> Replace /root with whatever you call your name server, type "yarp
> namespace" to check if you are not sure.
>
> There are other possible solutions with different trade-offs.  There's
> a
> gui floating around for maintaining persistent connections, and various
> scripting solutions.  It might be worth offloading some of this work
> onto the name-server in a systematic way, if someone had a good idea
> for
> what the desired behavior would be.
>
> Hope this helps,
> Paul
>
>
>
> -----------------------------------------------------------------------
> -------
> Open Source Business Conference (OSBC), March 24-25, 2009, San
> Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the
> Enterprise
> -Strategies to boost innovation and cut costs with open source
> participation
> -Receive a $600 discount off the registration fee with the source code:
> SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> Robotcub-hackers mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/robotcub-hackers


------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Robotcub-hackers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/robotcub-hackers