[Standards-JIG] Synchronization points
standards-jig at vicious.dropbear.id.au
Mon May 1 10:12:59 UTC 2006
On Mon, 1 May 2006, Justin Karneges wrote:
> I'd also like to see more serious discussion about Dave Cridland's proposal.
> I currently disagree with it, for reasons stated already, but I haven't seen
> anyone else paying attention to it. So far he's been nearly talking to
> himself in this thread, and I know how that can be. :)
Fair enough. Picking up at a suitable point in Dave's thread:
On Tue, 25 Apr 2006, Dave Cridland wrote:
> An alternative would be to introduce synchronization points, such that the
> server would inform the connecting client what the previously know
> synchronization point was on connect. (I'm assuming that whitespace pings or
> some other NOOP will handle detecting whether a suspiciously silent
> connection is actually dead).
> The simplest thing would be to add in an integer attribute on potentially
> every top-level element, such that a client simply grabs a new one (strictly
> increasing allocation), and can then know easily what was and wasn't received
> by the server.
With the idea that older clients will just ignore the 'sync' attribute on
all top-level elements as per 'if you don't recognise it, ignore it'?
It'd work, but there are two issues with it:
Either it is hop-by-hop, or end-to-end. It cannot be both without
introducing two seperate attributes.
Long-term, busy connections will be hit with a subtle increase in
traffic size (a problem with introducing any new attribute to
Rather than a seperate integer attribute on every top-level element, why
not (ab)use the '<presence/>' element for this purpose? I mean, define a
'sync' type which otherwise does not change the 'online' status, use the
existing 'from' and 'to' attributes to determine whether it is hop-by-hop
or end-to-end, re-use the 'id' field to provide a count of stanzas sent in
total, and add 'sent' and 'last' attributes for timestamping, eg:
<presence type="sync" from="thisendhop" to="otherendhop"
id="COUNT" sent="JTIME" last="JTIME"/>
Done as a stream feature that connections opt-into, it can be used as
both hop-by-hop and end-to-end, and only increases traffic to the tune of
two extra stanzas every X minutes (one each direction).
Note that this would simply provide detection of missing stanzas. What
clients do with the knowledge is a seperate issue.
More information about the Standards