[Standards-JIG] Synchronization points

Dave Cridland dave at cridland.net
Mon May 1 13:15:58 UTC 2006


On Mon May  1 11:12:59 2006, Bruce Campbell wrote:
> 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:
> 
> 
Well, I was assuming this would be a negotiated stream feature, so 
there's no idea of sending extra attributes anyway.


> 	Either it is hop-by-hop, or end-to-end.  It cannot be both without
> 	introducing two seperate attributes.

end-to-end is a different issue, and a much more complex one. Besides 
which, you need hop-by-hop reliability to get end-to-end receipts and 
disposition notifications to work reliably anyway. So while I agree 
with the point, I don't think it's an issue against this proposal, 
nor any other hop-by-hop reliability mechanism.


> and
> 	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).
> 
> 
Yes, but by increasing each stanza marginally, it's a lot less than 
increasing the number of stanzas, and worse, packets, which the ACK 
proposals are doing. So yes, it's certainly increasing data transfer, 
but by less than the alternative proposals.

In real figures, using a sequence number means an addition of around 
18 octets max per stanza - 10 for the number, 2 for quotes, 1 for 
'=', and 5 for a three-octet attribute and a one-octet namespace 
prefix. This could be elided by assuming that the current sequence 
value was simply the count of all stanzas, but I suspect it's easier 
to have it explicit. (It saves rules for dealing with TLS and SASL 
transitions.)

For any ACK-every-stanza mechanism, you're generally going to add 
34-40 octets for the extra packet headers, before the ACK stanza 
itself. So whether this is a whack or a stanza-ack doesn't matter a 
great deal, it's still going to cost double.

> 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"/>
> 
> 
Okay, leaving out the discussion of whether using <presence/> stanzas 
for this is a good idea (I would have thought that <message/> or an 
entirely new stanza might be better):

1) There's no point in sending the count. By the time the receiver 
gets the stanza, it knows the count - TCP does that much reliability 
perfectly well.

2) What are sent/last? I'm probably missing something, but I assumed 
the intent was to send "sent" as the current time, and "last" as when 
the last sync stanza was received, but that doesn't make sense when I 
stopped to think about it.


> 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).
> 
> 
No, it can't be done end-to-end, can it? I didn't think there was any 
method by which one endpoint could know how many stanzas had been 
transmitted to another in the other's current session. I can envisage 
servers performing presence damping, for instance, and even without 
that, I don't think it's possible, because of <presence/> and sync 
stanzas crossing on the wire.


> Note that this would simply provide detection of missing stanzas.  
> What clients do with the knowledge is a seperate issue.

Not for hop-by-hop, it isn't. For hop-by-hop, when you know that 
stanzas are not getting through, it's "drop the TCP connection, 
reconnect, resend stanzas that weren't received. If reconnection 
fails, notify the user". Whichever mechanism people go for, it's the 
same post-fail activity.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw



More information about the Standards mailing list