[Standards-JIG] Re: WHACK

Mridul Muralidharan mridul at sun.com
Wed Apr 26 22:31:08 UTC 2006


Hi all,

First off , a correction : packets -> xml stanza's , my mistake.

Secondly : the background on why I tried to condense my understanding 
w.r.t whacks -
In our impl , we are sending periodic whitespace space pings from both 
client and server side for sometime now.
Not an ack to any request , just a periodic ping to detect connection 
problems.
Until now , we are not using it to get a measure of reliability : just a 
way to keep a socket alive and detect socket timeouts.

The main question I have with periodic whack's is this :
It could be used to detect unresponsive connections - but how is this 
getting used for retransmission , reliability , etc ?
Stanza's are going to be pipelined at both server and client side 
streams - I did not really see how whack's can be used to do anything 
other than detect abnormal stream closures.
Note : you could be having intermediaries (like proxies you have 
tunneled through) - so receipt of a whack is no guarantee that all 
requests until that instant have been received at the the server.
Secondly , when we do detect a failure , how are we going to find out 
what all packets were dropped/are to be retransmitted ?

Without having a way of identifying required sent stanza's , and the ack 
mentioning these id's , I am not sure how we can achieve this sort of 
reliability.
On timeout we could retransmit the same packet again , with caveat that 
receiver should ignore duplicate receipts : we could pipeline these 
requests in-order - (borrowed from JEP124 rid design).
Ofcourse , IMHO this should be something which must be dealt with care : 
overloaded server might exhibit higher latency before responding - so 
retransmissions will just worsen it for server.

Just my thoughts ,
Thanks and Regards,
Mridul

Mridul Muralidharan wrote:

> Hi,
>
>  Just to get my thoughts in order about this discussion :
> Sending of whack's is just to get around tcp implementation issues 
> right ?
> What I mean is , there is no way to correlate which stanza's were 
> received at the server (or the client) end given that sender received 
> a whack.
> The only thing we are ensuring is that there is a high possibility 
> that all packets sent until 'x' seconds ago were received (and 
> possibly processed) by the server.
>
> So essentially ,  if you really want reliable messaging , you will 
> have to use end-to-end acknowledgment : whack's and whing's (cool 
> names btw :-) ) are just a way to keep the socket alive and detect its 
> 'death'.
>
> If the server's and client's already use whitespace pings , I really 
> dont see what can be gained by whacks.
> If I am right in my assumptions above , you dont need to whack 
> everything - only if no packet were transmitted to the sender in 
> previous 'x' seconds : this would reduce n/w usage.
>
>
> Regards,
> Mridul
>
> Peter Saint-Andre wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Chatting with Kevin Smith of the Psi project has, as usual, given me a
>> new perspective.
>>
>> There are really two things here:
>>
>> 1. Reliability
>>
>> 2. Accountability
>>
>> Everyone wants reliability: they want to know that their messages (and
>> other stanzas) will be delivered all the time. But not everyone wants
>> accountability: they don't necessarily want another party to know when
>> they received a message.
>>
>> JEP-0184 addresses the accountability issue, but if it is used for
>> reliability then it automatically includes accountability, which normal
>> users don't like.
>>
>> So what we need is a way to do acknowledgements without necessarily
>> including accountability.
>>
>> Justin's "stanza acking" proposal [1] does this, but in a rather heavy
>> fashion -- all those extra <a/> elements (seemingly top-level!), pings
>> and pongs, etc.
>>
>> Kevin mentioned to me an alternative approach, which he swears is also
>> Justin's idea -- whitespace acks (since I like fun names for things, I
>> dub these "whacks"). Whenever an entity receives a stanza, it sends one
>> whitespace character ("whack") to the immediate sender. So my previous
>> flow would be as follows:
>>
>> 1. My client sends a stanza (intended for you) to my server.
>>
>> 2. My server sends a whack to my client.
>>
>> 3. My server routes the stanza to your server.
>>
>> 4. Your server sends a whack to my server.
>>
>> 5. Your server routes the stanza to your client.
>>
>> 6. Your client sends a whack to your server.
>>
>> One nice thing about this is that it doesn't require any changes to the
>> core protocol, since entities are allowed to send whitespace between
>> stanzas (in fact whitespace pings -- whings? -- are a subset of whacks).
>>
>> Another nice thing is that it's easy to implement.
>>
>> For this to reliably add reliability to the network, everything would
>> need to support it. But that's true of stanza acking in general. You
>> could disco your conversation partners and the in-between servers to
>> know if they support it. And it's got to be something that you can't
>> turn off, it's just there.
>>
>> In fact, this has a real Jer feeling to it. It's the kind of hack he
>> would have built in at the very beginning. :-)
>>
>> Thoughts?
>>
>> /psa
>>
>> [1] http://www.jabber.org/jeps/inbox/ack.html
>>
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.1 (Darwin)
>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>>
>> iD8DBQFETo15NF1RSzyt3NURAiXZAJwP4r95EXUwLfTxcmvveIk4Hs99iQCgvX17
>> TZ1MUbITRRSSsv8/iM1XqKM=
>> =mYPv
>> -----END PGP SIGNATURE-----
>>  
>>
>




More information about the Standards mailing list