[Standards] Proposed XMPP Extension: Roster Versioning

Richard Dobson richard at dobson-i.net
Wed Mar 5 13:25:09 UTC 2008


> You can't use timestamps - they're not strictly increasing, for 
> various reasons.
Why does it need to be strictly increasing? As already explained the 
version identifiers should IMO be opaque and just be a server 
implementation issue, I still can't see any reason why this needs to be 
set in stone the protocol as a MUST, should only be a RECOMMENDED so 
that server implementors have an idea of where to start from as a way to 
implement this.
> Firstly, two roster changes could happen at precisely the same moment. 
> To be fair, by introducing cluster node identifiers, and having a 
> strict strong ordering of them, you could avoid this.
It could do yes, why is it a problem if they happen at the same time and 
are marked with the same timestamp?, it will just result in them both 
being pushed, how is that an issue?.
> Secondly, the clock on a computer can, and surprisingly often does, go 
> backwards. That's a much harder problem to solve.
Maybe so, do you have any more information on how prevalent this is? How 
long it lasts for etc?
> Thirdly, in a clustering situation, you'd have to ensure that the time 
> on each cluster node was perfectly synchronized.
No you wouldn't necessarily, not if the timestamping was happening at 
the central data storage layer (i.e. the database server), and again 
this is just an implementation issue and is easily overcome, not 
something that means its impossible.
> So the closest you can do would be a modified timestamp that had 
> additional logic during generation to ensure it never went backwards, 
> in which case you don't need the cluster identifier anymore, and 
> that's effectively the same as having a strictly increasing integer 
> sequence anyway, so it's easier to just do that. But even if you did 
> want to use timestamps, just representing them as an integer is pretty 
> trivial. Look at the definition of "modtime" in ACAP (RFC 2244), which 
> defines a strictly increasing modified timestamp represented using digits.
Yes I know I could represent them as integers, but id rather not if I 
don't have do, id prefer to have the flexibility to compress and shorten 
them to reduce bandwidth consumption as much as possible.

> It's useful for clients to be able to determine the ordering locally, 
> on occasion. If we removed this, we'd also have to ensure that roster 
> pushes were sent to the client in-order, which currently we don't 
> mandate. (Making this a SHOULD is sane, but in the cluster case, it's 
> quite hard).

Well im pretty sure XMPP dictates in order processing of stanzas so 
surely the roster updates should thus be in order? Also you haven't 
really answered my concerns about allowing clients to determine meaning 
from the version identifier introducing the possibility of bugs and 
interoperability problems which IMO is a far more serious issue, and one 
that doesn't exist if the client just treats them as opaque strings.

Also even if they were out of order (which I think would be unlikely 
because it would be only likely to happen when several roster updates 
were happening at the same time) it doesn't really cause much of an 
issue as far as I can see, its just that you might have one or two 
roster pushes that you have already cached pushed to you again, hardly 
the end of the world, and should be something the clients should be able 
to cope with, as what would happen if a servers database server crashed 
and needed to be restored from a backup and the most recent roster 
updates that have already been pushed arn't there, or the server now 
thinks it hasn't pushed the changes yet and ends up re-pushing changes, 
it shouldn't make any difference to the client, some method to 
re-synchronize needs to be in place to handle this, I think to solve 
this issue if the version id (be that timestamp or incrementing id) the 
client specifies is further on than any of the ones the server has you 
would need to re-push the entire list the server has invalidating the 
client list somehow (to ensure new now non-existent contacts that were 
created in between the db backup and the crash do not hang around).

>>> Plus, nobody can get it wrong.
>> How exactly are they going to get it wrong if its an identifier that 
>> only the server is interpreting the meaning of?
>>
>>
> It's the server I'm worried about. :-)
OK but that doesn't really answer my question.
> You just use a 128-bit unsigned integer. There is no upper limit here 
> - in particular, there is no upper limit specified anywhere in this 
> document - XSD merely states that a xs:nonNegativeInteger is a 
> sequence of digits, and has "countably infinite" cardinality.
>
> If you really and truly believe that practical limits of 64-bit 
> unsigned integers can cause problems in the real world, I honestly 
> don't know what to say except show you the figures - you could have 
> thousands of updates every millisecond, and still last over half a 
> million years - 574,542 roughly, assuming a fixed year length of 
> 365.25 days.
>
> I'm all for designing for the future, but you have to draw the line 
> somewhere, and besides, I figure we'll be on something bigger than 
> 64-bit well before then - a jump to 128-bit gains us 10^25 years of 
> breathing space, and I'd like to imagine we can think up a solution 
> within that time, assuming that's prior to the heat death of the universe.
Sure you can keep increasing the bit size of your integer in your 
implementation, but the spec still needs to dictate what happens once 
you reach overflow if its going to define that you have to implement it 
that way as well as how long the integer should be, although I still 
fail to see why strictly increasing numbers should be a MUST at the 
protocol level, IMO this is an internal server implementation issue and 
not a protocol one, im all for recommending that as a way for the server 
to implement it, but still don't think it should be MUST only RECOMMENDED.

Richard





More information about the Standards mailing list