The semester project will focus on the development of an Online Social Network. Online Social Networks, such as Facebook, Twitter, and Google+, are commonly deployed as client/server architectures and take advantage of content distribution networks. As privacy is becoming a major concern, we will develop a privacy protecting Cloud based Online Social Network in three phases.
In phase one we will implement a simple messaging platform based on the client-server model. Using transport layer protocols (i.e., TCP and UDP), we will develop chat and file sharing functionality.
In the second phase, we will develop cloud integration using commonly used free cloud storage providers such as Dropbox, Google drive, and Microsoft SkyDrive. Using transport and application layer protocols, we will develop a framework for profile registration as well as content storage and distribution.
In the third phase, we will address efficient content querying and delivery issues using peer-to-peer communication mechanisms and develop access control mechanisms to ensure user privacy.
In this phase you with learn to use the transport layer protocols (i.e., TCP and UDP) and client/server communication. We will implement a simple messaging and file exchange platform (similar to Napster).
The code that you develop in this part will serve as a basis for the following phases of the project. You must create a pair of programs (client and server). The server will act as a central registry for clients to lookup location of their friends. Clients will register with the central server when they become online. The server will keep a record of ID, IP, port for each online client. Queries to the server will be via UDP whereas communication between clients will be via TCP.
The server code should be started with a parameter of port number. Similarly, client code shold be started with parameters of user-ID, server-IP, and server-port (all seperated with spaces). After the client program is started it has to contact the server to indicate it is online and register it's TCP welcoming socket (which will be randomly chosen by the operating system).
Clients have to notify server when they terminate. However, if a client terminates abruptly, peers need to notify the server. The server will then drop the entry from the database.
After learning location (i.e., IP and port number) of a peer from the server, a client can establish a direct connection with the peer to chat or exchange files. For file exchange, users can ask list of current files and request files.
Following are the application level messages sent from/to the server using UDP sockets:
REGISTER user-ID user-IP user-port
This command registers a user with user-ID with the server where
user-port are the IP address and port number through which it will handle requests from peers (sent from user to server). Note that the registered port is the address of welcoming TCP socket for user communication.
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 asks for location (i.e, IP address and port number) of a user with user-ID.
LOCATION user-ID user-IP user-port
This command indicates the location of a user in response to a QUERY message (automatically sent from server to user in response to
QUERY). If a user does not exist in the list a user-IP of
0.0.0.0 and user port of
0 is returned.
QUIT user-ID user-IP user-port
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.
DOWN user-ID user-IP user-port
This command indicates the user with user-ID can not be reached at user-IP and user-port (sent from another user to server to indicate a user is not reachable). The server than uses
PING message below to test the validity of claim.
Following are the application level messages between the server and user using TCP sockets:
PING user-ID user-IP user-port
This command probes user registered at user-IP and user-port to see if they are online by establishing a socket connection over TCP. If no
PONG response is received within a minute, it is removed from the user table. The command will actually be unsuccessful if the server is down and TCP handshake should be monitored.
PONG user-ID user-IP user-port
This command replies to server probe indicating user-ID at user-IP and user-port is online (automatically sent in response to
Following are the application level messages sent between users over the TCP sockets:
This command asks for friendship establishment by user-ID1 through a TCP connection with another user user-ID2. This command initiates a
QUERY lookup to the server and if a valid response is recieved, a TCP connection is established. If TCP connection is not established in a minute, the user will notify the server that user-ID2 is not live via
This command confirms friendship of User-ID1 by User-ID2 and allows subsequent
CHAT. The message is automatically sent in response to
FRIEND if the user is not already in a chat session.
This command indicates that User-ID2 is busy to talk. Note that, in current implementation a user can chat with a single friend. Hence, once a
CONFIRM message is send to chat with someone, a user will reply with
BUSY responses to new
CHAT counter message
A chat exchange between users 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
This message indicates
CHAT message with
counter is delivered to the user and is sent automatically.
This command ends the current chat session and related socket connection.
This command asks for profile updates of a user since the profile-version. This command will be especially useful for OSN in later phases.
RELAY 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 file-length XML
This command indicates the current profile version and automatically sends the updates since the profile-version indicated by the
RELAY. The reply consists of wall updates as an XML file. Note that, if profile is empty or a user does not have any information about requested friend, an empty XML file should be sent.
This command queries a posted file which is referenced in the XML file transmitted in an earlier PROFILE message.
FILE file-name file-length file-content
This command sends a posted picture or video in response to a
GET message. If the requested file does not exist the reply will have a file-length of 0 and no file-content. Note that we will only exchange ASCII files (no binary files such as jpg at the moment).
Note that, there is no space after each message.
Report all major actions as the program communicates with other server/users in a file named
We assume file sizes to be at most 1M characters.
We assume user-IDs and 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
You may utilize localhost (127.0.0.1 or actual IP address) to test your program by running both server and clients on the same machine (with different port numbers).
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).
Except file transfer, you should add end-of-line symbol ASCII LF '\n' to messages so that receiving TCP is able to know when a message is finished.
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.
You may work individually or with a partner. (No group of three or more is allowed).
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 (in particular, mobile app or a well designed GUI) not required by the project (optional and at the discretion of the instructor) in addition to requirements marked as [bonus].
This document will evolve as we discuss the project and determine communication protocols and messaging formats.
See pages 159-161 of the text for udp socket and pages 164-167 for tcp socket examples in Python, http://docs.oracle.com/javase/tutorial/networking/sockets for Java, and http://www.faqs.org/faqs/unix-faq/socket/ for C. You may also look at http://www.cse.unr.edu/~mgunes/cpe401/cpe401sp09/Lecture18.ppt for threaded programming.
Last updated on Oct 29, 2013