[Standards-JIG] Re: WHACK

Mridul Muralidharan mridul at sun.com
Thu Apr 27 22:48:49 UTC 2006


Hi,

  Please see inline.

Thanks for your comments.
Regards,
Mridul

Michal vorner Vaner wrote:
<snip>

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

With whitespace ack's , both 1 and 2 are not possible from what I see.
An ack packet which has explicit ack info would allow this sort of thing 
to happen.
If intention is just to detect connection drops , you just need to 
periodically send whitespace pings and expect a whitespace ping response 
back within some time (requires a server & client which adhere to this 
:-) ).
Even just sending periodic whitespace pings is enough to detect dropped 
connections within say 8 mins or so (depends on m/c tcpip config).

Thanks,
Mridul

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




More information about the Standards mailing list