Abdelkader Ouda page 1 Winter 2020 WESTERN UNIVERSITY – CANADA FACULTY OF ENGINEERING DEPARTMENT OF ELECTRICAL AND COMPUTER ENGINEERING SE 3314B – COMPUTER NETWORKS APPLICATIONS Assignment 3: Peer-to-Peer Search Due Date: March 31, 2020 This assignment is to be done individually. Cheating is prohibited in this assignment, that is not to show your code to any other student, do not look at any other student’s code, and do not put your code in any public domain. However, getting help is easy and available, just ask the instructor or the TAs. At the same time, you are encouraged to discuss your problems (if any) with other students in general terms but the actual program design and code must be your own. Please note that the consequences of cheating are much, much worse than getting a low mark for that particular item of work. The very best case is that you get a zero for the whole thing. Keep in mind that turning in your own work would have at least gotten you a few marks, better than a zero. 1. Objectives In this assignment you are to build a peer-to-peer (p2p) network and perform a search for an image on the p2p network. In particular, you will implement a peer node similar to the one you implemented for assignment 2 (you may re- maximum number and automate peer join and redirection. This peer node will also support client image query to search for an image. 2. Task 1: A Peer Node Your first task is to write a peer node. If you’ve implemented assignment 2 and have decided to build this assignment on top of your working assignment 2, you’re done with the first task of this assignment. If you have not implemented assignment 2, review the supported code and specification of assignment 2. They go into much more details and also guide you step by step on what needs to be done. By this review, I will assume that you are familiar with the assignment 2 specification and the supported code. In this assignment, we assume that once a peer joins the network, it never leaves the network. So you don’t have to worry about cleaning up after departed peer. You must, however, ensure that none of the peers crash when one of them leave, so you can take down the network one peer at a time without the others crashing. 3. Task 2: More Peers In assignment 2, we limit the peer table size of each peer to 2. The command line option “-n ” allows the user to specify the peer table size at run time. A study of the Gnutella p2p network found that half of Gnutella peers supports at most 2 peers. Even though there are peers that support over Abdelkader Ouda page 2 Winter 2020 130 other peers, the mean number of peers supported is 5.5. If the -n option is not specified in the command line, use a default value of which has been bumped up to 6 for this assignment. If the -n option is assignment 2 that the acknowledgement message sent back to a joining peer contains at most 1 alternate peer. Your next task is to support more than 1 returned peer with each join acknowledgement message. The acknowledgement message MUST be of the following cPTP packet format. 0 0 1 2 3 4 5 6 7 8 9 1 0 1 2 3 4 5 6 7 8 9 2 0 1 2 3 4 5 6 7 8 9 3 0 1 V = 3314 Message Type Sender Number of peers Reserved Peer port number Peer IPv4 address Figure 1: The cPTP message packet format It stores the cPTP message type is one byte, it Welcome Re- . The sender ID is 4 bytes, the holds the number of peers the number of peers joined to this current peer. For each peer joined we store the following; 2 reserved bytes, 2 bytes for the joined peer port number and 4 bytes for 4. Task 3: Automatic Join In assignment 2, when a peer receives a Re-direct message, it simply prints out a join failure/redirection message to the console. It is then up to the user to re-run the peer to join another peer. Your third task is to automate this process. When a peer receives a Re-direct message, instead of simply printing out a redirection message, your code should go down the list of returned peers and try to join each one of them until you have filled up your peer table. Actually, you need to do this even if you receive a Welcome message if your peer table is not yet full. If your peer table is full but the list of peers returned to you by the peer you try to join is not yet exhausted, even if some peers in your table are still in “pending” state and may end up rejecting you, you can just throw away the remainder of the list. If your peer table is still not full after you’ve exhausted the list of peers, try to join with peers subsequently referred to you by the peers you contacted. You need to keep track of four cases: (1) don’t attempt to join peers already in your peer table, (2) don’t attempt another join with peers you already have a pending join, (3) don’t attempt to join the last maxpeers peers who have declined your earlier join attempt, (4) if you try to join a peer at the same time it tries to join you, only one will successfully form a link. The first case is easy to check for: just make sure the peer you want to join is not already in your peer table. For the second case, if you enter into your peer table all your pending joins, this case reduces to the first case. You may want to add a “pending” field to your peer table entry so that you don’t forward a search packet (see next task) to pending peers. For the third case, you need to keep a separate “peering declined” These 64 bits exist only if the number of peers is not zero, and could be repeated by the value of the number of peers Abdelkader Ouda page 3 Winter 2020 table. Prior to attempting a join, check against this table just like you would against the peer table. If your join attempt is declined, close the connection and move the peer from your peer table to your “peering declined” table. Otherwise, clear the peering table entry’s pending field. The peering declined table should be used to keep only the most recent maxpeers declined, i.e., once the table is full, you wrap around and overwrite the first entry. If your peer table is full, even if some of the entries are still “pending,” don’t initiate another join. (This also serves as a control to make sure that you don’t flood the network with join requests!) As for the fourth case, only one of the two connect attempts will succeed. The other will return with an error. In which case, simply clear the peer table entry of the failed connection. If you’ve exhausted the returned peer lists and you have attempted a join with all the peers you’ve heard about and your peer table is still not full, just chill out, do nothing, and wait for new peers need to connect. 5. Task 4: Client Image Query Your next task is to integrate the image query from assignment 1 with the peer code from assignment 2. If you’ve implemented assignment 1, you can re-use your code. If you have not implemented assignment 1, you want to review the supported code and specification to complete this task. The client, getIamge from assignment 1 should work without any modification. Next, incorporate the server code, imageDB, into the peer code, which we will then call peer2peerDB. The server will use two different ports: one to handle peer-to-peer network maintenance traffic and another to handle image query traffic. You get the first when you instantiate a peer object. The second comes with the instantiation of an imageDB object. We will call the former the peer socket and the latter the image socket henceforth. We will use one image socket for both client query and peer image-search reply (next task). When a client queries for an image, the server first searches its own database (or rather, its working directory/folder) for the requested file name. If the image is found, it is returned to the client using the ITP response packet format (see Figure 3) and the connection is then closed. If the image is not found, the server checks whether it is already searching for an image in the peer-to-peer network on behalf of another client. If so, it returns the ITP
response packet to the new client with the response type field set to . That is, a server performs only one peer-to-peer search at any one time. You have to decide how to determine that a server is already serving another client. We will discuss how to handle peer-to-peer search in the next task. At this point, you should test your code and verify that your getImage client and peer2peerDB server work as in assignment 1 to serve up image files that are local to the server. 4. Task 5: P2P Search When a peer cannot find an image locally, it sends out a search packet through the peer-to-peer network. When a queried image is found, the peer holding the image connects directly with the peer searching for the image (originating peer) and transfers the image to the originating peer, who then forwards it to the client. As explained in the previous section, this connection is made to the originating peer’s image socket. Thus, the search packet must carry the originating peer’s address and its image socket’s port number, Abdelkader Ouda page 4 Winter 2020 along with the name of the image being searched for. You may re-use code from assignment 2 for this task. The query/search packet MUST follow this format. 0 0 1 2 3 4 5 6 7 8 9 1 0 1 2 3 4 5 6 7 8 9 2 0 1 2 3 4 5 6 7 8 9 3 0 1 V = 3314 Message Type Sender Search ID Reserved Originating peer’s image socket port number Originating peer’s IPv4 address Image file name Figure 2: The cPTP search request packet format Where version as before type. The “search ID” field is a way for you to differentiate subsequent searches for the same image name from the same originating peer (see below). The port number in the search message is that of the image socket, NOT the peer socket. The peer initiating an image search sends a copy of this search packet to all the peers in its peer table. Search packets are sent along the connections made between peers, i.e., the “links” forming the p2p network. Peering relationships that are still “pending” (see the “Automatic Join” section above), should not be used to forward search packet. Once you have sent out a search packet to all your connected peers, you don’t need to send it again if new peers connect to you at a later time. When a search packet arrives at a peer, the peer must check whether it has seen the same query previously. You don’t have to keep a very long history. Just keep the last maxpeers number of the most recent searches (in a circular way) and check against them. If the peer has seen the search in the recent past, it simply drops the packet. Otherwise, it checks whether it has a copy of the queried image. If it does not have a copy of the image, the peer forwards the query further to all its peers, except the peer whence the query arrived. Your code must be able to make these determinations and not forward the search packet in the three cases mentioned here: (1) pending join, (2) previously seen search, and (3) the peer whence the search message arrived. Note: You will be deducted points if your queries loop on your p2p network because your node doesn’t drop duplicate queries. If a peer has no other peer to forward a search query, it simply drops the query. If a peer has a copy of the queried image, it creates a new socket and connects to the query originating peer at the address and port number listed in the search packet. Thus, the image is not transmitted on the “links” of the p2p network, but on a separate connection directly to the query originating peer, created just to transfer the image. Once the image transfer is completed, the connection is closed by the peer initiating the transfer. The originating peer then forwards the image to the client requesting it and closes the connection to the client. If the originating peer receives multiple copies of the requested image, it only returns one copy to the client. If it receives an image when it is not waiting for any search reply, it can simply close the connection with the Abdelkader Ouda page 5 Winter 2020 peer. At any one time, a peer can only perform a search on behalf of one client. Your code should enforce this. If a reply for an old search arrives after a new client initiated a new search, the peer will return the wrong image to the new client. Your code is not required to handle this error case. Image transfer between peers and between a peer and its client MUST follow the same protocol as in assignment 1, you MUST precede the image with the ITP response packet format as follows: 0 0 1 2 3 4 5 6 7 8 9 1 0 1 2 3 4 5 6 7 8 9 2 0 1 2 3 4 5 6 7 8 9 3 0 1 V = 3314 Response Type Sequence Number Timestamp Image size Image data (the payload) Figure 3: The ITP response packet format (the header and payload) To keep things simpler for you, you always search for an image that exists in the p2p network. For this assignment, we will use the same ITP message code, 5. Testing your code Below is a running scenario as an example to show the execution of the program and to summarize the requirements of this assignment. After finish building your codes, save it in four different working folders, p1, p2, p3, and p4. Open four command line windows, one for each of these created folders. At p1 folder, start your peer code with maxpeers set to 2. At p2 folder, start a second peer with maxpeers set to 3, connect it to p1 peer. At p3, start a third peer with maxpeers set to 2 and connect it to the p2 peer. If your automatic join code is working, p3 should then also join p1. Finally, at p4, start peer with maxpeers set to 1 and try to connect it to p3. P4 should fail to connect to p3 and p1 but successfully connect to p2. To test your search code, search for an image that is at least 2 hops away. Also search for an image that is held by more than one peer. You may want to test wrong version number handling for search and acknowledgement packets separately. Hand In Submit the final version of your source code (Fully commented and formatted) through OWL by the due date mentioned above. This should include one compressed achieve file (zip file) having all JS files for the peer program including the package.json file and name it yourUWOID-SE3314b-assignment3.zip.
