Quick Messaging Service

John Sung

Objective

• Use Demeter/Java to the fullest– Use COOL for coordination – Use RIDL for RMI

• Ability to send messages “instantly”

• Ability to handle 1 server fault at a time

QMS Implementation

• Implemented in 3.1 phases– Phase 1: Client/Server database with accessor

traverversals and testing infrastructure– Phase 2: Client’s GUI– Phase 2.1: Client/Server communication– Phase 3: Server/Server communication for

Fault-Tolerance

QMS System Architecture

Client ServerUser

Server

Server

Server

NotificationsLogon/Logoff/

Messages

Client’s View of System

• User Logs on and off it’s server

• Sends message with source and destination to the server

• Server looks up in the database to find the destination client

• Another server will notify if the current server is unreachable

Server’s View of System

• User Message Delivery– Find destination client in the database– Send the message directly to the client

• Notifications to other servers in the system– Client Logon/Logoff– New Server Entering System– Server Failure Recovery

Server Failure Recovery• Detection

– Attempt to connect to all of the servers in the system at a regular interval

• Recovery– All servers broadcast timestamp of failure detection time– Each server determines the server with the lowest

timestamp to take over– Failed Clients notified of change by the winning server– All servers update their databases

Fault-Tolerance

• Fault-Tolerance Robustness

• Able to handle 1 server fault at a time

• Possible Failing Cases– Client logon/logoff during server failure

recovery– New server attempting to enter system during

server failure recovery

Screen Shots

COOl Example selfex processServerFailureNotification;

mutex {serverFailureRecoveryStart, processServerFailureNotification ,getWonServer}

condition finishedRecovery = false; processServerFailureNotification {

on exit {

notificatoinReceived++;

if (notificationExpected != -1 &&

notificationExpected == notificationReceived) finishedRecovery = true;

}

} getWonServer requires(finishedRecovery) {

on exit {

finishedRecovery = false;

notificationExpected = -1;

} }

RIDL Example// the portal for the qmsServer object

portal qmsServer {

public void clientLogOn(ClientAddress newClientAddr) newClientAddr: copy;

public void sendMessage(qmsUserMessage newMsg) newMsg: copy;

public void clientLogOff(ClientAddress client) client: copy;

public ServerList newServerEnterSystemRequest(ServerAddress newSrv) newSrv: copy

return: copy ;

public void newServerEnteredNotification(ServerAddress newSrv) newSrv: copy;

public void newClientLogOnNotification(ServerAddress srvAddr,

ClientAddress newClientAddress) srvAddr: copy

newClientAddress: copy ;

public void oldClientLogOffNotification(ServerAddress srvAddr,

ClientAddress oldClientAddress) srvAddr: copy

oldClientAddress: copy ;

public Boolean isAlive() return: copy ;

} // qmsServer

Conclusion

• All of the basic functionality works– Client’s GUI– Client can send messages to server– Server can deliver messages from the client– New server can enter the system– Notifications of clients and servers– Very Limited Single Fault Tolerance

• There are still many bugs hidden in there!

Conclusion

• Found bugs in RIDL and COOL

• Demeter/Java Pros– Great for accessing databases and traversing

trees/graphs– Great for testing parts of the program

• Demeter/Java Cons– Performance of code generator/compilation– Robustness of different features