P2P Programming Assignment

Transcription

1 P2P Programming Assignment Overview This project is to implement a Peer-to-Peer (P2P) networking project similar to a simplified Napster. You will provide a centralized server to handle cataloging the files available on the network, and you will write a client program that interfaces both with the central server and with other clients to achieve P2P file transfers. The project is divided into two phases the first phase is due April 27th, and the second phase will be due May 7th. The package should include three parts and you must name each of the part as the example blow shows. Please pack your project named as 学号 _ 姓名.rar and submit to cn_tju@163.com before the deadline. If you submit your homework after the deadline, your score will be 50% off. Example: Phase 1: Establishing Client-Server Communications--Mandatory In this phase of the project, you will learn how to write programs that communicate through TCP sockets in C/C++ under Unix/Linux or Windows OS. For now you will ignore the portion of the P2P architecture that consists of communications between peers on the network your task is to establish communications between your client and the centralized server. In this project, you will be programming using sockets to build a P2P client. In centralized P2P networking architectures, a single server exists to maintain a database (it's not a real database, in fact, you just need store the data in memory) of all files that exist on the network. Whenever a user wishes to search for a file on the network, they simply submit a query to the centralized server. The server runs the query on its central database, and returns a list of locations (specified by IP address and port number) where the file can be found. The user can then select which of these locations they wish to download the file from, and a direct connection is opened with the peer that has the file. Your P2P client will need to interface with the P2P server which you are being provided with to carry out the following tasks: 1) Authenticate with the server (provide a username and encrypted password) 2) Send a list of files to the server that you wish to share with other users 3) Submit a search query to the server for a file you wish to download 4) Receive the search results, parse them, and output them to the user

2 5) Log out The protocol you will use for client-server communications is defined as follows. Each packet contains ASCII characters only, as with HTTP, so the messages being passed will be in human-readable format. The first four bytes of every packet contain a header value which determines the type of the packet. The data field varies for each type of packet (specifics listed below), but in general fields are split using the character # as a delimiter, and all packets are terminated with a \n character. Specific packet structures are as follows: LGIN is the 4-byte header value corresponding to a login/authentication packet. You can set the username/password combination to use for the project. Note you may not send passwords as plain text over the internet. You will be using a simple encryption algorithm in which you randomly choose an encryption key (a single digit number from 0-9), and subtract this number from the ASCII value of each character in the password. For example, if the password is pass and the encryption constant randomly chosen is 2, the encrypted password would be n_qq (consult an ASCII table to verify this). In order for the server to know how to decrypt the password, it must be given the encryption constant. Therefore, you would transmit 2n_qq as the encrypted password (note the encryption constant is transmitted as an ASCII character 2, not a 4-byte integer). If your encryption constant is randomly chosen to be 0, you would transmit 0pass. For 1, transmit 1o`rr, etc. Your client should choose the encryption constant randomly (from 0-9) each time it connects to the server. When the server receives a LGIN packet from a client, it will return one of two responses. If the username/password is invalid, or if the LGIN packet does not conform to the protocol format, an EROR (error) packet will be returned: Whenever the server receives a malformed packet of any kind, it will return an EROR packet as shown above. If your client receives an EROR packet from the server at any time, it should print out the error message, close the socket, and exit gracefully. If the login packet is received correctly, the server will instead generate a LRES (login response) packet containing a welcome message: Once the client has successfully logged in, it should be able to specify a list of files to the server that it wishes to share (the server will add these files to its database of available files on the network). Files are shared using a SHRE packet sent to the server: This packet can be of variable length it is terminated by a \n character. The first field, port specifies the port number on which your client will listen for incoming connections in case anyone wants to download these files from you. The port number should be transmitted as an ASCII representation of the number, not an integer representation. The remaining fields in the packet are the filenames that you wish to share. You can assume that no filename has a # character in it. Also, note that the server will only accept filenames of the format *.txt. You can also assume all files are located in the working directory (no path specification required). If the format of any of the filenames is incorrect, has the wrong file extension, or if the packet does not follow the correct format, the server will return an EROR packet as before. Otherwise, the server returns a SHOK packet: Once you re logged in, the server is stateless for each connection this means you can send multiple SHRE packets (and multiple SRCH packets, described below) in any order, and the server will respond correctly. Now that you have shared some files, you may search the P2P network for files that you wish to

3 download. To do this, your client should allow you to send SRCH packets to the server containing search strings: Search results are returned one at a time in SRES packets as follows: As usual, the IP and port fields are returned as ASCII string representations of the IP address and port number, respectively. When the last search result has been returned, the server will return an empty SRES packet: Tip: during testing if you would like to figure out what all the files available on the network are, you can search for txt to return a listing of all files (since all files must be of the format *.txt). Finally, when the user wishes to close the connection with the P2P server, a QUIT message is sent: Upon receiving the QUIT message, the server removes all shared files for that user from its DB. Phase1 Testing: The flow of your program for phase 1 is as outlined on page 1 of this spec (5 numbered steps). The program should ask the user for a username and password. The password should be encrypted, and a LGIN packet should be sent to the server. The client should then listen for a response from the server. If an LRES packet is received, the user should be prompted for a list of filenames to be shared. Only *.txt file names should be accepted. These files should be shared by sending the names to the server in a SHRE packet (or multiple SHRE packets), along with a port number that your client will listen on for incoming connections to download these files (this part will actually be implemented in phase 2). The client should then prompt the user for a search string, and send a SRCH packet to the server with the terms entered by the user. SRES packets should be parsed and outputted to the screen until no more arrive. The user should be given a choice of searching again or quitting if the user quits, a QUIT message should log the client out from the P2P network. Phase 2: Establishing Peer-Peer Communications In this phase you will extend your work from Phase 1 to create a fully functional P2P client. Now that you have a client which can connect to the central P2P directory server, share files, and search the network for other shared files, the last step is to add functionality to actually transfer files with other peers on the network. The primary function of a classic P2P network is to share and transfer files between clients (or peers) on the network. This is accomplished in much the same way as the communications with the server; one peer opens a connection with another one by creating a socket, calling connect(), and following a defined protocol to request and receive the wanted file. There are four main components to phase 2: 1) Add functionality to send ping messages over UDP and listen for echo responses, in order to estimate the round trip time to another peer.-- Mandatory 2) Add functionality to respond to ping messages from other peers.-- Mandatory 3) Add functionality to connect to another peer and download a file.--optional 4) Add functionality to make your peer a file server, so that other peers may connect and--optional download files from you. Furthermore, you will need to code your peer to allow concurrent execution of its various tasks. In other words, your user should be able to share, search, and download files at the same time that other users are downloading from you, or sending ping messages to you. More details on accomplishing this are included below.

4 The four components are described below in more detail. It is recommended for ease of testing that you implement the components in the order presented here, but you are free to do as you please. Next to each component title is an estimate of approximately how long you should budget to work on each component. You have a little over five weeks to work on this phase of the project, and if you leave it until the last week you will have trouble finishing. 1) Sending UDP PING Messages-- Mandatory In this component of phase 2, you will gain some experience with socket programming for UDP sockets. When your user submits a SRCH query and receives SRES messages in response, you will add functionality which will send a PING message to each of the peers listed in the responses. The reason for doing so is to ensure that the peer is in fact online. PING messages are fairly straightforward: Upon receiving a PING message, the server will echo back a PRES message to the same port from which you sent your PING message (this port will be assigned by the OS when you called sendto(), and it is also bound implicitly by the sendto() call so that you can receive from it using recvfrom()): Be aware, UDP does not guarantee delivery of packets. While you will most likely never drop a packet while just transmitting between two machines, you must code for this possibility (we will test for it). This is important because if your peer calls recvfrom() and waits for a packet which has been dropped, your program will hang indefinitely. There is a function called select() which will allow you to establish timeouts for your recvfrom() calls. 2) Responding to UDP PING Messages-- Mandatory As a complement to the functionality above, your peer will also need to be able to respond to incoming PING messages. This will require more concurrent programming, since you need to be able to do this in the background while simultaneously supporting all of the other functionalities described above. Your UDP ping server component will also need to have a specifically assigned port to listen on. 3) Downloading Files--Optional In phase 1, you wrote a program that allowed your user to connect to a P2P directory server, share some files, and search the shared file listings for available files. In this component of phase 2, you will give users the option to download files that are returned as search results. As usual, you will need to follow a specific protocol in order to accomplish successful transfers with other peers. You will use the information returned in the SRES message (IP, port) to open a connection with the peer who has the file. Then, you will need to identify yourself to the peer, in order to allow the other peer to decide whether or not to allow a transfer. You will do this with a simplified version of the LGIN message from phase 1: Note, you don t need to send a password to the other peers, just your username. The peer you ve connected to will respond with one of two messages. If your LGIN message was of the incorrect format you will receive an EROR message: Otherwise, if the peer decides to allow your connection, you will receive an LRES message: Assuming you receive an LRES message, you may proceed with the file request message: You will either receive an EROR message (if the file is not actually being shared, if the filename is incorrect, or if the GETF message was formed incorrectly), or you will receive a FILE message

5 containing the file itself: This message deserves some explanation. First, the four byte message type is simply FILE this is nothing new. After FILE, the message contains a 7-byte preamble, followed by the file contents, followed by the same exact preamble (repeated), followed by the newline character. The preamble is used as a means of delimiting the end of the file itself; since files can contain newline characters themselves, it s not possible to use \n as the delimiter for the end of the FILE message. Therefore, when transferring a file, each peer will randomly generate a preamble code which is seven characters in length, containing all 0 and 1 characters. This same preamble will be affixed to the beginning and the end of the file when transmitted as a FILE message. Therefore, when receiving a FILE message, you will need to read in the 7-byte preamble, store it, and scan for that pattern while reading in the file contents. When you find the preamble repeated, this will indicate that the entire file has been transmitted and that the following \n delimits the end of the FILE message. For this project, you can assume that we will only be transferring plain ASCII text files (with *.txt extensions, as in phase 1). When receiving a file, you should create a file with the specified name (the file name was contained in the SRES message, so you already know it) in your current working directory. If a file of the same name already exists in that directory, you may either prompt your user for the desired action or simply overwrite the old file (either choice is acceptable). The file contents transmitted to you should be written out to the newly created file, so that when the transmission is complete you have an exact replica of the file in your local directory. The file should NOT contain the preamble bytes, or the trailing \n character that delimited the end of the FILE message. Note that files may be of any size, and even though they will be carried in a single FILE message, this does not guarantee that you will be able to receive the entire FILE message in a single recv() call. As with receiving partial messages in phase 1, you ll need to continue calling recv()until you get the entire message. After you ve successfully received the file, your client should close the connection with the other peer. If you want to download multiple files from the same peer, you ll need to open a connection for each file request. 4) Adding File Server Functionality--Optional Your peer will also need to be able to transfer files to other peers who request them. The protocol for accomplishing this is exactly as outlined in the previous section, and will not be repeated here (you will need to generate all the server messages exactly as listed in section 1 above). Your server must handle all error conditions properly; if a peer sends you a malformed message, you should be able to recognize this and generate an appropriate EROR message. Make sure you test your server s ability to handle all types of errors, including when a connected peer crashes the connection (without a graceful socket close). A second pitfall to be careful of is the partial send. In phase 1, this wasn t much of a consideration (although you were instructed to code for it) because your messages were always relatively small. However, when sending a file your message may be arbitrarily long (100KB, 1MB, even 100MB files should all theoretically work). As a result, you will need to be careful to check that your server actually sends the entire message; this will most likely require multiple calls to send(). There is also another major consideration for this component. The user of your peer software should be able to share, search, and download files without interruption but at the same time

6 they should be able to concurrently support file download requests from other peers. Furthermore, your peer should be able to simultaneously handle incoming file requests from multiple peers. As a result, this will require learning a little about concurrent programming techniques. You probably have never written a program that requires concurrent execution. The basic idea is that since your program needs to do multiple things at the same time, it will need to spawn separate threads of execution (or child processes) in order to handle the various tasks simultaneously. There are two ways you can accomplish this using fork() to create child processes or by using the pthread library to create multiple threads within your main process. For details on how to use fork(). The basic structure of a concurrent server is as follows (incidentally, this is also the basic structure of the P2P server you ve been connecting to). The main execution thread creates a socket, binds to a port on which it will listen for incoming connections, and enters a loop. Inside the loop the server calls accept(), which blocks and waits for incoming connection requests. Upon receiving an incoming connection request, accept() will return a new socket descriptor which will be used for the new connection. The server then immediately spawns a separate process using fork() (or a separate thread using pthreads), and the new process/thread handles the new connection. Meanwhile, the main execution thread immediately returns to the top of the loop, calling accept() to allow another incoming connection. Inside the child process, communications with the connecting peer take place as described with the protocol above, and the file can be transferred. Once the file transfer is complete, the child process terminates. Your peer software will have several concurrent execution threads. Upon starting the program, the main thread will first connect and LGIN to the P2P server as in phase 1. Once connected, your peer should immediately spawn a separate process/thread to listen for incoming connections. Whenever another peer tries to connect to you, your server thread will need to spawn another process/thread to handle that incoming connection. Therefore, for this component alone you may have a large number of concurrent processes/threads at any time depending on how many users are connected to you simultaneously. One thing that you ll need to figure out is how to deliver information to the various child processes so that they know which files are actually being shared. In your main execution thread, your user will send SHRE messages to the server as in phase 1, to indicate the availability of files to other peers. Your file server component will also need to have this information, so that incoming GETF requests can be handled appropriately (if a user requests a file that you haven t explicitly shared, or a file that doesn t exist, you should return an EROR of some type). You will have a specific port number assigned to you for the file server component of your peer for this project. In phase 1, you were allowed to choose any arbitrary port number to put in the first field of your SHRE messages being sent to the server. In phase 2, the port number you place in the SHRE message will need to be the port number that your file server is actually listening on. Other peers will receive this port number in SRES messages, and will attempt to open up connections with you on that port. Phase2 Testing: The expected flow of your peer software is as follows. Upon running the peer, it should first attempt to connect and LGIN to the P2P server as in phase 1. Once connected, you should immediately spawn processes/threads to handle incoming PING requests and incoming file transfer connections. Your file server component should be capable of handling multiple

7 (theoretically unlimited) simultaneous connections therefore it will need to spawn a new child process/thread to handle each incoming connection. In your main thread, you will present a menu to the user and allow them to choose between sharing files, searching for files, or quitting. If they choose to share, the file server processes must have access to this information as well so that they know which files are available for incoming GETF requests and which are not to be transferred. If the user submits a search, SRES messages should be parsed and PING messages should be sent to each host (if a single host yields multiple search results, you may choose whether to PING that host once per file or once only). Estimates of the RTT to each host should be displayed with each search result. The user should then be given the option to download any of the files returned as search results. Your downloads do not have to run in the background if you don t want to implement this if a user chooses to download a file, you may wait until the file is received before returning control to them. NOTE: Your application should completely hide the underlying application layer protocol from the user. Messages should not be printed out in raw format they should always be parsed and interpreted, so that user-friendly messages can be generated. Furthermore, user input should never be required to be in the format of the protocol (in other words, a user should never have to input a message type such as SRCH or a # sign; your application needs to insert this data into the messages without the user s knowledge). As with phase 1, your project must be implemented in C/C++ under UNIX/Linux or Windows OS. Grading: Grades will be assigned based on the following criteria: Program Correctness and Functionality: 60% Code design & Program Structure: 10% Documentation: 30% Turn in: You must submit your report in Word document for the mandatory part, we will provide the Word template to you. In particular, you should describe the socket code in detail so that it is clear you understand what each line is for, and you also should describe how you decided to implement concurrency (processes, threads, how did you share information between them). You must also submit your electronically report and commented code to my before the deadline.