Hi All,
I want to know if, for connection which TCP detects as timeout
occured , does it try to send FIN packets/RST packets after detecting
so. Or it simply discards everything about that conn and conn no more
exists from its point of view.If it sends FIN packets or so, does it
again wait for complete timeout to occur before giving up even though
it knows the connection timeout has already occured for this
connection ??


--Rohit

Rohit <will.u.tellmemore@gmail.com> writes:
> I want to know if, for connection which TCP detects as timeout
> occured , does it try to send FIN packets/RST packets after detecting
> so. Or it simply discards everything about that conn and conn no more
> exists from its point of view.If it sends FIN packets or so, does it
> again wait for complete timeout to occur before giving up even though
> it knows the connection timeout has already occured for this
> connection ??
>

Any reasonable TCP stack sends RST segment after final
re-transmission timeout. Socket is closed after that. There is
no point to expect that FIN handshake would work after
multiple unsuccesful retransmissions of previous segment.

-ilkka

Ilkka Oksanen <ilkkao@omppu.modeemi.cs.tut.fi> wrote:
> Any reasonable TCP stack sends RST segment after final
> re-transmission timeout. Socket is closed after that. There
> is no point to expect that FIN handshake would work after
> multiple unsuccesful retransmissions of previous segment.

Well, the RST isn't necessarily any more likely to get there than the
FIN, but if it does, it does communicate the "right" message, which is
that the connection is toast.

Especially if the RST is from a stack which actually "extends" the RST
segment with some ASCII for the abort reason Of course one only
sees that with a packet sniffer...

rick jones
--
Process shall set you free from the need for rational thought.
these opinions are mine, all mine; HP might not want them anyway...
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

In article <fc6kfg$12h$1@usenet01.boi.hp.com>,
Rick Jones <rick.jones2@hp.com> wrote:

> Ilkka Oksanen <ilkkao@omppu.modeemi.cs.tut.fi> wrote:
> > Any reasonable TCP stack sends RST segment after final
> > re-transmission timeout. Socket is closed after that. There
> > is no point to expect that FIN handshake would work after
> > multiple unsuccesful retransmissions of previous segment.
>
> Well, the RST isn't necessarily any more likely to get there than the
> FIN, but if it does, it does communicate the "right" message, which is
> that the connection is toast.

The problem could be in the reverse direction. So the FIN or RST would
reach the other end, and the failure could be with the ACKs. Since RST
doesn't require an ACK, it seems like the correct way to let the other
end know that the connection is failing. If the other end hasn't been
trying to send any application data, it would never realize it (because
it's not sending anything that requires ACKs).

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***