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.
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.
Following are the application level messages sent from/to the server using UDP sockets:
REGISTER user-ID peer-IP peer-port profile-version
This command registers a peer with user-ID with the server where
peer-port are the IP address and port
number through which it will handle requests (sent from peer to server).
REGISTERED user-ID peer-IP peer-port
This command acknowledges that the peer is successfully registered with
the server (sent from server to peer). If the client does not get a
REGISTERED reply to a REGISTER message after a minute than it should assume
the registration has failed and record the event in
without retrying to register.
KEEPALIVE user-ID profile-version
Used as a heartbeat every three minute, this command indicates that the peer is alive (sent from peer to server). If the heartbeat message is not received from a node for more than ten minutes it is removed from the system assuming it went off-line. Moreover, if this message is received after a user is marked as offline, it is updated with the last IP and port numbers.
This command asks for location (i.e, IP address and port number) of a user with user-ID.
LOCATION user-ID IP port profile-version
This command indicates the location of a user in response to a QUERY message (sent from server to peer).
LOAD user-ID XML
This command updates the public profile of a client with an XML file which includes three categories with the following fields.
- Basic info: User-ID, Name, City, Language(s), Profile-version;
- Work and Education: Employer(s), High School, College(s), Grad School(s); and
- Interests: Music(s), Book(s), Movie(s), TV(s).
UPDATED user-ID profile-version
This command acknowledges that the peer has successfully updated its public profile. If the client does not get a
UPDATED reply to a LOAD message after a minute than it should assume the update has failed and record the event in
error.log without retrying.
This command asks for location of an entry in personal interests and public shares of peers which are stored as XML files (sent from peer to server).
RESULTS entry num-Replies user-ID1 peer-IP1 peer-port1 user-ID2 peer-IP2 peer-port2 .... user-IDn peer-IPn peer-portn
This command indicates the location of an entry in response to a FIND message (sent from server to peer).
This command queries the public profile of user-ID.
INFO user-ID file-length file-content
This command sends the public profile of user-ID in XML format in response to GETINFO request.
Note that, there is no space after each message.
Following are the application level messages sent between peer using TCP sockets:
This command asks for friendship establishment by user-ID1.
This command confirms friendship of User-ID1 by User-ID2.
This command asks for profile updates of a peer since the profile-version.
REQUEST user-ID profile-version
This command asks for profile updates since the profile-version of user-ID from another peer (such as a common friend).
PROFILE user-ID profile-version XML
This command indicates the current profile version and sends the updates since the profile-version indicated by the REQUEST. The reply consists of wall updates as an XML file.
EXITING user-ID profile-version
This command indicates that the user-ID will be leaving with the current profile-version. If the receiving friend has an earlier version of the profile, it will REQUEST a profile update.
This command queries a posted file which is referenced in the XML file transmitted in an earlier REPLY message.
FILE file-name file-length file-content
This command sends a posted picture or video in response to GET message.
Note that, each request is handled by a separate active socket. This socket should be terminated when the update is completed.
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.
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
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
Moreover, if the updated profile includes any new file, the client will use
GET to obtain the file from Alice.
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
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.
Report all major actions as the program communicates with other server/peers
in a file named
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
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.
You must submit all the source code with sufficient comments to help understand the code.
You must include in your submission a file named
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
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.
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).
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:
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