[Standards-JIG] Synchronization points

Bruce Campbell 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
 	all/most stanzas).

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.

   Bruce Campbell

More information about the Standards mailing list