For this assignment, you must do a programming project in computer networking, appropriate in scope for the time alotted. You may do either a default project of my design, or one of your own choosing.
If you are choosing your own project, a description of your project must be turned in by 3/11/2011, and approved by the instructor. The only requirement on the project is that it must involve network programming. You are free to choose any language to program in and do not need to use the sockets interface if some other interface is more appropriate. However, in order to be approved, your project must represent significant effort.
If choosing this option, you will be programming a cacheing HTTP proxy, following the HTTP specification. You must program using the sockets interface, but may use any language you choose as long as it has a sockets interface. Java, C, or C++ are suggested. You many not use any libraries that implement a significant amount of HTTP proxy functionality for you.
The current version of HTTP is described in RFC 2616. The specification is long, but thankfully, you do not need to read and know all of it. A proxy server sits between the HTTP client and server, and is used to provide better performance, and services such as content filtering.
When your proxy runs, it should listen for incoming connections. When a client connects, it should read the HTTP request, parse out the requested URL, and check if the document is in its cache. If the document is in the cache, it should be returned. If the document is not in the cache, it should be requested from the server, cached if appropriate, and then returned.
How the cache is implemented is up to you. You do not need to cache responses with return codes other than 200. Other than this, you should follow the guidelines in Section 13 of RFC2616
Your proxy should work correctly with the firefox web browser (you can configure the browser to use a proxy in the network section of advanced prefrences). In order to make it work, you will most likely need to make your proxy multi-threaded so it can handle multiple requests at the same time.
If choosing this option, you will be programming a DNS client, following (a subset of) the DNS specifications described below. You must program using the sockets interface, but may use any language you choose as long as it has a sockets interface. Java, C, or C++ are suggested. You many not use any libraries that implement a significant amount of DNS functionality for you. Instead, you must craft the DNS packets yourself.
The DNS system is described across many standards documents, most importantly RFC 1034 and RFC 1035. You should begin by reading these documents to understand the DNS system. You client is only required to support queries for type A records. Your client also must be able to correctly understand CNAME records.
When run, your program should ask the user what host name they are interested in. It should then send appropriate queries though the DNS system and print the (entire) record the user requested. If there are multiple records corresponding to the requested information, your program must print all of them. If, after five seconds a response is not recieved to any query your server makes, your server should retry, up to three times.
Your client must make iterative queries, it should not set the recursion desired bit in any queries it makes. It can (and should) obtain the addresses of the root DNS servers from the root hints file. However, it should not need any additional information such as locations of TLD name servers. Instaed, it should obtain these through the query process.
An example of how the query process works is provided below.
Assume we want to do a DNS lookup for www.google.com. Our resolver first contacts one of the root DNS servers, asking for www.google.com. The response recieved contains no answer records, but in the authority records, it contains: com. 172800 IN NS i.gtld-servers.net. com. 172800 IN NS h.gtld-servers.net. com. 172800 IN NS d.gtld-servers.net. com. 172800 IN NS a.gtld-servers.net. com. 172800 IN NS j.gtld-servers.net. com. 172800 IN NS b.gtld-servers.net. com. 172800 IN NS m.gtld-servers.net. com. 172800 IN NS g.gtld-servers.net. com. 172800 IN NS e.gtld-servers.net. com. 172800 IN NS l.gtld-servers.net. com. 172800 IN NS c.gtld-servers.net. com. 172800 IN NS k.gtld-servers.net. com. 172800 IN NS f.gtld-servers.net. Additionally, A records with the IP addresses for each are in the additional records. So, we pick one of these and ask the question again. I will contact the first one, i.gtld-servers.net. Once again there are no answers, but the authority section leads me closer, saying: google.com. 172800 IN NS ns2.google.com. google.com. 172800 IN NS ns1.google.com. google.com. 172800 IN NS ns3.google.com. google.com. 172800 IN NS ns4.google.com. So, we ask one of these, ns2.google.com. Its answers contain: www.google.com. 604800 IN CNAME www.l.google.com. www.l.google.com. 300 IN A 18.104.22.168 www.l.google.com. 300 IN A 22.214.171.124 www.l.google.com. 300 IN A 126.96.36.199 www.l.google.com. 300 IN A 188.8.131.52 www.l.google.com. 300 IN A 184.108.40.206 This is sufficient to resolve the CNAME, and get the corrct IP addresses. Let's try anoter, www.amazon.co.uk. Again, we start at the root, again we get no answers, but some authority records pointing in the right direction: uk. 172800 IN NS ns4.nic.uk. uk. 172800 IN NS ns2.nic.uk. uk. 172800 IN NS ns3.nic.uk. uk. 172800 IN NS ns6.nic.uk. uk. 172800 IN NS nsa.nic.uk. uk. 172800 IN NS nsb.nic.uk. uk. 172800 IN NS ns5.nic.uk. uk. 172800 IN NS ns7.nic.uk. uk. 172800 IN NS nsc.nic.uk. uk. 172800 IN NS nsd.nic.uk. uk. 172800 IN NS ns1.nic.uk. Additionally, the IP addresses of each are contained in the packet. So we can pick one, I'll pick ns5.nic.uk, and send it our request again. In response we get no answers, but autority records containing: amazon.co.uk. 172800 IN NS pdns6.ultradns.co.uk. amazon.co.uk. 172800 IN NS ns1.p31.dynect.net. amazon.co.uk. 172800 IN NS pdns5.ultradns.info. amazon.co.uk. 172800 IN NS ns4.p31.dynect.net. amazon.co.uk. 172800 IN NS pdns2.ultradns.net. amazon.co.uk. 172800 IN NS pdns1.ultradns.net. amazon.co.uk. 172800 IN NS ns3.p31.dynect.net. amazon.co.uk. 172800 IN NS pdns4.ultradns.org. amazon.co.uk. 172800 IN NS ns2.p31.dynect.net. amazon.co.uk. 172800 IN NS pdns3.ultradns.org. Note that there was no step that returned authority records for co.uk. The uk domains seem to have skipped this step. This should not mess anything up though. We just ask one of our new authorities the same question. In response, we get no answers, but the authority section has: www.amazon.co.uk. 3607 IN NS ns-912.amazon.com. www.amazon.co.uk. 3607 IN NS ns-921.amazon.com. www.amazon.co.uk. 3607 IN NS ns-923.amazon.com. www.amazon.co.uk. 3607 IN NS ns-932.amazon.com. www.amazon.co.uk. 3607 IN NS ns-931.amazon.com. www.amazon.co.uk. 3607 IN NS ns-911.amazon.com. Ok, this is strange that we don't have an answer yet, but fine. Lets ask one more time, this time to ns-912.amazon.com. We get: www.amazon.co.uk. 60 IN A 220.127.116.11 Ok, great, we seem to be done.