CSEE W4119 Programming Assignment I

CSEE W4119 Programming Assignment I

Due: Wednesday, 11th March, 2015
Prof. Augustin Chaintreau, Pooja Shah, Olalekan Afuye, Yelin Hong, Jen-Chieh Huang,

Nivvedan Senthamil Selvan, Chenze Zhao

Description

The brilliant W4119 class last year implemented a chat room service using a client­server architecture. This legacy architecture maintains a permanent link between the server and the client until the user decides to leave the server. Everything seems to work pretty well. The following diagram shows the concept of the legacy architecture when user A sends a message to user B. The line connecting the users and servers denotes persistent TCP links, and the arrows indicates the directions which the message is sent.

However, many users started to complain about the service, and demanded an upgrade of the application because of the following reasons.

• ●  A permanent connection makes the server unscalable and limits the number of users serviced by a single server. Users can not login to the server once the maximum connection capacity is reached.
• ●  Besides, more and more users are running the chat application using wireless network. The unstable wireless link results in a disaster of the legacy chat room architecture as the user is disconnected each time the wireless signal is temporarily unavailable. (Note: it would be challenging if you’d like to implement fully automatic reconnection. The point here is to work out a method that the client does not have a consistent link to the server.)
• ●  Some users would also like to have some privacy. They want to chat with their friends directly without all their conversation being routed via the chat server. A peer­to­peer chat client seems to be a good solution for this scenario.

Thus, the TAs turn to the even more brilliant 2015 class for help. The idea is to develop a chat application with a message center server, and the key criteria of the new design is that n o permanent connection is maintained between the server and client. Bear in mind that the states of each party will need to be maintained locally, and synchronized using the network connection when needed.

Technical Specifications

The assignment includes 2 major modules, the message center and the chat client. It is important to note that at no point in time should there be a permanent TCP connection from the client to the message centre or vice versa.

1. Message Center

The message center, also known as the server, has the following responsibilities ­

1. User Authentication ­ Each user logs into the message centre with a

   username and a password. On entering invalid credentials, the user is prompted to retry. After 3 consecutive failed attempts, the user is blocked for a duration of 60 seconds (this should be configurable), and cannot login during this duration (even from another IP). While a user is online, if someone uses the same username/password to log in from another IP, current user will be notified and automatically logged out.

2. User Message Forwarding ­ Forward each chat message to the correct recipient.
3. Timeout ­ The message centre should have a configurable timeout value. If it does not receive a ‘LIVE’ signal from a user within the timeout, it considers the user to be disconnected.
4. Blacklisting ­ Allow a user A to block / unblock any other user B. If user A has blocked user B, B can no longer send chat messages to A i.e. the message centre should intercept such messages and inform B that the message cannot be forwarded. Blocked users also do not get presence notifications i.e. B will not be informed each time A logs in or logs out.
5. Presence Broadcasts ­ Notify the presence of other users logged into the chat room i.e. send a broadcast notification to all online users when a user logs in / logs out.
6. Offline Messaging ­ When the recipient of a message is not logged in, the message will be saved by the message centre. When the recipient logs in next, the message centre will display all the unread messages stored.

2. Chat Client

The chat client has the following responsibilities ­

1. Authentication ­ Provide a login prompt to enable the user to authenticate with

   the message center.

2. Chat ­
   1. Allow the user to send a message to any other user.
   2. Display messages sent by other users.
3. Notifications ­ Display presence notifications sent by the message center.
4. Find users online ­ Obtain a list of all the users currently online.
5. Heartbeat ­ Every 30 seconds (this duration should be configurable), the client

   should send a ‘LIVE’ signal to the message centre to indicate that the user is

   still logged in.

6. User Interface (BONUS) ­ A simple graphical user interface can be

   implemented for extra credit.

Peer-to-peer chat

The aim of this feature is to implement a chat service in which the message centre has minimal intervention once a conversation has been established. It can be developed on top of the basic chat room architecture.
The basic requirements of this feature are ­

7. Any user A wanting to private chat with user B will first request the message centre for user B’s IP address.
   1. If B is online, the message centre will provide B’s IP address and PORT, else it notifies A that B is offline.
   2. If B is offline, the chat client should report that the request failed.
8. On obtaining B’s IP address, user A can establish a connection directly with

   user B using said address.

9. From this point onwards, A can send private messages directly to B using the

   “private” command. Such private messages would be sent directly to the IP address without going through the server.

Bonus Part:

The following are suggested for bonus points. Feel free to discuss other ideas with the TAs. Ideas not in this list need to be discussed with the TAs to confirm them to be worthy of bonus points.

1. P2P Privacy and Consent

1.1 When A requests for B’s IP address, the message centre should notify B that A wants to talk it. If B agrees to the conversation, the server should provide A with B’s IP address. Else, A cannot initiate a conversation with B.

1.2 When A requests for B’s IP address, the message centre should check B’s blacklist preferences. If B’s blacklist includes A, the message centre should not provide B’s IP address to A.

2. Guaranteed Message Delivery
By the problem definition, the server maintains a database of the clients and their IP addresses. Sometimes, this database might be outdated and the client might actually be offline. For e.g. if the client has been disconnected abruptly, and the message centre is still waiting for timeout. In this case, the sending client will attempt to connect to the last known IP of the receiving client and the connection will fail. Such failure should be handled and the sender can re­contact the server to leave an offline message. Also, if the receiving client logs in with a new IP, the sending client should also be aware of this and not sending message to the old IP any more.

Authentication requirements

● You should use the file “credentials.txt” to import all the username/password combinations. The first word in each line is the username and the second is the corresponding password. Note that the content of this file could be changed during the testing of your assignment.

Commands

The following commands need to be implemented in accordance with the technical specifications above. For the following, assume the commands were run by user A.

Sample Run

Case 1 : Successful login Terminal 1
>make
>java Server 4009

Terminal 2

>make
>javaClient10.11.12.134009 //Server’s IP address / port >Username: foo
>Password: bar
>Welcome to simple chat server!
> //Prompt to enter commands

Case 2 : Unsuccessful login Terminal 1
>make
>java Server 4009

Terminal 2

>make
>javaClient10.11.12.134009
>Username: foo
>Password: bar1
>Invalid Password. Please try again
>Password: bar2
>Invalid Password. Please try again
>Password: bar3
>Invalid Password. Your account has been blocked. Please try again after sometime.
The user should now be blocked for a configurable BLOCK_TIME (e.g. 60 seconds)
The terminal should shut down at this point.

Terminal 2 (reopened before BLOCK_TIME seconds are over)

>java Client 10.11.12.13 4009
>Username: foo
>Password: bar
>Due to multiple login failures, your account has been blocked. Please try again after sometime.

Terminal 2 (reopened after BLOCK_TIME seconds are over)

>java Client 10.11.12.13 4009 >Username: foo
>Password: bar
>Welcome to simple chat server! >

(NOTE : See the appendix for more examples of command behavior).

Development Environment Specifications

Development

You can choose between Java, Python and C/C++ to write your program. Whichever you choose, your program m ust compile and run on the CLIC machines. For your reference, the versions of the compilers/interpreters on the CLIC machines include:

• ●  Java ­ 1.6.
• ●  Python 2.7.3
• ●  C/C++: gcc/g++ 4.6.3

//Server’s IP address / port

NOTE ­ If your code doesn’t compile, we will call you to have a look at it and fix it. However, it will result in a deduction of 20% of your total points.

Deliverables

Your program will be submitted via courseworks. Please submit a zip file using the format <UNI>_<Programming Language>.zip (e.g. cn1111_python.zip) to the Programming Assignment 1 folder. Make sure you include all of the following files in your zip file:

• ●  README.txt: Your readme file should include but not limited to the following parts
  • ○  A general description of your programming design and data structure
  • ○  Explanation of your source code (make sure your code is well commented and

    readable or you will be taken 5­10 points. To avoid such an undesirable

    scenario, tools like astyle1 may be helpful.)

  • ○  Detailed instructions on how to run/compile your source code
  • ○  Sample commands to run your program
  • ○  A short introduction of your additional features and sample test cases (N otice:

    discuss your design of additional features to one of TAs during office hour or post a private message on Piazza before you actually implement them, some features may not be considered worthy of the bonus points)

• ●  Makefile: if you are not familiar with makefile, you can read through the tutorial: http://www.cs.colby.edu/maxwell/courses/tutorials/maketutor/ This article is also helpful: h ttp://www.devin.com/cruft/javamakefile.html
• ●  Source code and other files you think are important

  Grading Scheme:

1 h ttp://astyle.sourceforge.net/

Note:

1. 50% of the total points will be deducted if you use a permanent connection.
2. If we find detect any plagiarism in your assignment, you will get 0 points in this

   assignment. In addition, you will be referred to the Dean of Students without any exception.

Bonus:

1. Advanced P2P features ­ 20 points OR Any 2 other features for a maximum of 20 points

Maximum points for this assignment ­ 120 points.
There are a lot of ways to get extra credit, so make sure to use this opportunity!

Reference Message Sequence Charts (MSC)

Appendix A: Command Usage

Consider a scenario where 3 users, A , B and C are currently logged in.

The below command should print the following results on A’s terminal.

1. online
online l ists all the users who are currently online (except for the logged in user). So

the output should be ­

2. message

3. broadcast ­ broadcast sends the message to all online users (who haven’t blocked A)

4. block

5. unblock

Consider that A has blocked B

Appendix B: In Case You Need a Clue

There is some information which may help you to know more about the assignment. In the world of networks, protocol is defined as “a system of digital rules for data exchange within or between computers.”2 In other words, a protocol is a method which defines how the participants in the network communicate with one another. It is easy to find some analogy in our daily lives. Let’s say, when you meet a new friend, you will need to do handshake first, introduce yourself, and start to talk (most of the time) . After the conversation is over, you may need to say “see you next time” or “bye” to end the session. The whole process and the messages exchanged (handshakes, introduction, saying goodbye) is an example what a protocol looks like.

Another good example of protocol is HTTP3. When a user enters the URL in the browser, the browser will send a HTTP request to the server like this:

GET /index.html HTTP/1.1 Host: w ww.example.com

This message indicates that this is a GET message using HTTP v1.1 protocol, and the client wants the contents of index.html from w ww.example.com. Upon receiving this request, the server may return the following information.

2 h ttp://en.wikipedia.org/wiki/Communications_protocol
3 h ttp://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol

HTTP/1.1 200 OK

Date: Mon, 23 May 2005 22:38:34 GMT
Server: Apache/1.3.3.7 (Unix) (Red-Hat/Linux) Last-Modified: Wed, 08 Jan 2003 23:11:55 GMT Content-Type: text/html; charset=UTF-8 Content-Length: 131
Accept-Ranges: bytes
Connection: close

<html> <head>

<title>An Example Page</title> </head>
<body>

Hello World, this is a very simple HTML document. </body>
</html>

The returned status code, 200, means that the request is successfully handled, and the contents of the HTML page is attached in the end of the message.

In this assignment, you may need to d esign your own protocol and process these messages. The intuitive way to specify the message exchanged is to set up the f ixed fields in the message. For example, your messages may look like the following. It is an example from RTP.

One common technique to design a protocol is called T LV (Tag­Length­Value)4. You may find it very useful when you need to expand or upgrade your protocol. In this design paradigm, the messages can be specified as the following:

4 h ttp://en.wikipedia.org/wiki/Type­length­value

With this technique, you can extend your protocol if needed without renovating your codes completely.

Academic Honesty Policy

You are permitted and encouraged to help each other through Piazza’s web board. This only means that you can discuss and understand concepts learnt in class. However, you may NOT share source code or hard copies of source code. Refrain from sharing any material that could cause your source code to APPEAR TO BE similar to another student’s source code enrolled in this or previous years. Refrain from getting any code off the Internet. Cheating will be dealt with severely. Cheaters will be penalized. Source code should be yours and yours only. Do not cheat.