using network sockets write a c program called client that receives three command line arguments in the form no plagiarism 1
Lab L3 involves creating an HTTP client program and a separate HTTP server program. This is a networking assignment. I would highly recommend to start with the csapp echo client and echo server programs, and modify them to implement HTTP networking instead. Do not use Unix I/O or standard I/O for this assignment. Use csapp Rio instead, it’s better equipped for reading and writing to networks.
HTTP Client:
Example client usage: ./client www.google.com 80 /index.html ; would print the entire response from google.com (including headers and index.html contents) to stdout.
This would run the request specified in the assignment. Note that the default HTTP port (the well-known port) is port 80. You would send the header message specified in the assignment with the correct host and file filled in. You should not implement support for HTTPS, that is not an assignment requirement.
Note, the HTTP server will send back a response containing headers, followed by rnrn, then the body message which contains the actual file contents. One option for reading is to continually read until the number of bytes received is zero. This option is a bit risky, it requires the server to terminate the client connection, which is not a hard requirement for an HTTP server, and ultimately is an unreliable dependency. If the HTTP server does not close the client connection, then your program will loop indefinitely on read() and never terminate.
In general, network I/O is less reliable than file I/O. My suggestion would be to properly implement HTTP protocol parsing. In particular, Mozilla has a good writeup here on HTTP: https://developer.mozilla.org/en-US/docs/Web/HTTP/Overview#HTTP_flow. Note that the list of headers is terminated with the byte sequence rnrn, and one of the headers lists the size of the body message. Similar to the ICE “counter” example, you can parse and use this information to calculate how much your client needs to read in. Then, the client can terminate the connection once it is finished reading.
Note: google.com uses chunked transfer to send HTTP responses. It is not difficult to implement support for, but is not a hard requirement. Test on another website (such as your Tux website) if you do not want to deal with chunked transfer encoding. An example of parsing chunked transfer is located here: https://en.wikipedia.org/wiki/Chunked_transfer_encoding#Example. Each HTTP response will either have the Transfer-Encoding or Content-Length header, so, parse it out appropriately and use the header information to appropriately read the body message.
HTTP Server:
Example server usage: ./server 80 ; will host the server locally (host 127.0.0.1) on port 80.
Similarly, your server needs to implement HTTP. So, you will read in the client headers and send back response headers along with the correct file contents. See the Mozilla example above for appropriate HTTP response headers. In particular, send back “HTTP/1.1 200 OK” and the “Content-Length” header for the body message. Follow the protocol exactly, use rnrn to terminate the header message and then follow it with the body message. The server will continuously run and listen for client connections, and will read each client message and send back an appropriate HTTP response.
Once your client program is finished, you can write your server program and use your client program to test your server (have the client call the server at host 127.0.0.1, with the appropriate port and file).
If an invalid HTTP message is sent, or the file requested does not exist, send back an appropriate HTTP error. So, like HTTP/1.1 404 Not Found or HTTP/1.1 403 Forbidden. Read up on the HTTP return codes, use appropriate codes. The server should always relay problems back to the client, it should never quit on an error.
Submission:
A zipfile is fine. In particular, include the two C files (client and server), a README, a Makefile that lets us compile both programs (ideally a target for client and a target for server).
The README needs to explain how you ran and tested your code. If it does not sufficiently explain this, you might not get full credit.
To ensure that we can correctly run and verify your program, you can write in the README some test cases, which give example command line usage of your code and detail the expected output. We will be looking for meeting the required specifications and for following proper HTTP implementation.
Test your code out part-by-part, do not try to write it all in one-go. Maybe write the network read/write loop first, then write an HTTP writer/parser, then implement that into the network logic. Do not over-complicate the problem.
Thanks,
