[Standards-JIG] Re: WHACK

Michal vorner Vaner michal.vaner at kdemail.net
Wed Apr 26 17:56:28 UTC 2006


On Wed, Apr 26, 2006 at 10:56:35PM +0530, 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.

Any permanent connection has this issue. If it dies, there is no way how
you can still transmit the data. The only way to get around this is to
poll, means you make a connection, get messages and close it. The
connection is short-term, therefore low probability of dying and if it
dies, you can easilly asume it did not work at all and try it again.

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

Well, if you call stanzas packets than yes. Real network packets can get
lost (TCP is designed to survive on 30% packet losses) and the TCP takes 
care of them automatically - if it can.

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

Well, yes, if you want to ensure that someone received something for
sure, then you can easilly ask him. This is to supress the usual
emarasments of type 'hey, I sent you 30 messages and you did nit
respond, you just disappeared after a while', 'did you look on that web
I sent you? - um, what web? :-O'.

> If the server's and client's already use whitespace pings , I really 
> dont see what can be gained by whacks.

Well, with whings, you detect the death to drop it by server and keep it
forever. However, the timeout on the tcp level is really big (tested on
a real, quite used server, it was 15 minutes). Therefore, server lived
in the idea the socket is living, he sent sometimes a whing, but as it
does not request the client to respond anyhow, it did not receive
anything. So the server was sending more and more stanzas into the
socket, that was retransmitting and retransmitting. After the 15
minutes, the kernel closed the connection and reported an error to the
server as it was lost. But now, how can the poor server know, what of
the data it was sending were transfered and what data died with the
socket.

If you do not believe, try it yourself. Ask someone to help you, log in,
unplug your connection, hard-reset your computer or whatever that would
mean your server does not get the closing packet and ask after the test,
how long you was still online and that the messages did not arrive in
the time.

(note: killing the client wont help, the system would close the socket
automatically).

This means, if your computer crashes and you do not care to reboot it
and login again to replace the old connection, you loose 15 minutes of
messages which just disappeared. However, in theese 15 minutes, you are
still marked as online and the other people just think you do not
respond them and expect you to read the messages somewhen.

If the client turns this on, server can detect these things:
1) client did not ack me last 5 stanzas and it is a minute now.
Therefore, it is retransmiting and it is dead. So I close it now and
mark him as offline.

2) client did not ack me these 5 messages. I know these were 5 messages
and I still have them, because I delete them when they are acked. So I
can report an error or save them to offline storage.

Therefore, the messages are not lost and the server retransmits them on
the next login just as any other offline message. This counts to client
crash on the processing of the message as well, where the connection is
closed by the OS automatically, but the messages are not showed to user.

The most problematic part is on the last hop. If my connection is lost,
I can expect something odd, including my message got lost. Servers are
usually on a better connection, so they do not lose the connection so
often. But with usual connection to internet (from modems, WiFi, GPRS,
whatever), it sometimes happen you lose the connection. And the one who
sent you a message lives in the idea he sent the message and did not
get any error, therefore anything should be alright.

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

-- 

NAT should extinkt like dinosaurs did.

Michal "vorner" Vaner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20060426/4c655bee/attachment.sig>


More information about the Standards mailing list