From: brian gerkey <bgerkey@us...> - 2003-04-22 18:13:06
As you may recall, I recently changed Player's message protocol and addressing
scheme by adding a "robot ID" to the message header. This change has not yet
been released, and I'm now thinking of removing it.
As far I know, the primary reasons for making this change are (all to do with
* A single client can control multiple robots over a single socket
connection, rather than maintaining multiple connections.
* You only have to find one unused port for Player to listen on, rather than
finding one port per robot. Finding one port per robot can be difficult
in a multi-user environment, or in any environment if you have a large
number of robots. And in practice, the ports need to be contiguous, or
else you'll have a hard time starting up all the clients.
That's great, but unfortunately there are significant drawbacks to this
* All client libraries have to change to support the new message
protocol, and allow the user to specify a robot ID at many points in
the client API.
* This change *cannot* be hidden from the user; all client programs will
have to change to use the new client APIs, at least if they want to talk
to a robot with an ID other than 0.
The Player/Stage project now has a lot of inertia and a lot of users, and I
think that we have to weigh this kind of modification carefully, taking into
account the costs and benefits. It's no good if we make the "right" decision
just because it's the most elegant, symmetric, or consistent thing to do, but
in the process drive away or otherwise piss off users who have a lot invested
in terms of client control code.
With this in mind, I think that adding the robot ID brings us little benefit,
compared to the cost.
I think that there is a better solution, which is to implement a kind of
"name server" functionality in Player. Here's how it could work:
* In the Stage .world file, rather than specifying a port for each robot,
you can specify a single "base port", and then give a keyword that tells
Stage (well, actually Player) to automatically find and use any free ports.
It's a fatal error if the base port is already in use.
* A client can connect to Player on the base port and ask which port
corresponds to a particular robot, then connect to that port. A robot
could be identified by a "name", which the Stage .world file already
As a result:
* Client libs would have to change only if they wish to support the name
* The old way of doing things (i.e., specifying ports explicitly) is still
available, leaving most client code unchanged. Only those users who are
having trouble claiming a block of ports need to use a few new client lib
calls to access the name service.
* A single client that wants to control multiple robots still has to make
multiple connections, but that's all hidden by some kind of "multiclient"
mechanism that multiplexes the I/O with poll(), select(), or some
The only potential argument that I can see against this idea is that
maintaining a large number of open sockets might impact performance. Does
anyone have experience/information on that topic?
Importantly, the overall limit on the number of robots is not meaningfully
impacted: the robot ID is 16 bits, allowing 65K robots, and most POSIX systems
have ~65K ports.