DROS Namespaces

Maintained by: David Austin

1.0 Introduction
One of the primary design decisions for DROS was to free users from the problems of using fixed ports for servers (If fixed ports are used, then often they can be blocked by the OS when disconnections occur. Further, with fixed ports, it is impossible for multiple instances of the software to exist on the same CPU.).

To remove the fixed ports requirement, it is necessary for servers to advertise their locations (ports) to potential clients somewhere. In DROS servers advertise through the NameServer. The NameServer maintains a list of server names and their locations. Clients can query the NameServer to find the server they need.

The list of names stored in the NameServer is called a namespace. This document describes some of the details surrounding the namespace. The proper design and management of the namespace is fundamental to the ability of DROS to permit multiple instances of the system to run, both on a single CPU (e.g. for simulation) and on multiple CPUs (e.g. multiple robots).

2.0 Global Namespace
One important aspect of the namespace is that it should be global. It must span all of the robots (and stationary computers) that may interact with each other. Without a global namespace, it is very difficult to run multi-robot experiments because a client on robot1 cannot find the LaserServer on robot2 (it will find the LaserServer on robot1). There must be a method for specifying, as part of the search for a server, the robot that the server is on.

A similar argument can be made for configuration spaces. To allow multiple instances of DROS to run on the same CPU, the configuration used for each instance is also part of the server name. In the first instace, it is expected that the configuration space names will simply be user names. But there should be no implementation restriction requiring this.

The namespace entries have three primary attributes used for searches: the name of the server (must match), the name of the configuration and the name of the robot. The configuration name allows multiple instances of DROS to co-exist peacefully (and even share some parts), while the robot name allows for multi-robot experiments.

3.0 Namespace Searches
The namespace search order is important to ensure that the behaviour of the system is as expected/desired. It is also important that all users understand the namespace search order.

Suppose we are searching for the server Server, while running in the configuration Config, on the robot called Robot. The search order is as follows:

  1. Look for a namespace entry Server.Config.Robot
  2. If a possible listing exists for Server.Config.Robot, try to instantiate it
  3. Look for a namespace entry Server.Config.*
  4. If a possible listing exists for Server.Config.*, try to instantiate it
  5. Look for a namespace entry Server.*.Robot
  6. If a possible listing exists for Server.*.Robot, try to instantiate it
  7. Look for a namespace entry Server.*.*
  8. If a possible listing exists for Server.*.*, try to instantiate it

Thus, a user's configuration can override (replace) any server and a server on the same robot takes precedence over a similar server elsewhere.

Copyright 2002 David Austin