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

[Bob Shaver]

> > > But I'd like to suggest to use larger variables for the retransmission
> > > time. Why not use u_long instead of u_short?
> >
> > That would not fix it, because it may still receive a value of 0 after
> > approx. 49 days.
>
> Indeed. Even if a retransmission after 49 days is realy realy unlikely
> this is not clean code either.

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.