2009/4/21 Peter Saint-Andre <[email protected]>: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 4/21/09 12:57 PM, Jiří Zárevúcký wrote: >> 2009/4/21 Peter Saint-Andre <[email protected]>: >>> I propose the following implementation note: >>> >>> In some conditions, an XMPP client or server might know that the >>> sequence numbering is invalid (e.g., because of a catastrophic server >>> failure). In these cases, the entity that discovers the problem >>> SHOULD return a roster version of zero (in the case of the server) or >>> request a roster version of zero (in the case of the client). >>> >>> Peter >>> >> >> That doesn't seem very clear to me. And what if the roster was already >> modified with another client? I think that better formulation would be >> something like: >> >> If client announces it's version number to be bigger than the >> version of currently server-side stored roster (for example because a >> catastrophic server failure erased all roster information), the server >> MUST return the whole current roster as if client announced it's >> version to be zero, thus bootstrapping client's local cache. > > Something like that is good for the case when the client sends a roster > request with a version number greater than what the server has on hand.
That's the general idea. > But are there other cases of corrupted / invalid sequence numbering on > server side? Or do we say that in such cases the server needs to in > essence reset its sequence number back to zero? > I the server's database gets corrupted or lost, it doesn't know the correct roster for that sequence number anyway, so it is pretty implicit to revert it to the last known uncorrupted version (if any exists.. backup for example? does not necessarily need to be zero). But it doesn't hurt to make it explicit, too. There could be another problem, though. If the roster got reverted, some client could update it up to the original sequence number or further. Then if some client that wasn't used for long time came online, it could receive wrong updates. Is such scenario worth attention? I don't know how often could something like that happen. The only way to fix it (I can think of) would be including some identifier of roster (another number?) that server would have to reset in case of any failure/reverting. The client would then send requests based on both roster's ID and sequence number. But I don't like the idea much.
