CSE 422 Computer Networking Fall 2015
Lab 2: Socket Programming – A Remote Backup System
Due: 11:59pm, Friday, 12/11/2015 1 Objective
The objective of this assignment is to gain experience in UDP/TCP socket programming. You will imple- ment a small remote backup system with a simple protocol to exchange information between server and client. With this backup system, you can use the client to list whatever files that have been stored in the remote server’s backup folder. You can also send a local file to be stored in that backup folder on the server. If you do not want a file any more, you have the client send command to remove that files from the server’s backup folder.
2 Specification
This protocol includes five command functions, “ls”, “send”, “remove”, “quit” and “shutdown”, as shown in Figure 1, 2, 3 and 4. Figure 5 is an example of how this system works. After the startup of the server and the client, user sends input command from standard input (such as keyboard) to the client interactively, then the commands received at the client will be sent over the network to the server. Then, there will probably be some messages exchanges between the server and the client. After that, the server will execute the corresponding functions and send back the information requested by the client. Specifically, when the client receives the “ls” command from the user, it queries the server and lists all the available files in the server’s backup folder. When the client receives the “send” command together with a specific filename from the user, this file will be sent to the server and the server will store it in the backup folder. In addition, if the client receives the “remove” command together with a specific filename from user, it will send the command to the server and the server will delete the file from the backup folder. The client uses “shutdown” command to stop the server and uses “quit” command to terminate.
Before discussing the protocol, we define two types of messages used for implementing the protocol. One is command message (Cmd Msg T) and the other is data message (Data Msg T). The command message is used to send the command and exchange the necessary information to assist the data transmission for the functions. For example, when you implement “ls” function, the “CMD LS” command is sent as command message. The number of files is also sent back to client as command message to assist future filename reception. However, the exact filenames are sent as the data message.
1
2.1 Command and Data Message
The command message contains the following three fields. To support communication between different computer architectures, we use data types defined in the stdint.h library. The message data type is defined in message.h. The command message (Cmd Msg T) contains the following elements:
• command type: 8 bits unsigned integer (uint8 t) • filename:character[FILENAMELEN]
• size: 32 bits unsigned integer (uint32 t)
• port: 16 bits unsigned integer (uint16 t)
• error: 16 bits unsigned integer (uint16 t)
Please note that not all the elements will be used in a single command transmission. For most of the command message, only part of its elements are used in that transmission. The data message (Data Msg T) contains:
• data:character[DATABUFLEN]
For this assignment, we define FILE NAME LEN to be 128 and DATA BUF LEN to be 3000. Here we notice that the size and port are multi-byte integers. Transmitting them directly over the network would encounter some problem if the sender and receiver have different architectures and use different byte orders to represent integers. This potential problem can be solved by using htons() and htonl() to convert the size and port from the host machine byte order to the network byte order on the sender side for transmission. Thus the receiver can use ntohs() and ntohl() to convert the received data back to host machine byte order. However, this problem will rarely happen in your testing environment. But note that when you obtain the port number from operating system, the operating system gives the port number in network byte order and also when you use the port number to transmit message, the operating system can only understand the port number in network byte order.
2.2 “Waiting” state for user input
After the startup of the server program, the server initiates a UDP socket on a port. The port number can be given from command line or assigned by operating system automatically if none is given from command line. The server will then print out port number and wait for the UDP command from the client on this port. After the startup of the client program, the client will print “$ ” and wait for any command from standard input (keyboard) and send the UDP command message to the server via the server’s UDP port. The following message shall be printed to the console
- afterthestartupandeverytimewhentheserverenters‘Waiting”state,theservershallprint“Waiting UDP command @: xxxxx”. (xxxxx is port number)
- if the command from user is neither of the supported commands, the client shall print “ – wrong command”
- if server receives a command, it shall print “[CMD RECEIVED]: xxx”. (xxx is the command label in type Cmd T). See the example at the end of this handout.
2
2.3 “ls” command
This function lists the available files in the server’s backup folder. It uses the UDP socket. Figure 1 shows the detailed procedure to implement this function. After the startup of the server and the client program, if there is an “ls” command input from user, the client will send this command through a command message with “cmd = CMD LS” to the server. After receiving this message, the server will check the backup folder and send back a message with “cmd = CMD LS” and “size = N” to inform the client the total number (N) of files that it has. If there is no files in the folder or the folder does not exist, the server will send this message with “size = 0”, otherwise the server will transmit each filename through a data message to the client and the client will display each filename upon the reception. Upon the completion of the “ls” function, both the server and the client will return to initial states where the next command can be received from user input. Following are messages that need to be printed to the console.
•
•
• •
if the server finds the backup folder is empty, the server shall print “ – server backup folder is empty” on the server side
if the client receive the message indicating that the server is empty, the client shall print “ – server backup folder is empty” on the client side
the server and the client shall print out each filename with prefix “ – ” in a single line, respectively
if the client receive a message with a “cmd” field other than “CMD LS”, it shall print “ – command response error.”
Figure 1: “ls” command.
“send” command
This function sends a specific file to the server and the server will store it in its backup folder. It uses both the UDP and TCP sockets to implement the funciton (Figure 2). After the startup or the completion of the previous command, both the server and the client are in the waiting status for the next user input. If the command “send myFilename” is received from the user, the client will send the UDP message with “cmd=CMD SEND”, “filename=myFilename”, “size=filesize” and “error=0” to the server. Please note that any normal messages should have a “error=0”. Upon the reception of the command message and file information, the server will check if a file with the same name exists in the backup folder. The protocol will be slightly different depending on the existance of the file in the backup folder.
2.4
3
If the file already exists, the server will send back an error message with “error=2” and “cmd=CMD SEND”, and print “file xxx exist; overwrite?”. (Please note that error message has the same structure as a normal message, but a nonzero error code). Once the error message is received by the client, the client prints “file exists. overwrite? (y/n):” and waiting for the user input from keyboard. If anything other than “Y” or “y” is received from the user, the client sends an error message with “error=2” and “cmd=CMD SEND” to the server. Once this error message is received by the server, the server will return back to “Waiting” states, and so does the client. If the user input is “Y” or “y”, the client needs to send a normal message with “error=0” and “cmd=CMD SEND” to the server.
If the file does not exist in the backup folder or a normal message “error=0” and “cmd=CMD SEND” is sent from client in the previous step and received by the server, the server opens a file with the received filename in the backup folder. Then the server will open a TCP connection with a port number assigned by the operating system and send this TCP port number back to the client. Then, the server will wait at this port for the connection from the client for the file data reception. If the server cannot open a file for future writing, the server will send back to the client an error message with “cmd = CMD SEND”, “port=0” and “error=1”. In this case if client receives “error=1”, both the client and the server will return back to ”Waiting” state.
Figure 2: “send” command.
After receiving the message with a nonzero TCP port number, the client initiates the handshaking with the server at that TCP port. If the connection is established, the client will divide the original file into several segments and send each to the server until the end of file is reached. When the file data transmission completes, the client will wait for the acknowledgment message from the server. The server will write each received segment to a local file in the order of the reception. Once the server receives the whole file, the server will close the file and send back a message with “cmd=CMD ACK” and “error=0” to the client and both the client (after receiving this acknowledgement) and the server will close the TCP connection, and then return to the ”Waiting” state for the next user command. During the reception, the server shall
4
print out the total number of bytes received after each reception(Figure 5). If any error happened during the server reception, the server will terminate the reception and send back the acknowledge message with “error=1”. Following messages shall be printed to the console
if the client receives “error=2”, it shall print “file exists. overwrite? (y/n):” and wait for user input if the server receives “error=2”, it shall return to ”Waiting” state
if the client cannot open the file for sending, it shall print “ – cannot open file: xxx”. (xxx is filename), otherwise it shall print “ – filesize:xxx”. (xxx is filesize in bytes)
if the server fails to open a file for writing, it shall print “ – open file xxx error.”, otherwise it prints “ – filename:xxx” and “ – filesize:xxx”
if TCP binding is listening on a port, the server shall print “ – listen @:xxx”. (xxx is TCP port number) if server successfully accepts the connection request, it shall print “ – connected with the client.”
if any error happens during the message reception on the server, the server shall print “ – message reception error.”
if the server sends the acknowledgement, it shall print “ – send acknowledgement”.
if client receives “port=0”, “cmd≠ CMDSEND” or “error=1” from the server, the client shall prints “ – error or incorrect response from server.”, otherwise it prints “ – TCP port:xxx”. (xxx is port number)
if client receives an acknowledgement without error (error=0), it shall print “ – file transmission is completed.”, otherwise it prints “ – file transmission is failed”
Figure 3: “remove” command.
“remove” command
This function removes a file from the server’s backup folder (Figure 3). The procedure starts from the wait-
ing status of the server and the client. During the waiting status, if the command “remove myFilename”
is received from the user input at the client side, the client will send a command message with “CMD REMOVE”
and “filename=myFilename” to the server. Then server will try to delete this file from the backup
folder. If the file exists, the server will perform the deletion and send a acknowledge message with “cmd=CMD ACK” and “error=0” . If the file does not exist, the server will send back the acknowledge message with “error=1”. Following messages need to be printed out to the console.
• if the corresponding file is not in the backup folder, the server shall print “ – file doesn’t exist” • if the client receive with “error=1”, it shall print “ – file doesn’t exist.”
• • •
•
• • •
• •
•
2.5
5
2.6 “quit” and “shutdown” command
The quit command is designed for client to quite from execution. Once the client receives this com- mand, it shall exit the program. There is no need to communicate with server before quiting. However, the shutdown command is designed to be sent from the client to the server to shut the server down (Figure 4). If a shutdown command is received by the server, it sends back an acknowledgement with “error=0”, then exits the program. The client will turn to waiting status after receiving this acknowledgement. You may need to send back “error=1” if you implement the bonus part as other transmissions may be in progress during the shutdown request.
Figure 4: “shutdown” command.
2.7 Socket error handling
The socket errors should be handled by the server and client program as follows.
•
• • •
2.8
1.
for any server and the client functions, if it fails to create or bind the socket, it shall print “ – failed to create/bind TCP/UDP socket”
if the server fails to accept the TCP request, it shall print “ – failed to accept TCP connection”.
if the client fails to establish TCP with server, it shall print “ – failed to connect server with TCP”. in all the above situations, the program shall exit.
Program Requirements
(server side) Use “server” as the name of your server executable. The server program shall be invoked from command line and it may require an argument which indicates port number used for UDP command reception. If there is no command line input for the argument, the server shall ask the operating system to choose a port number. In either way it shall print that port out to the console as mentioned before. You shall then use that port number as an argument to start the client so that the client can use this port number to send UDP commands.
• -p may be used to specify a port number. This can be omitted so that the operating system will choose a port number.
Example invocation: ./server -p 35887
(client side) Use “client” as the name of your client executable. It should have the following two arguments.
2.
6
• -s is used to indicate the server address [default: 127.0.0.1]. This argument can be omitted if the server is local. If the server is a remote computer running Debian Linux, you can run /sbin/ifconfig on the server to check the address of the server.
• -p is the UDP port command transmission. (udp port). It cannot be omitted. It ranges up to 65535.
Example: ./client -s 35.9.42.35 -p 35887
When the client starts, it will wait for the user input from the command line.
3. You need to run the server and client on different computers to test program. Their correct execution on the same computer doesn’t necessarily guarantee that they can work correctly over the network.
2.9 Deliverables and Grading
You can download a package of skeleton files from the course website. You can choose to use either C or C++, but the skeleton file is given as C++. If you use C, you need to change the compiler in the Makefile. You do not need to follow the skeleton at all, but it may help you focus on socket programing. You can also use the provided executables to test your implementations of client/server, especially if you plan to complete part of the assignment described later. These executables are compiled and linked on black server. After you test your program, you need to deliver following files.
server.cc – server source code
server.h – server header
client.cc – client source code
client.h – client header
message.h – message formats shared between server and client *.cc and *.h – any extra source code required for the program makefile – compilation script to produce executables
You need to submit all the aforementioned deliverables to make sure your program can compile, even if you do not change some of them. However, you can come up with a completely different file structure, as long as it can compile by using makefile. If you only complete part of the assignment, the entire package shall still compile and you need to describe what exactly is implemented in README.txt file. If there are any extra comments for your programs, please submit a README.txt file to include your comments. The code should compile and link on adriatic.cse.msu.edu. Programs that do not compile will receive a zero score. Please test your programs and make sure they can compile before handing them in.
The executables are provided so that you can use them to test your program. For example, you can use the server’s executable “server” to test your client program and vice versa. Following is the score assigned for each module.
• client “ls” function – 25pts
• client “send” function – 15pts
• client “remove” funciton – 5pts
7
• client “quit” function – 5pts
• client “shutdown” function – 5pts • server “ls” function – 20pts
• server “send” function – 15pts
• server “remove” funciton – 5pts
• server “shutdown” function – 5pts
Please note that for “send” function, you need to make sure that the file received on the server side is correct. That is, the file received at the server must EXACTLY match the file sent by the client. You can transmit a binary file (pdf or image) to test the integrity of the file by opening it after transmission over the network. Another way is to use program ’diff’ to compare the two files. A pdf file will be used for grading. If the file received is not correct (cannot open, incorrect file size, etc.), 30% will be deduced from your score of “send” function.
If your program can only work locally, you will receive 10% deduction in the final score.
Bonus score: 15pts. The current implementation of the backup system can only handle one client at a time. For example, if client A is transmitting a large file to the server, client B cannot send any command to the server. Also the client has to wait for the completion of the current command before it can send another new command. This bonus assignment requires you to design the system so that the client/server can send/receive new command while another command is still being executed. Hint: you may consider using multi-thread/process programing (be careful with the port used for different threads/processes). You can make necessary changes to the protocol for this bonus assignment. For example, you can add/remove the messages exchanged between the client and server if neccessary. However, you need to make sure that the server uses the same port number for all the incoming commands. When you print the message to the console, add “task:xxx” (xxx is process id or a number that can be used to differentiate the concurrent command tasks) in front of all the messages. Please note that your system shall be able to handle the situation when two clients simultaneously request to overwrite the same file. To submit a solution for this bonus assignment, you need to describe the details of design for the system in a file and include the filename in your README.txt file.
You should submit your source code via the handin utility. Late submissions will not be accepted.
3 Example Output
8
Figure 5: Example of the client (left) and server (right).
9