|
|
||
|
The YAMI4 name server is a separate program that can be used for resolving readable names into network targets. Such a service can make it easier to manage large distributed systems, where remote targets have logical names instead of network endpoints.
For example, without such a service, YAMI4 programs need to address each other using their listener targets. The server can be started with the following listener target:
tcp://somemachine.company.com:12345
The client program that connects to this server needs to use the same target string to identify the network location of the server. This string has to be known to the client program and this can be achieved in different ways - it can be stored in the configuration file, passed as a parameter, etc. This is manageable in small client-server systems, but can quickly become difficult to maintain in a system with large number of servers playing different roles, as there is no connection between the target string and the purpose of the server - is the above server a weather forecast server or the air condition controller? Is it a calculator or a printer server?
A separate name service can help in administration of bigger systems, because it allows the user programs to operate on a higher level - for example, instead of storing the above target string in the configuration file, the client program can automatically ask the central name service for the location of an air condition controller. If such a name is stored in the name service, the service will reply to client with the actual target string. Such service can greatly reduce the number of targets that have to be maintained by all communicating parties, because in the ultimate case the target location of the name server can be the only one that needs to be known - all other locations can be announced and retrieved by means of the central name server.
This abstraction and hiding target string behind logical names is important not only for readability, but also to enable transparent server migration. In the above example, the air condition controller server can be moved to another machine or just started with a different port number and the clients will not need to be updated in order to take it into account - they will obtain the correct new location when they will ask for it the next time.
A typical client-server setup with the intermediate name service that will help the client find its server program each is shown on the following diagram:
Their interaction can involve the following phases:
Step 1. The server starts and creates its own listener - the resolved listener target is then sent to the name server to create a binding that will associate a logical name (for example ``calculator'') with a physical target; this step can be also understood as announcing the server's presence and location:
Step 2. The client queries name service to obtain the server's physical location. The location is already stored as an association in the name server and is returned to client:
Step 3. The client knows the physical location of its server and can initiate regular peer-to-peer communication in the usual way:
In order to enable this kind of interactions, the name server needs to provide at least two basic operations:
tcp://192.168.1.13:54635 under the name "calculator"."calculator" server.The YAMI4 name server implements these two operations and adds some additional ones. The complete ``API'' of the name server and its configuration are described in further subsections.
It is important to note that name server needs to offer persistent storage of its state in order to preserve it across system restarts. The YAMI4 name server uses local file storage for this purpose, which is an adequate solution for systems with up to several hundred logical names and with the advantage of being easy to manage. It is recommended to use a database server instead for distributed systems of higher complexity - this will require modifications of the implementation of name server.