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.