[Standards-JIG] Re: WHACK

Mridul Muralidharan mridul at sun.com
Thu Apr 27 22:58:20 UTC 2006


Hi,

  Please see inline.
Thanks,
Mridul

Matthew Wild wrote:

>On 4/26/06, Mridul Muralidharan <mridul at sun.com> wrote:
>  
>
>> [snip]
>>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 ?
>>    
>>
>
>Retransmission doesn't come into it. In the client I use (and would
>like to contribute more to), Miranda, notifies the user of undelivered
>messages, and gives the option to retry in the message window.
>Retransmission is a user initiated, manual process.
>
>Reliability isn't solved, but at least it is known whether a stanza
>reached the place you sent it to... without acks it may as well be
>entering a black hole.
>
>  
>

What I mentioned is just one possible hack to get hop-by-hop acking 
working :-) (retransmission on timeout , using id'ing for ack's , etc)
But I did not want to limit it to message, thats all (as of now , I 
guess it makes sense only to it though) - it could be used for other 
stanza's which could be transmitted over the stream.
For example , a custom extension which uses message stanza's to 
communicate additional metadata between clients - not something which 
may be user generated/provided.
Would also be useful when you want to use xmpp stream for other usecases 
like as a transport for webservices (SOAP/XMPP) , etc -
You may need someway of finding out reliably whether the stanza has been 
delivered to : a) the server , b) the recipient (end to end ack would 
help) depending on the required QoS.

For a normal chat , listing the undelivered stanza content's may be 
appropriate like what you describe.

Thanks,
Mridul

>>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