Simple Chat Room Protocol (SCRP) - Application Model, Commands, and Function Descriptions, Study Guides, Projects, Research of Electrical and Electronics Engineering

Download Simple Chat Room Protocol (SCRP) - Application Model, Commands, and Function Descriptions and more Study Guides, Projects, Research Electrical and Electronics Engineering in PDF only on Docsity!

PROJECT REPORT

APPLICATION LAYER PROTOCOL

ECE545, Fall 2005

Submitted by: Yimeng Li

Zeping Shi

Ling Lu

Date: 10/06/

1 PROTOCOL DESCRIPTIONS

1.1 Simple Chat Room Protocol

The Simple Chat Room Protocol (SCRP) defines rules and message format for a simple chat room application between the client and the server. This application is the type of simple many-to- many C/S model as shown in Figure 1.

1.1.1 Application model

The application model is rather simple as multi users are chatting in multi chat rooms supported by a single server. Users are able to create a new chat room on the server, to join in an existing chat room, and quit from any chat room he/she is now connecting with. There is only one server physically, but multi chat rooms can work concurrently on the same server. The logical relations among server, client, and chat room can be described as Figure 2.

In Figure 2, n chat rooms are supported on the server. Each user has one or more clients communicatingwiththeserver.Aclientissubstantializedasachattingwindowontheuser’s computer like MSN Messenger. A user may chat in multi chat rooms, i.e., chat with different friends in the same time, by opening multi windows, one window for each client.

1.1.2 Services

The protocol provides following services:

1. Chat room creation/close.
2. User’sdynamicjoininginor quitting from an existing chat room.
3. Message delivery in each chat room.
4. Chatting monitoring.
5. User kicking out.

1.1.3 Commands list

A user can use following commands to operate chat rooms on the server. Since all the commands are issued by clicking corresponding buttons on the GUI, not all arguments are explicitly specified by user.

Client

User Client User Client

Server

User

Figure 1 SCRP application model User A

Chat room 1 Chat room 2 Chat room n

Client (^) Client

User B

Client

User X

Client

Server

Client Client

Figure 2 Logical relations among server, client, and chat room

Source/Path Message body

Message header

Command

Variable Variable Variable

Figure 3 Message format

1.1.5 Message format

The message format is very simple in this protocol as shown in Figure 3. A message can be divided into two parts: Message header and Message body. Message header consists of several fields which contain control information for client/server communication. Message body has only one field which contains variable information in accord with the Command field.

There is no length restriction on the message (which can be easily implemented using the String data type in Java). That is, all fields have variable length so that we can extend the protocol (e.g., to modify command set or to add some new fields) easily without major modification to the source code. Besides, no length restriction on message body means users can input a large number of words as long as they want in just one message. This could be useful when a user wants to send a copy of a long article to his/her friend(s).

1.1.6 Design considerations

In order to provide the basic services of a multi chat room application, several considerations must be made on the basis of user requirements.

 Identify chat rooms

Because there is possibly more than one chat room on the server, it is important to identify each chat room so that messages sent to a specific chat room will not be delivered to wrong place.

IdentifierforchatroomcanbetheprocessID,thecreator’ssockaddress,or anything else that is uniquewithinthewholeapplication.However,fortheuser’sconvenienceofjoining an existing chat room, an easily read and memorized name should be the best choice.

 Identify clients

Similarly, each client should also be assigned a unique identifier within the whole application. This ID is used not only for identifying message source, but also for differentiate a single user from the user group when the administrator wants to kick that user out. The most natural way of client identification is to make use of some certain information which the operating system uses. The socket address, a combination of IP address and port number, provides a good choice to be the client identification.

 User’sprivilege

A user can have his/her privilege on chat room operation. One basic consideration is that each chat room should have one administrator who creates the chat room, monitors chatting messages, andrejectsunwelcomeusers.Apossibleapproachistoassignthechatroom’screatoras administrator automatically when it is being created. Thus he/she can kick out other users or even close the whole chat room, but can not stop the server.

 Chat room maintenance

The protocol should also have mechanism for chat room maintenance, including creation of new chat room, destruction of closed chat room, updating user list for each chat room, etc. This work could be done on either client side or server side. However, if the chat room maintenance is done by the user, the mechanism for electing a user as the system administrator will be necessary which could make the protocol more complex. Therefore, the protocol makes the function of chat room maintenance as part of the server.

 Message ordering

Message ordering in this protocol is not hard to achieve because it uses connection-oriented transport service provided by TCP and concurrently running threads to process the connections with all the clients.

1.2 Inter-Server Chat Room Protocol (ISCRP)

The Inter-Server Chat Room Protocol (ISCRP) defines rules and message format for multi-server chat room application between the servers.

1.2.1 Application model

The application model is different from the one described above in that there are multi servers supporting multi chat rooms in the application. In this protocol, users are able to do the same thing as in SCRP through multi servers. The logical relations among server, client, and chat room can be described as Figure 4.

The architecture for this multi-server chat room is similar with that of a single-server chat room, except that extended message delivery and synchronization are needed for communication between servers.

1.2.2 Services

The protocol provides following services:

1. Chat room creation/close on remote server.
2. User’sdynamicjoining in or quitting from a remote chat room.
3. Message delivery between servers.

User A

Chat room 1 Chat room 2

Client (^) Client

User B

Client

Server α

Client

User C

Chat room 3 Chat room 4

Client (^) Client

User D

Client

Server β

Client

Figure 4 Logical relations among server, client, and chat room

Synchronization is another critical consideration in the multi-server application because messages may probably be delivered to wrong destination if the chat room and user information is not synchronized among all the servers. There may be two choices for synchronization. One is to keep a complete chat room and user table on each server and update it each time when there is any modification on it. Another choice is to only keep information about local user and remote chat room on each server. For simplicity of protocol, the latter choice is used. However, each server should have knowledge of the positions of all the chat rooms.

 Differentiate local and remote chat rooms

Messages sent to local or remote chat rooms should be delivered in different ways. Generally, if a chat room is created locally and the server knows only local clients are connecting to it, the message delivery can be very simple. However, if a chat room is created on a remote server or it is created on local server but the server does not know whether there are remote clients connecting to this chat room, the message delivery can be more complicated. In such case, the server must forward messages to other servers and the remote server must check if there are local users belonging to that chat room before it forwards messages to its clients.

 Message tracing

Message tracing can be done with a path consisting of all the servers a message passes by. Each messagehasitsheaderconsistingofa“Source/Path”field.Whenaserverreceivesamessage,it adds its name/address to the message header before it forwards this message to the next server. When the message reaches the destination and is displayed on the chatting window, the user can find the path from source node to destination.

2 IMPLEMENTATIONS

The two protocols are both implemented in Java. Functions are separately implemented on Client side and Server side, as shown in Figure 5.

CRM

CR

SM

CR CR

SM CRM

CR CR

SM

CRM

CR CR

SM

Server

Server

Server

CRM: Chat Room Manager CR: Chat Room SM: Server Messenger

Figure 5 Software structure for server

2.1 Software architecture

There are several logical entities running on a server:

 CRM : Chat Room Manager, a thread that manages all the chat rooms created locally. On demand of a client, CRM creates a new chat room with name specified by the user, or close a chat room if user issues a CLOSE command on that chat room. It is the core of a server.

 CR : Chat Room, a thread that accepts user messages from clients and forwards them to all the other clients in the same chat room. It is also the interface to user which consists of several text boxes and buttons where user writes and reads messages and issues commands to the server.

 SM : Server Messenger, a thread that is created to manage inter-server communication when a server connects with another server, one for each connection. In the presence of SM, two servers do not communicate directly but through their own Server Messengers.

In order to implement chat room management, three tables are used on the server.

 Chat Room Table <roomID, roomhandler>  Remote Room List  Locally Created Room List

A basic flow chart of server and client can be shown as Figure 6. A sample of the graphic user interface is shown in Figure 7.

Server start

Open ports: Server_listening_port Client_listening_port

Listen for server connection request

Listen for client connection request

Create Server_Messenger

Server request?

Communicate with other server

Client request?

Create Chat_Room_Manager

Control chat room locally

Y Y

N N

Client start

Connect to server

Send room name to server

New room?

Create chat room on server

Chat with other users

Y

Join in chat room

N

Figure 6 Server and Client flow chat

 Otherwise, creates a new chat room for this client and updates corresponding tables. The connection between server and client is used to deliver messages locally. All inter-server messages will be processed by the Server_Messenger.

3. Receive a server connection request

When the server receives a connection request from another server, it sets up inter-server communication with that server. In addition, a connected server list will be displayed on the server window. After that, the server can forward messages to or receives messages from that server. There is no limit on the number of inter-serverconnectionsbesidesTCP’sconstraints that all the servers can connect with each other in an arbitrary topology.

4. Connect to other servers

Ifthe“Connect”buttonispressed,the server will connect to another server which address and port number is specified by user. The server address can be an IP address, a hostname (e.g. localhost), or a complete hostname + domainname.

5. Termination

Server can be terminated by pressingthe“StopService”button. All communications through this server will be closed if it is terminated by user. The two listening ports will also be closed.

2.2.2 Client side

1. Initialization

When starting up, the initialization for client includes two steps:  The client creates a stream socket and connects to the server through the port on which the server is listening.  If the connection request is accepted, the client will see a list of current running chat rooms and will be asked to input a chat room name. If this name already exists in the list, the client will join in that chat room. Otherwise a new chat room will be created for the client.

2. Termination

The chatting can be terminated whenever the user wants. There are two choices to terminate a client by the user – he/shecanpressthe“Disconnect”buttonattopofthechattingwindow or just kick himself/herselfoutusingthe“Kickout”buttononthechatroomwindow. However, it is not a good choice to close the chat room directly if not all the users want to quit it.

3 COMPILATION AND TEST

3.1 Compilation

1. The compilation should be done on the ECE server with java 1.5 packages. Since this implementation uses GUI, all the test steps should be done in an X-window supported environment.
2. Make sure following files and folder are in the same directory.

File: Makefile, server, client

Folder: src Try “make”tocompiletheprogram: % make If this does not work, try the following command to compile the program: % mkdir bin % javac -sourcepath src ./src/server/SuperServer.java -d bin There should be a bin/ folder created in the same directory. All classes are in this folder.

3.2 How to test the program

1. Server side

To start server, try:

% server &

Whentheserverstarts,youwillbeaskedtoinputtheserver’sname:

This name is used for message tracing and it would probably appear in later messages.

Then click“StartService”buttonontheserverwindow:

2. Client side

To start a client, try:

% client &

If you want to open n clients, just run above command n times.

Whentheclientstarts,youwillbeaskedtoinputtheserver’saddressandportfirst.

Byclickingthe“Connect”button,youwillbeabletoseealistofcurrentlyrunningchatroom,as “chatroom 1 ”and“chatroom 2 ”inthiscase.

You will also be asked to enter name of the chat room. If you enter a name from above list, you will join in that chat room. Otherwise a new chat room will be created for you.

Protocol design Coding Report Yimeng Li √ √ √ Zeping Shi √ √ √ Ling Lu √ √ √