[jdev] tcp acknowledged sequence number

[Tijl Houtbeckers]

On Tue, 12 Oct 2004 21:31:46 +0400, Alexey Nezhdanov <snake at penza-gsm.ru>  
wrote:

> Hello. Sorry slightly offtopic question.
>
> I need to know which data is reliably delivered to the other party for my
> currently developed jabber server.
> If the client silently looses it's connection server will not notice
> it and will continue to send messages to it during all the time of tcp
> timeout.
> Currently we know this as "blackhole effect" - if you will loose  
> connection
> you will risk loose messages that will be sent to you during tcp timeout  
> time
> window.

How reliable do you want this to be? Only clients connected directly to  
your server will benefit from the technique you suggest. Most proxies will  
still experience the "blackhole" effect. That includes some SOCKS proxies,  
transparant JEP-25 proxies, GPRS APNs etc. Also don't forget that even if  
both clients talking are connected directly through a TCP socket with your  
server and one client doesn't use simulair techniques in a conversation  
messages could still end up in the "black hole".

> When time out will be hit - connection will broke so I need to know
> wich packet was delivered last and wich were just dropped by tcp/ip  
> stack to
> re-send them later when client come back online.
>
> I know that such info can be obtained from tcp's acknowledged sequence  
> number
> but I haven't found how to access it.

I think people will be more able to help you if you state on what platform  
this is on. Some platforms will definatly not provide you with this  
information. Some platform also work with an "internal" blackhole. Data  
and such is buffered before sending, and while you might get an error or  
exception when trying to send some more data, you won't know what happend  
to whatever was still in the buffer.

In the end, if you want to provide your users a reliable infrastructure, a  
Jabber protocol level solution is needed. For end-to-end this can be done  
with JEP-0022, for hop to hop (easy to implement since you have to do no  
real tracking) there is the JEP-ACK initiative which was discussed a while  
back on SJIG. Either would be more reliable than relying on the TCP layer,  
but it's still not a bad idea to implement that as well, since it will  
work with all existing clients. Just remember it'll only give you *some*  
extra reliability in *some* of the cases.