RPIcq

Project Description

Due Saturday, March 3^rd at midnight (that minute between Saturday and Sunday).

For this program, you need to write the networking that mimics the very popular chat system known as ICQ. Skeleton and UI code is available here. IMPORTANT: This code is merely a guideline. You do not need to follow it directly, and you can modify any code provided as you see fit.

You need to implement a system that does the following items: (Note that items 1, 2. and 3 you are not given any code for.)

1. You need to design a protocol for the RPIcq system. The system should use a message passing system over sockets to allow multiple clients to chat with one another. There should be a central server that clients use to log into the system. From that point, the user should be able to chat with as many people as he wants.

2. You need to write a multi-threaded server from scratch. This server must keep track of all users in your chat system. It should operate on a known port. The server should also facilitate communication between users any way you see fit.

3. You need to write a network-client from scratch that contacts your server, and lets the server know when the user logs in and out of the system. It should also be used to contact the server to find out who’s online. This network-client can do more things, but it’s up to you.

Some code is provided to help you with this:

4. The User interface is done for you. If you want to create your own, that’s fine. But keep in mind this is a course on network programming. You won’t receive additional credit for doing this, but it might be fun.

a. There are several callback functions in the UI code that you can use to integrate your networking code. We’ll visit them soon.

5. A Client skeleton is provided for you. Client here means the main class that the user would invoke to run the application. I am not referring to a network client used to connect to a server. ClientSkeleton.java sets up the UI, and provides callbacks for dealing with the network. Several things should/can happen from this class.

a. The network-client (part 3) should contact the server in the Constructor.

b. The loginUser() method is a callback from the UI. In this method, the network-client should log the user into the system. After logging the user in, it should get a list of users currently on the system. Once the list is received, it needs to be posted in the UI. This is done by calling mMainFrame.setUsers(Vector) or mMainFrame.addUserName(String). The first method takes a Vector of Strings which are the user names to show. It replaces the previous list with the one passed in. The second method takes a single String, which is one user name. You can use mMainFrame.removeUserName(String) to remove a single user name from the list.

c. If the user double clicks on someone’s name, the startConversation() method is called. At this point, you should somehow facilitate the conversation between the two users. You have two options: One is creating a new set of connections between the two clients. (This is a peer-to-peer approach, with skeleton code provided in ConnectionSkeleton.java). The other option is sending all messages through the central server. In either case, you need to associate the MessageSplitFrame passed as a parameter to this method with a connection, so messages in this conversation get posted to this window.

d. When the sessionStop() method is called, network connections should be cleaned up and the application should be stopped.

FAQ:

1. Should the user be able to talk to the same person in two different message panes?

No, the user shouldn’t. But you don’t have to worry about it. That’s a problem with the interface, not the networking. Don’t worry about it, and you can assume that the user won’t try to do that.