CPE 401/601 Computer Communication Networks

Spring 2012

Peer-to-Peer Online Social Network

Project due on Wednesday, May 9 at 1:00 pm

In this project, we will develop a simplified version of peer-to-peer online social network. The goal of the project is to develop a PeerSoN-like Online Social Networking system.


Requirements

To keep the user interface simple, you should build two simple programs one for server that keeps login information and one for the peers.

The server program is responsible for (1) building and maintaining a list of active peers in the network, (2) building a database of each peer's public sharing, and (3) respond to search queries from peers.

The peer code should be started with the number for the peer's own control port, the name and port number of a central server. The peer will accept friend and update requests from other peers through the control port and respond to them.

We will only exchange ASCII text/files in the system.

All server communication should use UDP as transport layer protocol whereas transfer between the peers should use TCP.

You should only use C++ or Java for socket programming. Other parts of the system might use another language, such as Python or Ruby for text processing.


Message Formats

Following are the application level messages sent from/to the server using UDP sockets:

Note that, there is no space after each message.

Following are the application level messages sent between peer using TCP sockets:

Note that, each request is handled by a separate active socket. This socket should be terminated when the update is completed.


System Operation

Server Start-up:

The server will establish tables that will manage users. In particular for each client it will record online status (IP address and port number), the profile version, latest heartbeat time, and public profile.

Client Start-up:

The client will REGISTER with the server indicating its IP address and port number and retry 3 times if REGISTERED response is not received in a minute. If this is the first time a client is connecting to the server it also LOADs its public profile.

Moreover, the client will send KEEPALIVE message to the server every 3 minutes.

Public Profile Update:

From time to time, a client may update their public profile using LOAD command.

Friend Query:

From time to time, a client will ask the location of one of its friends (lets say Alice) from the server using QUERY and if the friend (i.e., Alice) is online use UPDATE to directly ask for profile updates. However, if Alice is not online the client will determine common friends and (starting with the clients that it already knows as online) ask common friends for any update about Alice using REQUEST message.

Moreover, if the updated profile includes any new file, the client will use GET to obtain the file from Alice.

Public Search:

From time to time, a client will look for someone using FIND. If a non-empty RESULTS is received, the client will randomly pick a user-ID to ask for friendship using FRIEND. Then, if the friendship is confirmed, it will ask for profile using UPDATE.

User Exit:

When a user exits, it will first look up the location of friends using QUERY and then notify all online friends that it is leaving with EXITING message. The friends will then initiate REQUEST if their version is old. After a minute of receiving no query, the client may terminate.


Sample XML files

publicProfile.xml content.xml

Assumptions/Notes

Report all major actions as the program communicates with other server/peers in a file named activity.log.

We assume file sizes to be at most 16K characters.

We assume file names to be at most 64 characters without any white space characters.

When a malformed message is received report it in a log file named error.log.

If you are developing advanced features develop two versions of code. One with the required functionality and nothing more and another one with advanced features that you added.


Deliverables

You must submit all the source code with sufficient comments to help understand the code.

You must include in your submission a file named README that includes your name and a brief description of your submission, including the name of each file submitted along with a one line description of what is in the file.

If your code is not complete, tell us what works and what doesn't. If you are submitting code that does not compile, please tell us that as well. If you borrow code from someone else, you are required to tell us about it (this must also be documented in the code itself).

Finally, feel free to include a description of any problems you had or anything else you think might be helpful to us.


Grading

Your project will be tested to make sure it works properly. We will test your clients and servers against each other. That is, your server should be able to exchange files with clients developed by someone else.

Your grade will depend on the functionality and the code quality. Hence, please pay careful attention to clean, modular and extensible design as you implement the project.

There will be bonus grades for extra functionality not required by the project (optional and at the discretion of the instructor).


Bonus

This section is due May 16th at 11am.

You may get up to 10 points bonus for providing a detailed survey (at least 2000 word paper excluding references) on peer-to-peer social networking.

The report should provide a detailed analysis of current peer-to-peer social networking systems and discuss their weaknesses and how to improve them. The coverage of this report should demonstrate your competence with the topic. Your writing should be clear, engaging, technically sound, and written in an appropriate style for an academic publication.

Your report should address:

Your review of at least 5 (which includes all relevant ones) papers may address:


Submitting your files

Submission of your project is via WebCampus. You must submit all the required files in a single tar or zip file containing all the files for your submission.

Last updated on May 1, 2012