> > > Btw: can the aplication somehow ask the tcp/ip stack what was
> >actualy acked?
> >> (ie. how many bytes were acked).
> >no, but it's not necessarily a useful number anyhow -- because it's
> >possible that the remote end ACKd bytes but the ACK never arrives. so you
> >can get into a situation where the remote application has the entire
> >message but the local application doesn't know. the only way to solve
> >this is above the TCP layer. (message duplicate elimination using an
> >unique id.)
> No, because if the ACK doesn't reach the sending machine, the sender
> will retry the data until it does get an ACK.
if the network goes down in between, the sender may never get the ACK.
the sender will see a timeout eventually. the receiver may already be
done with the connection and closed it and never see the error. if it
were a protocol such as SMTP then the sender would retry later, and the
result would be a duplicate message. (which you can eliminate above the
TCP layer using unique ids.)
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/