CS352-Project 2 Load-balancing DNS Servers Solved

In project 2, we will explore a design that implements load balancing among DNS servers by splitting the set of hostnames across multiple DNS servers.

You will change the root server from project 1, RS, into a load-balancing server LS, that interacts with two top-level domain servers, TS1 and TS2. Only the TS servers store mappings from hostnames to IP addresses; the LS does not. Further, the mappings stored by the TS servers do not overlap with each other; as a result, AT MOST ONE of the two TS servers will send a response to LS. Overall, you will have four programs: the client, the load-balancing server (LS), and two DNS servers (TS1 and TS2).

Each query proceeds as follows. The client program makes the query (in the form of a hostname) to the

LS. LS then forwards the query to _both_ TS1 and TS2. However, at most one of TS1 and TS2 contain the IP address for this hostname. Only when a TS server contains a mapping will it respond to LS; otherwise, that TS sends nothing back.

There are three possibilities. Either (1) LS receives a response from TS1, or (2) LS receives a response from TS2, or (3) LS receives no response from either TS1 or TS2 within a fixed timeout interval (see details below).

 

If the LS receives a response (cases (1) and (2) above), it forwards the response as is to the client. If it times out waiting for a response (case 3) it sends an error string to the client. More details will follow.

 

Please see the attached pictures showing interactions among the different programs.

  

More details  on the design

1. TS design: There are two TS servers which each maintain a DNS table consisting of three fields:

-  Hostname

-  IP address

-  Flag (A only; no NS)

 

For each query received from the LS, each TS server does a lookup in its DNS table, and if there is a match, sends the DNS entry as a string:  Hostname IPaddress  A

If the Hostname isn't found in the DNS table, the TS server sends nothing back. A TS server without the hostname in its local DNS table MUST NOT send any data to the LS or the client. DNS tables can be read from PROJ2-DNSTS1.txt and PROJ2-DNSTS2.txt respectively for TS1 and TS2. We will ensure that the two DNS tables have no overlapping hostnames. Note that DNS lookups are case-insensitive. If there is a hit in the local DNS table, the TS programs must respond with the version of the string that is in their local DNS table. Each TS maintains just one connection -- with the LS.

 

2.      LS design: The LS receives queries from the client and forwards them directly to

both TS1 and TS2. Since the DNS tables for TS1 and TS2 have no overlap, at most one will respond to any query. It is possible that neither of them responds. If the LS receives a response from one of the TS servers, it should just forward the response as is to the client. (As shown above, this string will have the format: Hostname IPaddress A as obtained from the TS that just responded.) If the LS does not receive a response from either TS within a time interval of 5 seconds (OK to wait slightly longer), the LS must send the client the message: Hostname - Error:HOST NOT FOUND  where the Hostname is the clientrequested host name.

The LS maintains three connections (and sockets): one with the client, and one with each TS server.

The tricky part of implementing the LS is figuring out which TS has pushed data into its corresponding socket (if at all one of them has), and timing out when neither has pushed data. Think carefully about how you will achieve this. Just performing recv() calls on the two TS sockets won't do it, since recv() by default is a __blocking call__: if you recv() on the TS1 socket but TS1 hasn't pushed any data, your LS program will indefinitely hang.

 

3.      Client: The client is very simple. The client sends requests only to the LS. The client also directly prints the output it receives from the LS. The client reads hostnames to query from PROJ2HNS.txt, one query per line. The client must write all the outputs it receives from LS into a file, RESOLVED.txt, one line per query. The client must NOT communicate directly with TS1 or TS2.

The client maintains only one connection -- with the LS.

 

4.      How we will test your programs: As part of your submission, you will turn in four programs: ls.py, ts1.py, ts2.py, and client.py, and one README file (more on this below). We will be running the four programs on the ilab machines with Python 2.7. Please do not assume that all programs will run on the same machine or that all connections are made to the local host.  We reserve the right to test your programs with local and remote socket connections, for example with client.py, ts1.py, ts2.py, and ls.py each running on a different machine. You are welcome to simplify the initial development and debugging of your project and get off the ground by running all programs on one machine first. However, you must eventually ensure that the programs can work across multiple machines. The programs must work with the following command lines:

python ts1.py ts1ListenPort python ts2.py ts2ListenPort python ls.py lsListenPort ts1Hostname ts1ListenPort ts2Hostname ts2ListenPort python client.py lsHostname lsListenPort

 

Here:

 

-  ts1ListenPort and ts2ListenPort are ports accepting incoming connections  at TS1 and TS2 (resp.) from LS;

-  lsListenPort is the port accepting incoming connections from the client at LS;

-  lsHostname, ts1Hostname, and ts2Hostname are the hostnames of the machines  running LS, TS1, and TS2 (resp.).