In this assignment, we will develop a Napster-like peer-to-peer Online Social Network.
You must create a pair of programs (client and server). The server will act as a central index where clients will announce their location. Clients will establish a TCP session with the server when they become online and notify the server when they terminate.
The server code should be started with a parameter of port number. Similarly, client code should be started with parameters of user-ID, server-IP, and server-port (all separated with spaces).
The Server should use threads to handle client connections. Note that, you need to use locks to prevent concurrent writing of common data structures.
The clients will establish UDP connection sockets through which they will exchange direct messages with each others. Users will post a message to friends, friends of friends or public. When a user receives a message from a friend that is posted as friends of friends or public, it will relay the message to its own friends. Note that, friends of friends messages will not be forwarded further but we need to be careful with public posts to prevent broadcast storms.
Following are the application level messages sent from/to the server using TCP sockets:
REGISTER user-ID user-name user-last-name
This command is used to register a user with user-ID in the system. The server will allow users to search for friends in this list using either user-ID, name, or last name.
ACK user-ID user-IP user-port
This command acknowledges that the user is successfully registered with the server (automatically sent from server to user in response to
REGISTER). If the client does not get a ACK reply to a REGISTER message after 10 sec than it should retry two more times and if all fail assume the server does is not live and record the event in
This command indicates the user with user-ID is joining the system (sent from user to server). The server should pick up the source IP and port of the packet and update the information in the user table.
This command indicates the user with user-ID is leaving the system (sent from user to server). The server should assure the source-IP of the packet matches the user-IP before dropping the entry from the user table.
UPDATE file-length XML
This is an update to the public profile, sent as an XML file (see sample below).
This command acknowledges that the user's public profile is successfully updated where time is obtained from the XML tag in the updated file (automatically sent from server to user in response to
This command looks up the given keyword with no space in public profiles. The keyword is a single word that can be matched with any information in the public profile.
RESULTS file-length XML
This is in reply to
SEARCH keyword and consists of all matching public profiles along with users' IP and port as an XML file.
Following are the application level messages sent between clients using UDP sockets:
This command asks for friendship establishment by user-ID1 with another user user-ID2.
This command confirms friendship of User-ID1 by User-ID2 and allows subsequent messaging/wall posts.
This command indicates that User-ID2 does not want friendship establishment with User-ID1.
This message is used to indicate that user-ID1 has become online. The message should be sent to all online friends (learned via
SEARCH queries to the server) when a user with user-ID1 becomes online.
CHAT user-ID2 counter message
A chat exchange from user is sent to user-ID2 with a counter that increments for each message (separate counter for each friend). Message can be up to 1024 characters and will be displayed to the user. Messages with end-of-line characters should be sent as a separate
CHAT. Once the message is delivered to user-ID2, it will send a
DELIVERED user-ID2 counter to user-ID1. If user does not get an acknowledgement in 30 seconds it will retry for up to 3 times
POST user-ID file-length XML
This command pushes a content to friends as an XML file. After obtaining the XML file, your program should download (and potentially display with GUI) the linked content. Note that, a message can be marked for friends, friends of friends or public and hence it might further be forwarded. If a post is marked for public you should prevent broadcast storms and try to minimize secondary deliveries. Even though not a requirement, there will be bonus points for minimum spanning tree based broadcast implementations.
ENTRIES user-ID time
This command asks for up for all wall posts since the time in reverse chronological order. The posts will be compiled by the user where they can include posts from friends (if they indicated friends of friends for a post). As a bonus; if another user's user-ID is provided, the user will respond with its cached copy of the user's data.
WALL file-length XML
This is in reply to
ENTRIES time and consists of wall updates as an XML file. After obtaining the XML file, your program should download (and potentially display with GUI) the linked content.
Note that, these formats are recommended (as we will not cross test). You need to implement these functionalities.
Report all major actions as the program communicates with other server/users in a file named
We assume user-IDs to be at most 32 characters without any white space characters.
When a malformed message is received report it in a log file named
You may utilize localhost (127.0.0.1 or actual IP address) to test your program by running multiple users on the same machine but within different folders (with different port numbers).
If testing on multiple machines, be sure that the machines are not behind a NAT (or within the same subnet).
You might get TCP messages in multiple segments even one byte at a time. Hence, you must check whether you have read all the message when parsing them (TCP streams).
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.txt 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 in
Readme.txt file. 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.
You should work individually.
Your project will be tested to make sure it works properly.
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 (such as a well designed GUI) not required by the project (optional and at the discretion of the instructor).
There will be bonus for students that point to major issues or add to program structure.
This document will evolve as we discuss the project and determine communication protocols and messaging formats.
Don't wait till the last minute to start this phase!
Last updated on Mar 19, 2015