The Union Platform (tm)

hi peter,
wherever we've determined that message delivery order matters for application development, union guarantees that order. for example, if you send three chat messages, they'll be delivered to all recipients in the order they were sent. or if you issue a join-room request followed immediately by a leave-room request, union guarantees that you get the join result before the leave result.

generally speaking, we believe that union shelters application developers successfully from delivery-order issues, but if you're concerned about any specific cases, or are encountering problems related to delivery order, please let us know.

colin

Hi collin,

thank you for your prompt answer. I'm thinking of an application similar to google wave. Wave uses the OT model (http://en.wikipedia.org/wiki/Operational_transformation) and xmpp for communication. I was wondering how to implement causality preservation with union. Causality preservation (I think it was first described in a groupware context in 1989 http://portal.acm.org/citation.cfm?id=66926.66963&coll=portal&dl=ACM ) needs more complicated ordering.

For example suppose client A sends message M1 while client B sends message M2 (same time without reading M1). M2 arrives to A and A replies with M3.

At client C

M1, M2, M3

or

M2, M1, M3

can appear but not

M1, M3, M2

Why? Because M3 was a response to M2. It does not have to be signed as a response.

Do you have any idea how to implement this in union?

peter

Hi Peter,

Here's a bit more information on how Union processes message:

i) Union guarantees that it will process messages received from a client in the order that they are received. It means that if client A sends message 1,2,3 it will not start processing message 2 until message 1 has been processed. However, it doesn't guarantee this order across clients.
ii) Similar to 1, Union guarantees that it will send messages out to a client in the order they are scheduled to be sent. It does not guarantee order across clients.

Together, that means that the specific scenario of M1, M3, M2 is highly improbable but not impossible, however, given i and ii it is still easy to come up with other scenarios that break causality preservation and other rules needed in a real time co-operative system.

To your specific example, you could selectively implement these rules for your app at a message level. Rather than using the various sendMessage() methods available in Reactor (UPC u1, u2, u57) you would instead use the Room.sendModuleMessage(UPC u70) method. An example would best illustrate:

1) Clients A, B, C want to use the shared doc application to edit a document.
2) Write a room module "RTCEModule" that implements rules to selectively enforce Causality Preservation, Intention Preservation etc to determine when messages are sent to clients. Since the room module is broadcasting to the room every client will receive the messages in the same order.
3) A room "sharedDoc" is created and the room module "RTCEModule" is deployed with the room.
4) Clients A, B, C join the room sharedDoc.
5) Whenever a client makes a change to the document they send a room module message to the room "sharedDoc".
6) Room module RTCEModule receives these messages and processes according to the rules in 2.

Regards,

Derek