Description
• Overview 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 PROJ2- HNS.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.). We will provide the input files PROJ2-HNS.txt, PROJ2-DNSTS1.txt, and PROJ2-DNSTS2.txt. You must populate RESOLVED.txt from the client. The entries in the DNS tables (one each for TS1 and TS2) will be strings with fields separated by spaces. There will be one entry per line. You can see the format in PROJ2-DNSTS1.txt and PROJ2-DNSTS2.txt. Your server programs should populate the DNS table by reading the entries from the corresponding files. Your client program should output the results to a file RESOLVED.txt, with one line per result. See the samples attached in this folder. We will test your programs by running them with the hostnames and tables in the attached input files (*.txt) as well as with new hostnames and table configurations. You will be graded based on the outputs in RESOLVED.txt. Your programs should not crash on correct inputs. 5. README file In addition to your programs, you must also submit a README file with clearly delineated sections for the following. 1. Please write down the full names and netids of all your team members. 2. Briefly discuss how you implemented the LS functionality of tracking which TS responded to the query and timing out if neither TS responded. 3. Are there known issues or functions that aren’t working currently in your attached code? If so, explain. 4. What problems did you face developing code for this project? 5. What did you learn by working on this project? Submission: Turn in your project on Sakai assignments. Only one team member needs to submit. Please upload a single zip file consisting of client.py, ls.py, ts1.py, ts2.py, and README. Some hints Run your programs by first starting the TS programs, then the LS program, and finally the client program. There are a few methods to turn a blocking recv() call at LS into a call that will return, possibly after a timeout. One possibility is to use a non-blocking socket. Another is to use the system call select(). Multithreading may help, but is not necessary. DNS lookups are case-insensitive. It is okay to assume that each DNS entry or hostname is smaller than 200 characters. START EARLY to allow plenty of time for questions on Piazza should you run into difficulties.
