P2P Protocol: Discovering Peers and Sharing Files, Study notes of Computer Science

A p2p protocol using java multicast dns (jmdns) for service discovery. It covers the basics of the protocol, including requesting user information and browsing and getting files. The document also discusses chat functionality and handling user invitations and departures.

Typology: Study notes

Pre 2010

Uploaded on 08/05/2009

koofers-user-uq6
koofers-user-uq6 🇺🇸

5

(1)

9 documents

1 / 4

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
P2P Protocol Definition
DISCOVERY
Use JmDNS for discovery. The service type you should use is
"_cs6452._tcp.local."
There is still a bit of flakiness in JmDNS. In particular, sometimes requests to
resolve a service aren't handled. It's fairly easy to work around this. In my version
of the code, did the following:
- When you first detect a service (through serviceAdded), fire off requestServiceInfo
to try to resolve the service. Also, add an entry to a dictionary where the name of
the service is the key, and the value is a new Date object that provides a timestamp
on when the request was sent:
self.jmdns.requestServiceInfo(event.type, event.name, 5000)
self.pendingRequests[event.name] = util.Date()
- In our serviceResolved method, remove entries from this dictionary once they are
resolved:
del self.pendingRequests[event.name]
- Create a new thread that will wake up periodically and check for services that are
still in this list, and have a timestamp that is older than, say, 10 seconds ago.
Reissue requests for these to be resolved.
self.jmdnsMender = threading.Thread(target=self.mendJmdns)
self.jmdnsMender.start()
def mendJmdns(self):
while 1:
time.sleep(10) # wake up every 10 seconds
for key, value in self.pendingRequests.items()
now = util.Date()
if now.time - value.time > 10000: # milliseconds
self.jmdns.requestServiceInfo("_cs6452._tcp.local.", key, 5000)
------------------------------------------------------------------------------------------------------------
PROTOCOL BASICS
Each request should open a new connection to the peer, send a correctly formatted
pf3
pf4

Partial preview of the text

Download P2P Protocol: Discovering Peers and Sharing Files and more Study notes Computer Science in PDF only on Docsity!

P2P Protocol Definition

DISCOVERY

Use JmDNS for discovery. The service type you should use is "_cs6452._tcp.local." There is still a bit of flakiness in JmDNS. In particular, sometimes requests to resolve a service aren't handled. It's fairly easy to work around this. In my version of the code, did the following:

  • When you first detect a service (through serviceAdded), fire off requestServiceInfo to try to resolve the service. Also, add an entry to a dictionary where the name of the service is the key, and the value is a new Date object that provides a timestamp on when the request was sent: self.jmdns.requestServiceInfo(event.type, event.name, 5000) self.pendingRequests[event.name] = util.Date()
  • In our serviceResolved method, remove entries from this dictionary once they are resolved: del self.pendingRequests[event.name]
  • Create a new thread that will wake up periodically and check for services that are still in this list, and have a timestamp that is older than, say, 10 seconds ago. Reissue requests for these to be resolved. self.jmdnsMender = threading.Thread(target=self.mendJmdns) self.jmdnsMender.start() def mendJmdns(self): while 1: time.sleep(10) # wake up every 10 seconds for key, value in self.pendingRequests.items() now = util.Date() if now.time - value.time > 10000: # milliseconds self.jmdns.requestServiceInfo("_cs6452._tcp.local.", key, 5000)

PROTOCOL BASICS Each request should open a new connection to the peer, send a correctly formatted

request, wait the response, and then close the connection. (NOTE that this is different from the IM program, where every client maintains a persistent connection to the server.)


FINDING OUT ABOUT USERS Once you've discovered a peer through JmDNS (and thus have its mDNS name), and have the service info for it (the IP address and port on which the peer is listening), you can begin to issue requests to it for additional information, to start chats, etc. To find out about the user running the peer, issue a GET_ USER_INFO request: GET_USER_INFO The recipient should respond with a pickled dictionary containing key/value pairs that provide additional user information. At a minimum, your dictionary should contain the following data: Key Value


"Long Name" "URL" <string containing a URL to the user's home page> You can include extra stuff if you want, but receiving peers aren't necessarily expected to do anything with the data.


BROWSING AND GETTING FILES List the shared files on a remote peer by issuing LIST_FILES: LIST_FILES Peers should return a pickled Jython list containing the names of the files: Note that these don't have to be "real" full-path filenames. The easiest thing to do is return the short names of files that exist in a specified directory. Once you know that a given filename is available on a peer, you can request it via GET_FILE: GET_FILE

the chat members (as the third argument). This message indicates to all peers who is currently in the chat, so that they can update their display. Any peer can generate messages to any other peer in the chat. To send a message to other chat members, use MESSAGE: MESSAGE (id, sender, text) The argument is a pickled Jython tuple containing the chat ID, the sender of the message, and the text of the message. You should send this to every other member of the chat. Any member can leave a chat by sending the GOODBYE message to the original initiator of the chat: GOODBYE (id, sender) The arguments are a pickled Jython tuple containing the chat ID and the mDNS name of the party leaving. The original initiator, upon learning of the departure of a member, should notify the remaining peers through a CHAT_STATUS message. Only the initiator can "close" a chat completely. This is done by sending a CLOSE_CHAT message to any remaining peers in the chat. This can be triggered by the initiating user closing his or her chat window, for example: CLOSE_CHAT (id, sender)