[Standards-JIG] Re: WHACK

Matthew Wild mwild1+jig at gmail.com
Wed Apr 26 23:24:27 UTC 2006


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.

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