Computer Science 461Distributed Computing and NetworkingFall 1997 |
The AcmeNet naming protocols use authenticated connections, allowing a name server to control which users can access which parts of the name space.
Your task is to implement two classes: AcmeNet.Assn4.Naming and AcmeNet.Assn4.NameService. The Naming class gives clients a convenient way to talk to a group of distributed name services, and the NameService class is a base class that all of the individual name services will extend.
Some AcmeNet services are name services: they speak the AcmeNet naming protocol. A client connected to a name service can send requests to the service and will receive replies according to the message formats defined in the AcmeNet naming protocol.
Name services play a role analogous to that of directories in the Unix file system. In other words, a name service provides a mapping from simple names (names without '/' characters) to services. Some of these services might themselves be name services; these name services act like subdirectories.
The result is that looking up a compound name like "/cs461/echo/swedish_chef" involves going to the root name service and looking up the name "cs461", then going to the name service returned by the first lookup and looking up the name "echo", then going to the name service returned by the second lookup and looking up the name "swedish_chef". (At any point in this chain of lookups, the search could fail because there was no mapping for a name, or because the requester didn't have permission to do a search.)
We have provided you with the class AcmeNet.Assn4.NameServiceOperationCode, which defines integer codes for four kinds of naming operations and two kinds of return codes for those operations. Each of these codes is sent along the connection as a single byte.
We will describe the protocol by describing the four kinds of requests one at a time. All data is send and received using DataOutputStreams and DataInputStreams, using the writeX method to send values of type X (and writeUTF for Strings). Several places in the protocol need to send a ServiceAddress; this is sent as a String followed by two ints. The String is the IP or DNS address of the machine, the first int is a port number on that machine, and the second int is the service number.
Note that a requestor may bind a service to a name even if another service was already bound to that name. This has the effect of removing the pre-existing binding and replacing it with the new one.
On receiving a valid Unbind request, the name service checks whether there is a binding for the received name, and whether the requestor has permission to unbind names. If there is a binding for that name and the requestor has permission to unbind the name, the binding is removed and a Success return code (a byte) is sent back. Otherwise, a Failure return code (a byte) is sent back.
On receiving a valid List request, the name service checks whether the requestor has permission to do the List operation. If the requestor has permission, the name service sends back a reply that consists of the Success result code (a byte), followed by the number of names bound in the name service (an int), followed by a sequence of Strings giving all of the names bound in the name service. (The names may be sent in any order.)
On receiving a valid Lookup request, the name service checks whether the name is bound and whether the requestor has permission to look up that name. If both of these conditions are satisfied, the name service sends back a reply message that consists of the Success result code (a byte), followed by the ServiceAddress of the service bound to the requested name. (The encoding for ServiceAddresses is described above.) If the name is not bound or the requestor does not have permission, the name service sends back a Failure result code (a byte).
The AcmeNet.Assn4.NameService class should provide implementations of the has*Permission methods that always return true, denoting that everybody has permission to do everything. Programmers can then change the permission rules by defining subclasses of NameService that override the permission-checking methods.
For example, the root name server implements a policy that allows everybody to do List or Lookup, but Bind and Unbind operations only if the name being bound or unbound is equal to the requestor's userid. This gives each student the ability to have a part of the name space in which nobody else can control name bindings.
The details of the Naming class are given in the on-line documentation.
Last modified: Friday, November 14, 1997<--webbot bot="Timestamp" endspan i-checksum="1341" -->