The usual note:

• At the beginning of each file, you should include "COSC 4377, Fall 2000, 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 is the instruction for RCS. And a simple 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 for the assignment is not readable by others.

Latest Hint:

• 02-12-2001:
  

  Policy for late assignment (Assignment #2 only):

  • Due date: 11:59 PM, Wed., Feb. 14, 2001. You have a grace period of 10 minutes (to compensate inconsistent system time).
  • 10% penalty of full score (i.e., 20 points) for lateness per day. If you turn in after due date (plus grace period),
    • before 11:59 PM, Th., Feb. 15, 2001 (plus 10-minute grace period): off 20 points;
    • before 11:59 PM, Fri., Feb. 16, 2001 (plus 10-minute grace period): off 40 points;
    • before 12:00 PM (noon), Mon., Feb. 19, 2001 (plus 10-minute grace period): off 60 points;
  • No late assignment will be accepted after 12:00 PM (noon), Mon., Feb. 19, 2001 (plus 10-minute grace period).

• 02-08-2001:
  

  If you need to access Linux machines in 547 PGH from home (or anywhere outside 547 PGH), you can use SSH client to connect to it. For example, "ssh your_userid@redhat20.cs.uh.edu" will connect to redhat20 in the lab. You can run ssh from bayou, pegasus, or any SunOS machines in CS dept. Get PuTTY (and pscp) for your Windows system. Or visit www.openssh.com for clients for other platforms (look for "Alternatives" at left-hand side menu).

• 02-07-2001:
  

  Submit instruction has been posted. Also, the link to www.simtel.net (to get Windows/DOS version of RCS) is fixed.

• 02-05-2001:
  

  Couple things we mentioned in the class.

  • Error checking is only done in the sever side (checking messages from client). You can assume all messages from server are correct.
  • TA will not test your programs for minute errors (like incorrect field length for UID). The error-detecting functions that your sever program should have are checking UID, unexpected/unknown actions, and checksum errors.
  • Debugging mode is issued from command line and only need to be implemented on the client program.
  • Server will follow the state diagram.
    There is a mistake in the state diagram that a student pointed it out to me. If there is a checksum error in WTHD/DPST/QURY, the sever program should be able to accept a BBYE (besides WTHD/DPST/QURY). You don't have to correct this unless you want to.
  • Post your questions in the newsgroup (uh.nsm.cosc4377).
  • If you need RCS for DOS/Windows, do a serach on RCS at www.simtel.net.

  Also, here is a copy of simple Makefile.

• 02-01-2001:
  

  If you want to use Java on Solaris machine in 563 PGH, you can find instruction in Dr. Steven Huang's COSC 6390 web page.

• 01-31-2001:
  

  There is a mistake in the checksum function. It should add 48 to generate a printable numerical character, '0' ~ '9'.

  Also if you want to use Java for this assignment, please send an e-mail to TA, Mark, or Dr. Subhlok, so we can count how many students will use Java and arrange demo if necessary. Basically, you do exactly the same thing as other students. You can also use RCS/Makefile for your Java programs (using javac). And there is no need to implement a graphical interface. In your README file, you should also specify which version of Java you use and on which platform or machine (Windows, bayou, pegasus, Linux). Linux machines in 547 PGH have Blackdown Java-Linux: Java 2 - JDK 1.3 installed (under /usr/local/j2sdk1.3.0; change your path accordingly). TA will use equipments (on Linux, SunOS, and bayou) available in the department to test your Java programs. If you need to run on Windows JDK, you either test it on Linux/SunOS/bayou machine or bring your notebook/PC (or find one which works) to demo it.

Overview:

You will write two C/C++ programs using BSD sockets (using AF_INET and SOCK_STREAM) to implement a simplified banking system which follows a homemade protocol to exchange messages and perform withdraw, deposit, and query for customer's account. There will be only one client and one server for this assignment.

1. Greeting message (HELO/OLEH) will be exchanged before sending account info.
2. After verifying account is valid, withdraw, deposit, or query can be performed.
3. Each message includes a checksum which can be used to verify correctness of a message.
4. If server receives a message which is incorrect UID, unknown/unexpected action, or checksum error, this would be considered as an error. Server will send a message to client and ask for resend a new message.
5. At any given time, server receives a good-bye (BBYE), the connection will be terminated.
   

The Protocol

Message format

Each message has 15 bytes which is consisted of 4 fields. For the sake of convenience, all data are stored as characters, and you can use a 16-charater array to store a message (16th 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 (3 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 + last digit of your student ID. For example, UID of John Smith (student ID: 123-45-6789) is "SM9".
   
• Action (4 bytes): This is the action/command exchanged between client and server. Please see below for a detail list of actions.
   
• Data (7 bytes): This is where you store the account number, amount for withdraw/deposit, or amount in the account (from query). The amount of money is integral and is stored as character. Some actions do not require this field (for example, HELO). For the correction of checksum function (see next point), you should clean up this field with " " (blank), "0" (zero), "-" (dash), "z", or any printable ASCII of your choice.
   
• Checksum (1 byte): Checksum is used to check the integrity of the message. Here we use a simple function to generate the checksum, which is to sum the ASCII values of first character of ID, Action, and Data, and then modulate the sum by 10. [There is a mistake in the following function which couldn't generate printable numerical character, '0' ~ '9'. It should add 48 as an offset.]

  Checksum = (char) ( ( (int) UID[0] + (int) Action[0] + (int) Data[0] ) mod 10 + 48);

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
	ACCN	acc number	send ACCount Number (acc number)
	WTHD	amount	WiTHDraw amount of money
	DPST	amount	DePoSiT amount of money
	QURY	-	QUeRY account status
	BBYE	-	notify the end of connection (Bye-BYE)
Server	OLEH	-	response to client's connection request
	NOAC	-	NO such Account number
	GDAC	-	valid (GooD) Account number
	NEMN	-	Not Enough MoNey
	DONE	amount	requested withdraw/deposit/query is DONE (amount reflects new status of account)
	BYED	-	reply the end of connection request
	EROR	-	indicate an ERroR (incorrect UID, unknown / unexpected action, or checksum error)

 

Requirements:

• The client and server program will use command line parameters to input server name (servername), port number (port_no), account information file (account.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 account.txt
          client -h servername -p port_no -d
  
      or  server port_no account.txt
          client servername port_no y
  

• A typical account information file would look like this.
  

          # account_no   amount
            1112223      5000
            1112244      250
            223451       3010000
        

  You can assume there will be (<=) 5 accounts. And you can decide your own format (number of digits) of account number, as long as you can match the account number. You can assume at any given time, amount of money in any account will be less than 9,999,999. You have to keep track of all account and update the file accordingly, so account 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 and Checksum will be filled in by client / server programs.)
  • Debugging interface (mode): User can type in all fields (UID, Action, Data, and Checksum), 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 get instructor's approval and make a arrangement with TA (on which machine to run your program and maybe a domestication.)

Discussion Questions (20 points):

Answer these questions and include them in your README file.

1. Our homemade protocol for banking assumes reply from server is always correct. If client receives message from server and finds UID is different, unknown action, or checksum error, what is the best way to handle this kind of problem? Write a short paragraph (less than 3 lines) to state your solution.
    
2. Our checksum function is not robust in term of error checking. Identify two better checksum functions/algorithms which are commonly used.

Submit your assignment:

• You should turn in your programs (client and sever), your account 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 how to submit the programing assignment:

  At command line on CS SunOS machines (pegasus, chicken, etc.), type

    ~xsun/submit assignment# filename#
  	

  then, follow the instruction.

  For exapmle:

    ~xsun/submit 2 server.c client.c readme.txt
  	

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.
• Spencer's Socket Site: Network Programming with Sockets - A good reference on Socket programming.
• 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 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 covered in 124 pages.

Last modified: February 12, 2001.
tihuang at cs . uh . edu