Re: [Playerstage-users] Using ECho Middleware in Player

[Brian G. <ge...@ro...>]

On Fri, 27 Feb 2004, Keith J. O'Hara wrote:

> I recently saw a discussion on the mailing list archives about making
> player more distributed and I thought I'd chime in.
> 
> Although we have some ideas, we are stil trying to figure out the best
> way to use ECho with player. Brian - I saw some of your comments on
> Carmen's use of a publish/subscribe system for its middleware, could
> you elaborate on why you think it isn't that great of an idea?
> 
> It seems to me that publish/subscribe is the most flexible way to
> connect the components (whether they be device drivers or higher-level
> algorithms) of multi-robot systems.  Of course, there is some overhead
> in configuring all the components to talk together, but this can be
> done.  One of the nice things is that since the components talk over
> event-channels, and not directly to each other, components can be
> dynamically created, destroyed, and migrated. Also, one of the coolest
> things about ECho is that it can move code around dynamically.

hi Keith,

I agree that publish/subscribe is a great comms model (in fact the first
paper I ever wrote was about publish/subscribe-based task allocation).

It leads to a more strictly general system than the client/server model,
in which all processes (no client, no server, all peers) can produce
and consume messages, anywhere on the network.  It's more difficult
to implement than a client/server system, especially if you want it to
be efficient.  But it sounds like you've got a good implementation on
your hands in ECho.

As far as I can tell, the reason it works badly for multiple robots in
CARMEN is that the subject namespace is defined poorly, in that there's
no concept of a "robot" in a message subject.  It's as if you took the
messages flowing on multiple Player client-server sockets and sprayed
them all over the network.  You couldn't tell from *which* robot a given
"laser" message came.  We maintain that context with the TCP socket;
in CARMEN they do it with a message router.  To talk to multiple robots
in CARMEN you need multiple instances of the message router.

There's no reason that you can't define the namespace better so that each
message has an unambiguous origin (e.g., the 4th laser on robot "jane").

Perhaps the best way to incorporate pub/sub (e.g., ECho) with Player
would be to add support right at the server.  It wouldn't be too hard
to add hooks so that data packets would be published (rather than just
unicast to each client), and command packets could be subscribed (rather
than just unicast from each client).  Each Player server should then
fit seamslessly into the rest of your pub/sub network.

We can talk in more detail if you have specific questions as to how to go
about this.

        brian.