In v1.2.0 of AAVOnline, the biggest feature will be the ability to send messages to other pilots while logged in. To accomplish this I have created a web service based near-instant messaging framework.

The idea behind it is rather simple and easy to implement. Because AAVOnline already provides a framework for authentication I am able to piggyback on this existing framework and concentrate on message delivery. Validation is done on each messaging request made to the server (get or send) via a callback to AAVOnline's server side web service. This callback returns true or false and from there the messaging framework determines if it should continue processing the request. I implemented it this way so I can use the same messaging system in other applications in the future.

To retreive messages from the server, AAVOnline has a thread running in the background that sends a request to the server for any and all messages it has for the user. If the server has any (and the pilot can be authenticated) it returns all messages in XML. Each message has a unique hash identifying it from the rest as well as sender's name, base64 encoded content, and a timestamp assigned by the MySQL server. The get message thread on the client side receives this xml, processes it and creates new Message objects internally for each message received. If no messages are received it does nothing and waits until the next time around to check again.

In this messaging framework I have made an assumption on how people interact with instant messages.

Immediate responses are only expected in cases of active conversation.

Using this assumption, I am able to throttle up or throttle down the delay at which the get message thread downloads messages based on the activity of messaging the AAVOnline client is experiencing. i.e. If somebody is engaged in active conversation with another person responses are expected to be quicker than if a message is sent during an inactive conversation. If I had an asynchronous connection to the AAVOnline server, this would all be a moot point but with web services everything must be synchronous.

Finally, when a client wishes to get messages, they also send the highest timestamp which they have received. The server can now assume that it has successfully delivered all messages with a timestamp less than or equal to this to the client and can dequeue them from the database. After that it pulls out any remaining messages for delivery to the client.

Sending a message is simpler. When a pilot wishes to send a message, the client connects immediatly to the server where the message is queued in the database for delivery the next time the recipient wishes to get their messages.

jeremiah's blog | 4324 reads