Copyright: (C) 1998 Free Software Foundation, Inc.
The gdomap daemon is used by GNUstep programs to look up distributed objects of processes running across the network (and between different user accounts on a single machine). The deamon is NOT used for lookup where two processes belonging to the same user are using a host-local connection.
If you are packaging GNUstep for inclusion in a software distribution you may want to skip to the final section of this document.
Usually the gdomap daemon is started at system boot time and binds itself to port 538. (See the GNUstep Build Guide for a sample startup script.) It expects to receive fixed-size request packets for registering, deregistering, and looking up distributed objects servers. The response packets vary in length depending on the type and content of the information requested. In addition, limited support for federation is provided by a rudimentary gdomap-gdomap communications protocol.
What follows is a description of gdomap from a developer perspective. For information pertinent for users, such as how to configure and start up gdomap, please see the man page for more information ("man 8 gdomap").
The name server is intended to work with both the UDP and the TCP protocols. It is intended that the TCP interface be used by GNUstep programs, while the UDP interface is intended primarily for communication between name servers on different machines.
A complete distributed-objects "conversation" between a client and a server looks like the outline below. The gdomap daemon only plays a role in the "pre-" and "post-" phases. Everything else is conducted "peer-to-peer" between the two GNUstep processes.
The fixed size of a request packet was chosen for maximum ease and speed of implementation of a non-blocking name server. The server knows how much it needs to read and can therefore usually do a read as a single operation since it doesn't have to read a little, figure out request length, allocate a buffer, and read the rest.
The server name length (bytes) is specified - no assumptions should be made about whether the name contains nul characters or indeed about the name at all. This is future-proofing.
Why UDP as well as TCP? The OpenStep specification says that a connection may be established to any host on the local network which supplys a named service if the host name is specified as '*'.
This means that the application must poll to see if it can find a server with the name it wants. The polling could take a huge amount of time!
To make this all easier - the server is capable of supplying a list of those hosts on the local network which it knows to have (or have had) a name server running on them.
The application then need only poll those name servers to find the service it wants.
However - to give the application a list of hosts, the name server must have got the information from somewhere. To gather the information the server has to poll the machines on the net which would take ages using TCP since attempts to talk to machines which are down or do not exist will take a while to time out.
To make things speedy, the server sends out GDO_PROBE requests on UDP to all the machines on the net when it starts up. Each machine which has a name server notes that the new name server has started up and sends back a GDOPREPLY packet so that the new name server will know about it.
Things are never perfect though - if a name server dies, the other name servers won't know, and will continue to tell applications that it is there.
Port type codes - these are used to say what the port is for so that clients can look up only the names that are relevant to them. This is to permit the name server to be used for multiple communications protocols (at the moment, tcp or udp) and for different systems (distributed objects or others). This guarantees that if one app is using DO over UDP, its services will not be found by an app which is using DO over TCP.
The communications protocol is identical for both TCP and UDP and consists of a simple request-response sequence.
Each request is a single message consisting of -
The total is always sent in a packet with everything after the service name (except the final byte) cleared to nul bytes.
Each response consists of at least 4 bytes and depends on the corresponding Request Type and where it came from as follows -
The following are used for communications between name servers -
The gdomap process is a system daemon used to coordinate
services between different machines. As such it should be
started (as root) at system boot time (if inter-host messaging
is desired), and you need to write the appropriate startup
scripts for your system and put them in place when the
package is installed.
Alternatively you may install gdomap setuid to run as root, and GNUstep programs will launch it on demand ... but this is not recommended as it provides lass control than when you write a proper startup script.
The default operation of gdomap is to probe the hosts on the
local network to find other machines with copies of gdomap
running, so that all the machines on the network can be kept
informed of the seervices provided by GNUstep servers.
This probing may be considered unfriendly by other users of the LAN, so it is usually better to provide a configuration file specifying the IP addresses of machines to be probed, and start up gdomap at boot time with the command line option to tell it to read the file.