EE122 Project #1: Echo Client and Echo Server

Due September 28, 2006, by 11PM

Updates and Announcements

Introduction

The client-server model is a very common way to build network applications. For example, when surfing the Web, your Web browser (the client - Firefox, say) requests data from a Web site, say www.yahoo.com (the server). In this project, you will build a client program that sends user input to a server program that echoes it back to the client. The goal of this project is to learn socket programming for both clients and servers. Note that in this project the network protocol is trivial (the server just copies whatever bytes it receives back to the client, without parsing them in any fashion).

This project consists of two phases. In phase 1, you build the client. The client should be able to communicate with the server run by the EE122 staff. In phase 2, you build the server program. The server program should be able to inter-operate with the client program you wrote in phase 1, as well as with the client program written by the EE122 staff.

General Instructions

  1. All code must be written in C or C++.
  2. Although this is not a software engineering course, we emphasize that you need to write clean, well-formatted and well-documented code.
  3. The programs must compile and run on the UNIX instructional account machines. We will not be able to grade programs that work only on Windows.
  4. Please do not hesitate to contact the TAs if you have any questions regarding the project, and/or send questions to the mailing list.

Client - Specifications

  1. The client program reads input from the keyboard (stdin).
  2. After the user enters one line, the client sends this line to the server. In phase 1, you will use the server at i1.millennium.berkeley.edu, port 7788 (for both TCP and UDP), run by the EE122 staff. (Note that the first part of the host name is "i1" [eye-one], not "il" [eye-ell].) The hostname and port number of the server is to be passed as command line arguments to the client.
  3. The client outputs the data received from the server to the console (stdout).
  4. The client repeats the above steps until it is killed with a Ctrl-C or stdin is closed (user enters end-of-file).
  5. The client uses TCP to communicate with the server. Extra credit will be given if the client can support UDP as well. The server run by the EE122 staff supports both UDP and TCP.
  6. The client must gracefully handle error conditions. For example, the server may not be running or may not respond to you or may unexpectedly close the connection.

Server - Specifications

  1. The server listens for TCP connections on a port, specified as a command line argument on startup.
  2. The server echoes back whatever data it receives on a TCP connection.
  3. The server must be able to handle concurrent connections from multiple clients. This will entail use of select(), as discussed in lecture; or, at your option, you can instead use threading (not covered in lecture, and for which the TAs can provide only limited support).
  4. Extra credit will be given if the server supports UDP as well.

Packet Traces

  1. You should include in your project submission packet traces recorded using tcpdump demonstrating the network traffic your client and server generate and receive. Tcpdump will be discussed in Section the week of Sept. 18.
  2. EE122 tcpdump tutorial: Please refer this tutorial if you have not used tcpdump before.
  3. You should also include a trace of what happens when you kill the server while your client is connected to it and you continue trying to send text to the server using the client.
  4. If you implement UDP as well as TCP for extra credit, include a trace of the client's behavior for each.
  5. Do NOT misuse tcpdump to spy on other's traffic or to compromise the security of the Berkeley computing infrastructure. Please refer the tcpdump tutorial for information on how to ensure that you analyze only your traffic.

Deadlines

Both phases of the project are due September 28 at 11:00 PM (Pacific Time). There is no separate deadline for the individual phases of the project. However, we encourage you to first complete phase 1 and test it against the server run by the EE122 staff, before working on phase 2.

Submission Guidelines

  1. You will need to submit the source code for both the echo server and the echo client, along with an appropriate Makefile to compile both the programs.
  2. The client should compile to a binary called echo_client.
  3. The server should compile to a binary called echo_server.
  4. Please submit a README.txt file that documents how to use your echo_client and echo_server programs and describes what the different trace files contain.
  5. Submission Steps:
    1. Make sure you are registered with the EECS instructional account system (different from registration for the class). You would have been prompted to register the first time you logged in to your instructional account. You can check your registration status by running the command "check-register". If you find yourself not registered, run the command "register".
    2. Log in to your instructional account.
    3. Create a directory called "proj1" : mkdir proj1
    4. Change to that directory: cd proj1
    5. Copy all the files that you wish to submit to this directory
    6. Run the submit program: submit proj1
    7. Make sure that no error messages are displayed. If some error occurs, retry. If it still occurs, contact the TAs.

FAQ and Clarifications

  1. What is the maximum size of the input to be handled by echo_client?
    Answer:The echo_client program should accept input from the keyboard that can be upto 2048 bytes long. Make sure you size the buffers in echo_client and echo_server appropriately.

  2. Clarification: send() : The send() function does not always send the entire data given to it. Make sure to compare the return value of send() with the number of bytes you intended to send . Repeatedly call send() till all the data is sent.

  3. Clarification: recv() : The recv() function call does not always read in all the available data in one go. You have to repeatedly call recv() till all the data is received. In this project, you know the number of expected bytes because it is equal to the number of bytes you had sent out. In project 2, you will use some other methods to know when all the bytes have been received. The server in project 1 need not make repeated calls - It can simply echo back whatever it reads. A subsequent read will handle leftover data, if any.

  4. I am getting a linking error when using the C++ compiler. What should I do?
    Answer: Make sure that /usr/sww/lib is included in the LD_LIBRARY_PATH environment variable.

  5. How do I fix the linking error I get when compiling my program on the Solaris instructional machines?
    Answer: Pass the options -lsocket -lnsl -lresolv to the compiler/linker.

  6. How do I test my server if my client isn't working?
    Answer: You should first be sure to get your client working using the staff server, as you will need quite similar (and more) functionality to implement the server.

  7. I am not sure about aspect X of the specifications. What should I do?
    Answer: Please contact the TAs via email, discussion section or office hours; or consider using the mailing list, as often your question will be of interest to other students too. Make sure you clarify the specifications of the project before implementing. You might save a lot of effort and avoid implementing something that was not required.

Grading