Hi Jahmai, Your solution seems like it might be the best for your needs, but I will think about it further...
Peter On 3/20/12 2:45 AM, Jahmai Lay wrote: > Hi, > > The purpose of this post is to declare a problem statement for us and > how we solved it and to elicit feedback on our solution, as well as > encourage this to be considered in any future versioning scheme that > may be applied to the PubSub specification. > > I'm an engineer co-founding a startup for mission critical realtime > location systems using mobile devices like smart phones, and we have > chosen XMPP as our realtime message bus. > > The PubSub and Common Alerting Protocol XEP's fit our need for alert > aggregation between individuals in distress and the caretakers of a > given geographical area. > > To set the scene; we have an "alerts" node where CAP alerts are > published by someone in distress. These alerts are subsequently > updated by caretakers in the field either with additional information > or to transition the alert state (such as acknowledgement). > These updates occur from occasionally connected mobile clients and we > assume that these client connections are both fragile and expensive. > > It is crucial for us that the collection of items held by a client for > a node are synchronized with the server - that is, that each node > observer will have precisely the same collection after receiving the > same event sequence sent from the server. > > This is challenging when we have nodes which have many publishers and > sometimes items have many publishers. > > With regards to possible race conditions in updating items between > publishers, we are satisfied with "latest wins" logic and is not being > considered in this discussion. > > During development we have discovered cases where desynchronization > of the collection of items stored at a node can occur in which the XMPP > specifications do not appear to address. > > For example; > > C1: <iq id="id1" type="get" to="pubsub.criticalarc.com" > from="[email protected]/client1"> > <pubsub xmlns="http://jabber.org/protocol/pubsub";> > <items node="my_node" /> > </pubsub> > </iq> > > C2: <iq id="id2" type="set" to="pubsub.criticalarc.com" > from="[email protected]/client2"> > <pubsub xmlns="http://jabber.org/protocol/pubsub";> > <publish node="my_node"> > <item id="item1" /> > </publish> > </pubsub> > </iq> > > S: <iq id="id2" type="result" to="[email protected]/client2" > from="pubsub.criticalarc.com"> /> > > S: <message id="id3" to="[email protected]/client1"> > <pubsub xmlns="http://jabber.org/protocol/pubsub#event";> > <items node="my_node"> > <item id="item1" /> > </items> > </pubsub> > </message> > > S: <iq id="id1" type="result" to="[email protected]/client1" > from="pubsub.criticalarc.com"> > <pubsub xmlns="http://jabber.org/protocol/pubsub";> > <items node="my_node"> > <item id="item1" /> > </items> > </pubsub> > </iq> > 0123456789012345678901234567890123456789012345678901234567890123456789 > In this case it is not clear to client1 whether the latest version of > item1 is in the event or the result. > > This case is exacerbated when Result Set Management is used to receive > multiple pages of items are interleaved with events updating or > removing the same items. > > I have read previous discussions regarding timestamping and versioning > for pubsub. > > We considered using timestamps, but dismissed them due to very real > possibility that this sequence could actually occur within the same > time unit, and that if a timestamp needs to be 'massaged' for ordered > uniqueness, it's not the best choice. > > We considered using opaque versioning ala Roster management, but this > doesn't actually solve the above scenario because there is no natural > ordering to opaque strings, so determining which version is the most > recent is still a problem. > > As such, we have currently solved the problem by using a natural > ordering "ver" attribute on each item receives that the client can use > to compare. > > We have also added the ability to request historical events > (also versioned) so that when a mobile client connects it can resume > its event stream at minimal cost. > We did this because there is more in an event stream than just item > publications that we would like to know about. > (I can expand on this at request). > > Thoughts and criticisms welcome. > > Regards, > > Jahmai. > >
