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