代写program留学生程序、JAVA，c++，Python编程代做

日期：2021-04-02 11:39

Abdelkader Ouda page 1 Winter 2021

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: 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.

1. Objectives

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

Abdelkader Ouda page 2 Winter 2021

will be ready waiting for other peers to join into. This is the first case that is defined in task 1 in

assignment 2.

2. 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.

3. Pc should not send connection request to any peer who have declined it during earlier join attempt.

4. This process continues until all join attempts have been made to all peers in (Ps1 , Ps2 , …, Psn ).

5. 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.

Abdelkader Ouda page 3 Winter 2021

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=7 Message Type IC Search ID Sender ID length

Sender ID

Originating peer’s IPv4 address

Originating peer’s image socket port number

IT File name size

Image file name

Figure 1: The cPTP search request packet format

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.

These three fields

(the payload) could

be repeated by the

value of the IC

Abdelkader Ouda page 4 Winter 2021

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 collected images to the client requesting them and closes the connection to

the client. If the originating peer receives multiple copies of one image, it only collects one copy of the image.

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=7 F Response Type IC Sequence number

Timestamp

IT File name size Image size in byte

Image file name

Image data

Figure 2: The ITP response packet format (the header and payload)

Here are the descriptions of the ITP response packet fields:

? (V) is a 3-bit ITP version field. You must set this to 7.

? (F) is a 1-bit field, if set to 1, indicates that the client request is fully fulfilled, i.e., all images are

loaded. If the client request is partially fulfilled, i.e., subset of the images is loaded, the value of F is

0.

? The response type is one byte so that the value 0 means “Query”, 1 means “Found”, 2 means “Not

found”, and 3 means “Busy”.

? (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 0 and 31.

? Set the sequence number. The sequence number of the first packet is chosen randomly; it is

incremented by 1 for each subsequent packet sent out of the server. This field is 15 bits in length and

the increment will be performed mod 215

.

? The timestamp is a 4-byte field has the current value of the server’s timer.

? (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 (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, without the file extension.

These three fields

(the payload) exist

only if the IC is not

zero, and could be

repeated by the

value of the IC

Abdelkader Ouda page 5 Winter 2021

? The image size (part of the payload) is a 16-bit field which we will need to extract the image data

from the packet and display it. The actual image content (part of the payload) will then follow the

image size field.

To keep things simpler for you, you always search for images that exist in the p2p network.

6. 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. Create four different folders in your computer and name them: peer1-2,

peer2-1, peer3-5, peer4-3, peer5-3, and peer6-3. Note that, the first part (before the dash sign) of the folder

name represent the peer ID, and the part, the number after the dash sign, indicates the peer table size. After

creating these folders, copy and paste your program in all these six folders. Open seven command line

windows, and perform the command as shown in the figure below.

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.