CS 6210 Project 4

This project is to be completed in groups of one or two. You may have groups of three if you like but there will be extra work assigned for such groups)

NOTE, there has been a change in the assignment. Please take the time to read over the section concerning CLIENTS. The quick summary is that you will be required to write your own clients due to the fact that I am letting you use either DataExchange or raw sockets. I have left the protocol on how the clients communicate to the servers up to your discretion.

Note that the server initial data files are available further down in this docuemt.

GOAL

You are required to implement a simple naming service (SNS) to allow clients to query a server with an internet hostname and get back the corresponding IP address for that machine. This is very similar to the way DNS works for most UNIX machines connected to the Internet.

You will be required to implement a SNS server that will act as either a primary server or as a secondary server as well as the concept of authoritative and non-authoritative answers. You must use either DataExchange or raw sockets as the communications substrate for this project. It is strongly suggested that you use DataExchange but there will be no penalty for using raw sockets.

CLIENT

A bind request is of the form:
{Success, NotFound} --> Bind( char* AccessId, char* Name, char* IP_Addr)
It returns a value representing the success of the call or that the name was not present. The AccessID is the unique identifier representing who is creating the entry in the name server. Only a call using this unique ID can subsequently unbind the name. Do no concern youself with authentication regarding this AccessID. By default all binds of names that are not present are considered to be non-authoritative to the server that they are initially issued to and must propagate up to the primary name server where they will be authoritative.

A lookup request is of the form:
{ASuccess, NASuccess, NotFound} --> Lookup( char* Name, char* Type, char* Attr)
It returns a value indicating whether it was an authoritative or non-authoritative success or that the name was not present. Authoritative means that the answer returns came from the name server that was directly responsible for keeping track of that particular hostname. Non-authoritative means that an answer was returned but it could have been from a cached value rather than from the one nameserver that is responsible for providing that information. Name is the name of the host that you wish to find the IP for, Type indicates whether it is authoritative or non-authoritative (A or N respecitively. Attr is used to indicate whether you are looking up a host based on IP or hostname. For the base assignment you need to implement the "A" attr which stands for the standard lookup where the user provides the hostname and the IP address is returns. For groups, you will have to implement the "R" attr as well which is the reverse situation where the IP address is provided and the hostname is returned.

An unbind request is of the form:
{Success, NotFound, NotAllowed} --> Unbind( char* AccessId, char* name)
It removes hostname and their corresponding IP address from the name service. It returns a value indicating that it was successfull, that you are not allowed to perform that function or that the requested hostname was not present. Note that the AcessID must match the one that was given in the initial bind for this to succeed.

Clients will be executed via the line

sns_client -s hostname portnumber

SERVERS

Resolution of queries will use a recursive server-controlled lookup. This means that when a client requests an authoritative resolution of a name, the server first attempts to resolve the request based on the information that it has received from its data file. If the response is non-authoritative then the server that responded will query its primary server for the correct response and then return that answer to the client. So the server performs the necessary multiple lookups rather than the client.

When a server resolves a name remotely, it caches that value in its own database. When a bind or unbind request succeeds, the value must be propagated up the hierarchy to the primary server and then back down the hiearchy to make sure that all the servers are consistent. Propagation should happen once every 30 seconds if needed. This is done to batch up requests and to minimize traffic between servers.

The format for the server's initial data file is:

HOSTNAME IP_ADDRESS AUTHORITATIVE
...
HOSTNAME IP_ADDRESS AUTHORITATIVE

There will be an unspecified number of lines in the file. HOSTNAME is always a sequence of alphabetic and numeric characters. IP_ADDRESS is a "dotted quad" of the form XXXX.XXXX.XXXX.XXXX where X can be any numeric character. AUTHORITATIVE is either the character "a" for yes or "n" for no indicating that this is an authoritative entry for this pair.

You should start up your primary server via something similar to
"server -f inital_file -p"
The server will print out to the screen its advertised connection port (usually a hostname and IP pair).

You will start up your secondary server via something similar to
"server -f initial_file -s hostname port"
Secondary servers should print out to the screen their advertised connection port (usually a hostname and IP pair).

The only real difference between the primary and secondary nameserver is that a primary server doesn't have a server that it can delegate unresolved requests.

Here are sample server files that you can use to test your project. The primarly.sns should be used to start up a primary name server. The other three file should be used to start up secondary name servers that look to the primarly nameserver for information.