130 likes | 246 Views
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
E N D
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 Logon/Logoff/ Messages Notifications Server Server User Client Server Server
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
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