SE 3314B – COMPUTER NETWORKS APPLICATIONS
Assignment 3: Peer-to-Peer Search
Due Date: April 7, 2021
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.
In this assignment you are to build a peer-to-peer (p2p) network and perform a search for one or more images on the p2p network. In particular, you will implement a peer node similar to the one you implemented for assignment 2. This peer node will also support client image query to search for images.
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, no problem you still have the chance to practice socket-programming in this assignment. Read the requirements and the specifications of task1 and task2 given in assignment 2, build the required Peer Node program, and then move to task 2 in this assignment.
3. Task 2: Advanced Automatic Re-Direct
In this assignment we will enhance the automatic re-directed process so that, when a peer program Pc tried to connect to peer Ps and Ps peer table is full, the following cases need to be considered. Ps will decline the connection and send to Pc a message packet with ‘Message Type’ equal to 2, (2 means Re-Direct), along with Ps connected peers (Ps1 , Ps2 , …, Psn ). Pc will print out “The join has been declined; the auto-join process is performing …” and performs the following for each peer P in (Ps1 , Ps2 , …, Psn );
1. Pc sends connection request to P, if P peer table is not full, it should accept the connection and send to Pc a message packet with ‘Message Type’ equal to 1, (1 means Welcome). The peer program Pc will be ready waiting for other peers to join into. This is the first case that is defined in task 1 in
- if P peer table is full, P will decline the connection and Pc will receive message packet with ‘Message
Type’ equal to 2 along with the connected peers of P. In this case we will, recursively, repeat the process and should go down the list of returned P peers one at a time and performs the same process in step 1.
- Pc should not send connection request to any peer who have declined it during earlier join attempt.
- This process continues until all join attempts have been made to all peers in (Ps1 , Ps2 , …, Psn ).
- If all attempts are declined, the peer program Pc terminates.
Hint: to achieve step 3, you need to keep a separate “peering declined” table. Prior to attempting to join a peer P, check against this table to make sure this peer P is not existing. Also, if the join attempt is declined by a peer P, add the peer P in the “peering declined” table.
4. Task 3: Client Image Query
Your next task is to integrate the server functionality described in assignment 1 (that accept image query request and then respond by sending the requested images) with the Peer Node code from assignment 2 in a new program (server) which we will call it peer2peerDB. This new 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, which will accept peer join requests. The second comes with the instantiation of the image object, which will accept image query requests. 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 images, the server first searches its own database (or rather, its working directory/folder) for the requested file names. If the images are found, it is returned to the client using the ITP response packet format (see Figure 2) and the connection is then closed. If all or subset of the requested images are not found, the server will search for these images in the peer-to-peer network on behalf of the client. We will discuss how to handle peer-to-peer search in the next task.
5. Task 4: P2P Search
When a peer cannot find at least one of the requested images locally, it sends out a search packet through the peer-to-peer network using the peer socket. 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 the collected images (if many were requested) 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, along with the name of the image(s) being searched for.
The query/search packet MUST follow the format shown in Figure 1.
Here are the descriptions of the cPTP search request packet fields:
- (V) is a 3-bit cPTP version field. You must set this to 7.
- The message type is one byte to represent the message type; the value 3 means ‘Search’ type.
- (IC) Image Count is a 5-bit field indicates the number of images in the packet. Note that we can have
a maximum of 31 image because a 5-bit field only allows a number between 1 and 31.
- 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.
- (IT) Image Type is a 4-bit field, part of the payload, indicates the type of the images as follows: 1 –
BMP, 2 – JPEG, 3 – GIF, 4 – PNG, 5 – TIFF, and 15 – RAW.
- The file name size (part of the payload) is a 12-bit field hold the number of bytes needed to store the
image file name.
- The image file name, without the file extension, (part of the payload) is a field to store the name of
the requested image. The size of this field is equal to the length of the image file name.
Search packets are sent along the connections made between peers, i.e., the “links” forming the p2p network. 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 n number of the most recent searches (in a circular way) where n = the peer table size. 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 two cases mentioned here:
(1) previously seen search, and
(2) 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.
本网站支持淘宝 支付宝 微信支付 paypal等等交易。如果不放心可以用淘宝交易！
E-mail: firstname.lastname@example.org 微信:itcsdx