The usual note:

• At the beginning of each file, you should include "COSC 4377, Fall 2001, Assignment #2", your NAME, and your E-MAIL address in the comment.
• Structural programming and good programming style are necessary.
• Comments / in-line documents for functions and variables are a must.
• You should provide a README file describing which platform (Linux/SunOS) or machine your programs have been successfully tested, how to compile your programs, how to run your programs, and any special note to TA.
• You should use RCS and Makefile. Here are the instruction for RCS and sample Makefile.
• You can discuss with your classmate, but no collaboration / copy. And your programs will be checked by MOSS (Measure Of Software Similarity) to find any similarity. Any student found guilty of academic dishonesty will receive severe punishment.
• You are responsible for ensuring the code you write is not readable by others.

Latest Hint:

• Start early. Start often.
   
• 10-03-2001:
  Whoops!! The time of deadline shoule be 11:59:59 PM.
  It's late to make major changes on the spec. It's ok to have error checking for "actions" on client or server side. But your client program must have some way to input incorrect/arbitrary actions and UID. As long as your programs can accept correct sequence (without major problem), you will receive at least 85% of grade for programming (which is 130 points).
• 10-01-2001:
  We extend one day for assignment #2. The new deadline 12:59:59 PM, Thursday, October 4, 2001.
• 09-24-2001:
  - Now you can use WebCT to discuss questions regarding assignments and other matters. You have to find your user ID first. The instruction can be found here. Once you get in, choose "Fall - COSC 4377" and then click "Discussions" from the menu at left-hand side. This page is still under construction.
  - Please DONOT run your program on letos. letos is a mail server and doesn't have all necessary programs installed. Please use redhat machines (redhat01 ~ redhat37) instead. You can use secure shell (ssh) to connect to redhat machines directly.
  - SSH clients for Windows: WinSCP.) And for academic and non-commercial use, you can also get SSH Secure Shell Client. (I was told its license might expire after 30 days. Unconfirmed.)
  - I have tried to compile sample programs from bayou.uh.edu (the actually machine you logon might be bay.uh.edu or creek.uh.edu). "cc" and "gcc" both work. I would suggest you use "gcc" for better portability.
• 09-20-2001:
  - If you want to write your programs on bayou, use "gcc" instead of "cc". In previous semesters there were some students reporting incompatiblity between bayou's cc and gcc.
  - Also, I would suggest you to run/test your programs on Linux machines (redhat??.cs.uh.edu) in 547 PGH. You can ssh directly into one of them. TA will grade your programs on one of Linux machines.
• 09-18-2001:
  Please be aware of firewall at CS dept. Most ports are blocked. If you try to run your programs on both sides of firewall (say one on bayou and the other on redha01.cs), it's likely you cannot get a connection.

Overview:

You will write two C/C++ programs using BSD sockets (using AF_INET and SOCK_STREAM) to implement a simple grade recording system which follows a homemade protocol to allow student to login, submit grade, query grade/average, and change password. There will be only one client and one server for this assignment.

1. Student first has to login with proper user id and password.
2. After authenticated, student can submit it's grade, query grades/average, or change its password.
3. If server receives a message which is incorrect UID, or unknown/unexpected action, this would be considered as an error. Server will send a message to client and ask for re-send a new message.
4. At any given time, server receives a good-bye (BBYE), the connection will be terminated.

The Protocol

Message format

Each message has 28 bytes which is consisted of 3 fields. For the sake of convenience, all data are stored as characters, and you can use a 28-character array to store a message (28th byte would be an end-of-string, "\0"). So you can use string functions (strcat, strncat, strcpy, strncpy, etc.) to construct messages or extract individual field.

• Unique ID (4 bytes): Unique ID is used as an identification between client and server, so client communicates with intended server. Unique ID is constructed by first two letters of your last name + first letter of your first name + last digit of your student ID. For example, UID of John Smith (student ID: 123-45-6789) is "SMJ9".
   
• Action (4 bytes): This is the action/command exchanged between client and server. Please see below for a detail list of actions.
   
• Data (20 bytes): This is where you store the user_id, password, grades, error messages, etc. Some actions do not require this field (for example, HELO).

Messages exchanged between client and server

The following state diagram describes messages exchanged between a client and a server.

Here is a list of actions with detail explanations.

Sent from	Actions	Data	Explanation
Client	HELO	-	send an connection request to server
	USER	user_id	send USER's id (user_id) to server
	PSWD	password	send user's PaSsWorD (passwd) to server
	SBMT	asgn# grade	SuBMiT grade for assignment asgn#
	QURY	AVG	QUeRY AVeraGe of all assignments
		GRD	QUeRY GRaDes of all assignments
	CHPW	new_passwd	CHange PassWord to new_password
	BBYE	-	notify the end of connection (Bye-BYE)
Server	NEED	USER	NEED USER's id
	NEED	PSWD	NEED user's PaSsWorD
	OLEH	user_id	say hello (OLEH) to user (user_id) after authentication
	RECV	asgn#	RECeiVe grade for assignment assgn#
	RPLY	AVG avg_grade	RePLY the query of average grade (avg_grade)
		GRD #1 #2 #3 #4	RePLY the query of grade of all 4 assignments
	PWOK	-	new PassWord has been changed
	BYED	-	reply the end of connection request
	EROR	messages	indicate an ERroR (incorrect UID, incorrect user_id/password, or unknown / unexpected action) with your messages

Requirements:

• The client and server program will use command line parameters to input server name (servername), port number (port_no), student information file (student.txt), and debugging mode (-d or "y"; see below). The commands would look like this. [Hint: you can use getopt() or argc/argv.]

          server -p port_no -f student.txt
          client -h servername -p port_no -d
  
      or  server port_no student.txt
          client servername port_no y
  

• A typical student information file would look like this. Each field is separated by one or more " " (blank).
  

          # user_id   password  grade#1  #2  #3  #4
            student1  password1   100     0   0   0
            student2  password2   0       0   0   0
            student3  password3   0       0   0   0
        

  You can assume there will be (<=) 5 students. And you can decide your own format (number of characters) of students' user ids and passwords, as long as you can match student's user_id and password. There will be 4 (four) grades for each student and each grade is a positive integral number (<= 100). You have to keep track of all students' info and update the file accordingly, so student information file reflects latest status (at the end of each connection). By the way, you don't have to implement the comment ("#") part.
  
  
• Only client program will need a user interface. Server program will (passively) response to client's request (construct and check messages automatically). For the sake of testing, you should provide two user interfaces for users (TA and you) to type in each filed (for all inputs).
  • Regular interface (mode): Users can type in Action and Data fields. (UID will be filled in by client / server programs.)
  • Debugging interface (mode): User can type in all fields (UID, Action, and Data), so error-handling can be tested.
  Regular or debugging mode should be activated by command line parameter, like "client -d -h servername -p port_no" or " client servername port_no y " to activate the debugging mode.
   
• You should print out entire message block of all messages exchanged for both client and server program with proper prefixes to identify message is sent or received (or from client or server). [Hint: there are lots of string related functions which will significantly shorten the time you spend on this assignment.]
   
• RCS and Makefile should be used. Here is the instruction for using RCS.
   
• If you plan to use Java (instead of C/C++), you should submit your program like everyone else, include a detail instruction on how to compile and run your programs, and make an arrangement with TA if your program only run on your own computer (likely TA will run your programs on CS's machines, such as redhat??.cs.uh.edu or bayou; do a demonstration if necessary.)

Discussion Questions (20 points):

Answer these questions and include them in your README file. The answers are usually short and should be less than 3-4 lines.

1. Our homemade protocol for grade submission assumes reply from server is always correct. If client receives message from server and finds UID is different, or unknown action, what is the best way to handle this kind of problem? Write a short paragraph (less than 3 lines) to state your solution.
    
2. Is this user id/password authentication safe? State your reason.
    
3. If your sever allows more than one client connecting to it, what kind of problems you might encounter which is not addressed in this assignment? And which part will you change in the design and/or protocol?
    

Submit your assignment:

• You should turn in your programs (client and sever), your student information file, Makefile, and README (with instruction and answers of discussion questions).
   
• You will use your CS account to submit your assignment. If you don't have one, please apply for one. If you can't get your CS account in time or having trouble with your account, e-mail submission to TA, Mark, or Dr. Subhlok will be accepted.
   
• Here is the command to submit your files.
  • Run the command from any of RedHat machines (redhat01 ~ redhat37).
  • Submission CMD:

        /auto/disk01/grad/cosc/y2000/zhu/4377/submit Assign#No FILE1 FILE2 FILE3 ...
    		

    where Assign#No is the number of assignment (it's "2" for this assignment), and FILE1, etc. are the file you want to submit.

Reference:

• A simple Socket example - a simple but sufficient example for this assignment. You can use this example as a base to implement your programs. I have added some debugging messages and you can download here (client.c and server.c). To run client program (modify source accordingly), "client <path>" or "client /usr".
• BSD Sockets: A Quick And Dirty Primer - a brief introduction to Sockets.
• BSD Sockets - a more detail introduction to Sockets with examples.i
• Spencer's Socket Site: Network Programming with Sockets - A good reference on Socket programming.
• Beej's Guide to Network Programming - Using Internet Sockets - A well-written guide for socket programming and it's easy to read. It also covers sockets for Windows.
• Unix Socket FAQ - Frequently Asked Questions about programming with sockets in UNIX environments.
• Davin's collection of UNIX programming links - an excellent resource for UNIX programming (including Sockets).
• List of known port numbers from IANA.org.
   
• A great UNIX network programming reference book, "UNIX Network Programming," by W. Richard Stevens, Prentice Hall, 1990. (ANDERSON/RESERVES QA76.76.O63 S755 1990). Sockets programming covered in 84 pages.
• Another book about client/server programming is " Power Programming with RPC," by John Bloomer, O'Reilly, 1991. (ANDERSON/RESERVES QA76.8.U65B4 1991 3-WK LOAN). You can find some sockets programming example from this book (actually the example in the first link is from this book.) Socket programming were covered in 25 pages.
• If you want to know how sockets is implemented, you should check out " TCP/IP Illustrated, Vol. 2 - The Implementation," by Gary R. Wright and W. Richard Stevens, Addison-Wesley, 1995. Sockets were covered in 124 pages.

Last modified: October 3, 2001.
tihuang at cs . uh . edu