辅导program留学生程序、JAVA，c++，Python编程讲解 讲解SPSS|解析Java程序
- 首页 >> Python编程 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.
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.