From: brian g. <bg...@us...> - 2003-04-22 18:13:06
|
hi everybody, 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 Stage): * 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 change: * 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 supports. As a result: * Client libs would have to change only if they wish to support the name service. * 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 equivalent. 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. Comments? Opinions? brian. |