[En-Nut-Discussion] Latest fix in tcpsm.c and tcpout.c

[Henrik Maier]

It probably would have been a good idea to look at the code first. Nut/OS'
TCP stack implements all of these features. Timeout times are limited and
even so the max. Number of retransmission attempts.

Henrik
http://www.proconx.com

> -----Original Message-----
> From: en-nut-discussion-bounces at egnite.de [mailto:en-nut-discussion-
> bounces at egnite.de] On Behalf Of Bob Shaver
> Sent: Tuesday, 15 April 2008 4:13 AM
> To: 'en-nut-discussion at egnite.de'
> Subject: Re: [En-Nut-Discussion] Latest fix in tcpsm.c and tcpout.c
> Disclaimer: I have not looked at the Nut/OS code to see if it implements
> any of
> the following.  It appears from the previous discussions that it does not.
> My
> apologies if I am wrong.
> 
> One thing that I think people are missing - the TCP specification calls
for
> a
> maximum number of retries (and "suggests" selecting a maximum retransmit
> timer
> value).  If the re-transmit backoff time ever reaches this upper timeout
> limit
> (chosen by the system designer), the timeout value "saturates" and never
> grows
> any larger.  If the system hits the maximum number of retries, then the
> connection **should** be closed under the assumption that the other end is
> "gone".
> 
> Continuing to retransmit over the course of several hours (much less
> several
> DAYS) without aborting the connection and attempting a new one is not what
> TCP
> was designed to do.  Instead, retry some limited number of times the close
> the
> connection.  Open a new connection and try again.  It this new connection
> hits
> the max # of retries (even during the SYN/SYNACK phase), abort it, then
> open
> yet another new connection.
> 
> Bob.
> 
> 
> 
> _______________________________________________
> http://lists.egnite.de/mailman/listinfo/en-nut-discussion