Download Chat Server Project: Multiple Server Discovery and Communication and more Study Guides, Projects, Research Computer Science in PDF only on Docsity!
COP5615 โ Operating System Principles โ Fall 2006
Document Version 1.
Project 3 โ Protocol Design Phase
Team:
Aranika Mahajan - 31095373 Manu Sethi - 10317465 Rohin Sethi - 97173206 Twisha Patel - 05499574
Abstract :
In this project, we would extend the earlier scenario of Projects 1 & 2, to include multiple chat servers.
Fig: Representation of Chat Servers and Clients
The circles in the above diagram represents chat servers implemented in project 2. The square elements represent the user nodes connected to the servers. Each user node consists of user agent as well as end user modules developed in project 2. In project 2, peer-to-peer communication was disabled, which will be re-enabled in project 3. Also the servers will have the capability to communicate with each other.
Nodes will be named hierarchically in a globally unique fashion. The format is as follows:
Global Name= .
Hence Name collision is automatically prevented.
This project will be divided into various modules as follows: -
Module 1: Server Discovery Protocol:
Handling Server Name Collision
- Once the server is started, a predefined multicast address and a port number is used to listen to multicast messages from other servers on the network.
- The server asks the user to enter its name.
- Now to determine whether this name is unique or not, this name of the server is multicast to all other servers on the network using the following message:
Checkservername <server receiver port#>
- Once this command is listened to by other servers, there may arise two cases:
- Already there exists a server which has the same name. If this is the case the server which already has the same name will send a unicast reply to the server receiver using the following command:
Myname
On receiving this reply, the server asks the user to enter another name and again multicasts that name using the above command.
- No other server exists which has the same name till Timeout. In this case no reply is received. Then the server will again multicast a message asking for confirmation if it can keep that name or not.
Confirmname
If again no reply is received till Timeout then the server sets this name as its own name.
Server Discovery
As part of server discovery, we would use the random number concept. Every time a new server comes up, it would generate a random number from a particular range and hence generate a ConnectID. Then it would send a multicast message to all the other servers with a connect token and this ConnectID. Also, any other server which is not connected to the max number of neighbors would also generate a random number every X seconds. All the servers with the same ConnectID would reply back to this new server with a connect reply token (unicasting). The new server would acknowledge this connect reply to the max number of neighbors with a final connect token on first come first serve basis and to the others who had replied with a deny token. If no server replies to this new server, it would wait X seconds before it re-generates another random number and sends out the multicast message again.
Since all nodes will after some interval of time be connected to max no of nodes, hence the probability of fragmentation of the network is very low. Even if a node crashes and fragments the network, its neighbors will, in some time, connect to each other and hence join the network back again.
No of servers say 20 Let max number of neighbors be N (Preferably 4). Range of random numbers R = 1 to No. of Servers / N Random Number Generation after every X Sec (Pref. 300 Secs)
The purpose of sending to all neighbors is, that if any server lying along the path through which the message had come fails, then in that case other neighbors would be able to send the reply via some other path.
Module 3 : User to Server Communication:
Failure Detection
A Thread in each End User would continuously ping the server, and when it does not receive any response it assumes that the server has gone down and goes into Failure Recovery Mode.
Load Balancing and Failure Recovery
Whenever a new user comes up, we need to assign a backup server to it. For this when a user- agent comes up, we give it a number out of N in a circular sequence (N is the number of max neighbors), where each number refers to a neighbor in the neighbor list. We give a number and not a name because the list of neighbors is dynamic due to node failures and continuous reconnections.
In case of failure, the child sends a message to the backup server corresponding to the BackupID it was assigned in the neighbor list. If it doesnโt receive a reply from the backup server, it increments the backupID in a circular loop till it has tried all neighbors. If there is no reply at all, this child node dies.
Request : Adopt Reply : Adopted
Search for another End User
If an end user needs to search for another end user under some other server, it sends a message to itโs own server. The server sends it out to itโs neighbors to search for that user. The timeout in this case will be doubled than the usual timeout time. In case that user is found, the Server sends a reply to this message to the end user.
Request : Search Reply : Found <Port # of found user>
List of Commands :
The list of commands is as follows: -
- exit โ used to terminate the system
- alias โ used to define named aliases
- remove โ used to remove an existing alias
- send โ command to send the messages
- list โ lists all the current existing aliases
- setalias โ allows to set one's own alias name
- createroom โ creates a chat room and names that chat room
- joinroom - allows particular user to join a chat room
- leaveroom - allows the user to leave a chat room
- ulist - lists all the users that are in a chat room
- listrooms โ lists all existing chat room names
- search <loacal_username> - looks for users with name username across other servers and responds with IP address and port of all users with name username.
Message Flow:
1. Check Server Name Collision 1. Server multicasts the following command: - Checkservername <server receiver port#> 2. If any server has same name it sends back a unicast message: - Myname 3. If no reply within timeout then send another multicast message: - Confirmname 2. Server Discovery 1. Requesting Server multicasts the following command: - Hello < ConnectID > <sender server receiver port> 2. Servers with matching ConnectIDs reply back: - Connect < receiver server receiver port> 3. Requesting Server confirms the connection with the following message: - Connect Confirm/Deny
B
A
C D
Server 1
Server 2
Server Server^4 3
1(mcast)
1(mcast)
2 (unicast)
1(mcast)
