Based on my experience with T-Mobile’s GPRS system in Seattle, I assume that HTTP over GPRS, EDGE, or 3G is unreliable. My wife’s experience with AT&T’s EDGE service with her iPhone has been much more positive, but this could be because of the flexibility and reliability of Safari over Windows Mobile’s Internet Explorer. In any case, I have to assume the worst.
Simple Retransmission Protocol
Message IDs between the server and client are independent and sequential. If a message arrives out of order and the missing messages have timed out on receipt by the client or server, either side should be able to issue a resend request for message IDs.
On both the server and client side, a message buffer must be implemented. On the client side, the message buffer should discard in-order received and processed messages, such that only out of order messages are held before processing and the queue gets a chance to refill.
On the server side, cumulative world state changes, messages, etc., need to be stored for the client between batch updates. Some reasonable (10-30 seconds) window of state changes need to be stored in case of retransmission.
Both the client and server keep track of IDs.
When the user performs an action in the client, the action request is stored for the next update polling request. Some actions may force an immediate update polling request. The update request may have one or more actions performed by the user.
Every n-seconds, the client sends an update request which contains recent client actions, which causes the server to send an update batch in return. Each update batch should be of minimal size, using IDs where possible (both for graphical and text resources, if appropriate). A batch contains one or more identifiable update blocks, which contain:
- system messages
- broadcast or tell messages from other users
- movement updates within the client’s viewport
- state updates on mobiles within the client’s viewport
Additional update blocks may be included in the batch to fill in missing updates. The batch may also includes a list of missing client message IDs that the server never received. The client may, if designed appropriately, resend recent, missing messages.
In short, message queues (MQ) allow sharing of messages in a generic way between system components. The upshot is that it allows for translation of messages between client and service types allowing a single MQ to serve and synchronize world state between multiple representations (browser, 3D client, text).
A message is as detailed as the component which uses the finest detail, where possible. It’s up to the interface to the client to translate these messages appropriately, such that a user of a text-only client might have to enter “walk to Soandso” in order to move his avatar around the room or zone in a way that 2D and 3D clients could see. Likewise, a 3D client walking around the room would have to be translated into text terms (“Soandso meanders until he stands beside Alice.”).