In this assignment, we will develop a Napster-like phone-to-phone Online Social Network.
You must create a pair of programs (client and server). The client will run on a phone (preferably Android) whereas server can be same as the previous assignment. 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. Users will post a message to friends or friends of friends. When a user receives a message from a friend that is posted as friends of friends, it will relay the message to its own friends. Note that, such messages will not be forwarded further.
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.
This command looks up the register list for a keyword with no space. The keyword is a single word that can be user-ID, name, or last name.
RESULTS file-length XML
This is in reply to
SEARCH keyword and consists of all user-ID, name, last-name, user IP, user port information as an XML file.
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.
Following are the application level messages sent between phone 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 exchange of 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 becomes online.
CHAT user-ID1 user-ID2 counter message
A chat exchange from user-ID1 is sent to user-ID2 with a counter that increments. 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.
ENTRIES user-ID time
This command asks for wall posts since time. The posts will be compiled by the user where they can include posts from friends (if they indicated friends of friends for a post). Also, 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.
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 Apr 6, 2014