44100113: COMPUTER NETWORKS FALL 2023 Assignment: Socket Programming - FTP Server and Client
44100113-0: COMPUTER NETWORKS FALL 2023
Socket Programming
Assigned: September 28, 2023 Due Date: 23:59, October 22, 2023
Section 1-2 describe the assignment.
Section 3-6 provide very useful information to finish this project.
1 ASSIGNMENT
You must work on this assignment individually.
This project is designed for you to:
• LearntosetupcommunicationsbetweenPCswithsocket.
• TobefamiliarwithFTPprotocol.
• Tobefamiliarwithnetworkprotocolstack.
• Learntobuildclient/serverapplicationsthatcommunicateusingsockets.
Before writing this project, you need to finish the following task, which gives you basic ideas for UDP programming:
-
Readthegivenprogramslocatedinudpdirectorycarefully.Youmaychooseanylanguagethatyou are familiar with.
-
ModifytheUDPServer.Theservercountsthenumberofmessagesitreceivedandrecordsitasase- quence number. For each string the server received, add the sequence number before the received string and return the whole string back to the client. For example, if the server received “hello” and the sequence number now is 1, return the string “1 hello” back to the client.
-
Modify the UDPClient. Let the client send messages with the number from 0 to 50 to the server. The server then returns all messages with the sequence numbers described above.
-
Answer:Howtowriteachatprogram(twoclientschatwitheachother)withUDP?
Then, you will be asked to create, from scratch, a miniature FTP server with the following characteristics:
• Yourservermustservefilesfromadesignateddirectoryonyoursystemtoclientsmakingrequests on a designated TCP port.
1
-
Your server must handle USER, PASS, RETR, STOR, QUIT, SYST, TYPE, PORT, PASV, MKD, CWD, PWD, LIST, RMD, RNFR, RNTO commands from the clients. You may support other commands.
-
You may assume that all data connections will be binary - i.e., you can choose to ignore TYPE A
requests. Binary mode means that you should transfer the data without modifying/converting it in
any way.
-
You must use the Berkeley Socket API and write your server in C, which indicates that you must
write your server running with GNU/Linux. You may not use any libraries containing code specifi- cally designed to implement FTP functionality. We suggest that you compile your code with gcc or clang.
-
Each Unix vendor has its own special version of the “make” program builder, and each one has its own special beloved features. For this project, we will require that you use GNU Make. The makefile for this project should be trivial.
-
Ifyourserveremitsdebuggingortraceinformationonthestandardoutputorstandarderrorstreams, it should suppress this output.
-
Handlinginvalidinputreasonablyandgeneratingdefensibleerrorcodes.
-
Supportintegrallargefiletransmission.
-
Supportconnectionsfrommultipleclientssimultaneously.
-
(Optional)Resumetransmissionafterconnectionterminated.
-
(Optional)Filetransmissionwithoutblockingtheserver.
Finally, you will also be asked to create a simple FTP client with the following characteristics:
-
Youcanwriteyourclientinyourfavoriteprogramminglanguage,butanyFTPlibraryisnotallowed. Your client can run with GNU/Linux, Mac OS X, or Windows as you wish.
-
Your client must use USER, PASS, RETR, STOR, QUIT, SYST, TYPE, PORT, PASV, MKD, CWD, PWD, LIST, RMD, RNFR, RNTO commands to log in a common server and download/upload files as well as manipulating directories.
-
Youmaysimplyusebinarymode.
-
YourclientisabletologinaprovidedcommercialFTPserveranddownload/uploadfiles.
-
Supportintegrallargefiletransmission.
-
(Optional)Resumetransmissionafterconnectionterminated.
-
(Optional)User-friendlyGUI.
-
(Optional)FiletransmissionwithoutblockingtheGUI.
NOTE: You will get 5 extra points for each optional completion, but no more than 10 extra points in total. Project deliverables:
Your modified UDP programs must be placed in udp directory. Leave the filenames without any change. For the question in UDP part, write a plain text file in English or Chinese.
Your server must be named “server”. It must accept, in any order, the following command line arguments:
-
-port n: An ASCII string representing the TCP port number your server will bind to and listen for requests on. If you do not receive this argument, default to port 21.
-
-root /path/to/file/area: The pathname of the directory tree that will serve as the root for all re- quests. If you do not receive this argument, default to “/tmp”.
Your client must be named “client”. Your files are to be organised as follows:
2
studentID.zip
studentID
udp
server
client
src: your code
doc: answer to the question
src: your code
src: your code
executable file
doc: how to run the file and the running environment
report.pdf: see next section
Note that if you write a Windows client, you need to submit an executable program. If you use Java, you need to package your program into a jar file.
2 GRADING GUIDELINES
-
If your project generates compiler warnings, you will lose credit; if your server dumps core dur- ing our testing, you will lose substantial credit. Handling invalid input reasonably and generating defensible error codes are fundamental parts of writing any server program.
-
Poor design, documentation, or code structure will probably reduce your grade by making it hard for you to produce a working program and hard for the TA to understand it; egregious failures in these areas will cause your grade to be lowered even if your implementation performs adequately. Putting all of your code in one module counts as an egregious design failure.
-
Yourprojectwillbegradedbasedonthefollowingfourparts:
-
UDPprogramming(10)
If you implement the program correctly, you will get full mark of 10. -
ImplementationofFTPprotocol(70+10)
If you implement the server and it works, you will get 40 credits. If you implement the client and it works, you will get another 30 credits. If you complete any two optional requirements, you will get 10 extra credits. -
Projectreport(20)
You can include a short introduction to your FTP, FTP commands you implemented, etc. in your report.
Anything you think valuable, e.g., difficulties you encountered, your innovative ideas, can be included in the report. However, the report should not be longer than THREE pages.3 FTP BACKGROUND
An FTP server is a program that listens for incoming TCP connections (typically, but not always, on port 21). The client connects to the server on port 21. It sends commands to the server via this connection and receives the replies from the server over this same connection. These commands and replies are made up of special 3 digit codes and plain text strings. Actual data transfers (file transfers, directory listings etc.) is
-
3
done via another connection specified via either the PORT or the PASV command. The PORT command allows a client to tell the server which IP address and port number to connect to to send/retrieve data. The PASV command allows a server to tell a client which IP address and port number to connect to to retrieve/send data. The FTP protocol has many optional features that allow an implementation to be bewilderingly complicated and bug-ridden.
Tutorial material on FTP is available in Ftp by Example (https://www.cs.colostate.edu/helpdocs/ ftp.html); we suggest you start by reading this. D. J. Bernstein has a lot of information on the exact strings and commands expected by FTP servers and clients at http://cr.yp.to/ftp.html. As is the case with most Internet protocols, the authoritative definition is found in “Request for Comments” (RFC) documents. FTP was defined by Internet RFC 959 (http://www.ietf.org/rfc/rfc959.txt). This RFC defines everything about the basic FTP protocol. However, it is a long, dense document and we do not expect you to read it thoroughly. It is provided for your reference only. There have been additions to the FTP protocol in RFC 2640 (http://www.ietf.org/rfc/rfc2640.txt) and RFC 2228 (http://www. ietf.org/rfc/rfc2228.txt). You will not need to implement any of the additional features added to FTP by these 2 RFCs.
3.1 LOGGING IN (USER/PASS COMMANDS)
FTP servers require clients to log in before allowing those clients to access the files on the server. For the purposes of this assignment, you only need to implement anonymous logins. I.e., the username of the client should be anonymous. The server should respond with the appropriate string (which has the right command codes embedded in it) asking the client for the password, which should be just the users email address. The user should then be able to respond with an email address as the password. The strings to support are thu
123-This line does not end the mark; note the hyphen 150 This line ends the mark
226-This is the first line of the second response
7
226 This line does not end the response; note the leading space 226 This is the last line of the response, using code 226
Servers are required to follow several more rules. Each line of the response is required to contain \r im- mediately before the terminating \n. If the answer has more than one line, its first line is required to begin the same way as the last line, but with a hyphen in place of the space.
RFC 959 prohibited all codes other than 110, 120, 125, 150, 200, 202, 211, 212, 213, 214, 215, 220, 221, 225, 226, 227, 230, 250, 257, 331, 332, 350, 421, 425, 426, 450, 451, 452, 500, 501, 502, 503, 504, 530, 532, 550, 551, 552, and 553. (Typically the second digit is 0 for a syntax error, 1 for a human-oriented help message, 2 for a hello/goodbye message, 3 for an accounting message, or 5 for a filesystem-related message.) However, clients cannot take this list seriously; the IETF adds new codes at its whim. Hence, many clients avoid looking past the first digit of the code, either 1, 2, 3, 4, or 5. The other two digits, and all other portions of the response, are primarily for human consumption. (Exceptions: Greetings, responses with code 227, and responses with code 257 have a special format.)
Servers must not send marks except where they are explicitly allowed. Many clients cannot handle un- usual marks. Typical requests do not permit any marks.
Some clients are unable to handle responses longer than one line to various requests, even though RFC 959 permits multiple-line responses under most circumstances. The client we are using for testing sup- ports multi line responses in some cases (see example in Section 4). Hence, use one-line responses when- ever in doubt.
The server can reject any request with code
• 421iftheserverisabouttoclosetheconnection; • 500,501,502,or504forunacceptablesyntax;or • 530ifpermissionisdenied.
Typically 500 means that the request violated some internal parsing rule in the server, 501 means that the server does not like the format of the parameter, 502 means that the server recognized the verb but does not support it, and 504 means that the server supports the verb but does not support the parameter.
RFC 959 states that codes 400 through 499 are for temporary errors, and codes 500 through 599 are for permanent errors.
3.6 MULTI-CLIENT SUPPORT
An FTP server that accepts only one connection at a time is probably impractical and definitely not very useful. As such, your server should also be written to accept multiple connections (usually from multiple hosts). It should be able to simultaneously listen for incoming connections as well as keep reading from whatever connections are already open.
Unfortunately, many of the calls you will use (eg. accept(), recv()) are blocking calls, that is, they go to sleep and stall program execution until some data arrives. So if your server is blocking on an accept() call, for instance, it cannot receive() data at the same time. This could lead to starvation of certain clients, i.e. they never get served. One solution to this problem would be to use a call such as fcntl(sockfd, F_SETFL, O_NONBLOCK)to set the socket to a non-blocking one, and then poll for information. Generally speak- ing, putting your program on busy-wait loop looking for data on a socket consumes enormous amounts of CPU time and is a bad idea.
select(), on the other hand, gives you the power to monitor several sockets at the same time, blocking until there is data to be dealt with. It will tell you which ones are ready for reading, writing, and which
8
have raised exceptions (if you really want to know).
Your server must deal with multiple connections. A single threaded server is entirely adequate if you choose to use the select() call to implement multiple connections on your server. Alternatively, it is per- fectly fine if you prefer to use multiple threads (using pthreads) or multiple processes (using fork) to implement your own connection management.
