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

[Ole Reinhardt]

Hi Harald,

> The problem was not the overflow by itself, but the fact that the 
> retransmission timer may receive a value of 0. In other parts of the 
> code a value of 0 is interpreted as "no retransmission waiting".

Ok, I see the problem :)

> > 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.

> Henrik suggested not to decide on re-transmission on the tick value but 
> on the send buffer queue pointer. IMHO, this is cleaner.

Sorry I don't know the internals of the tcp sm, but it sounds better.

> Changing the tick value from u_short to u_long would extend the 
> retransmission time, but do we really need them above 65 seconds? I 
> think that even on slow connections this is a very long time.

It is, but 65 seconds is still much less than 49 days :)

> Wouldn't it be a better solution to use u_int (uint_t if we ever manage 
> to switch to stdint), specially for 32 bitters?

Shure. I only had 32 bits in mind and thought is should be the same type
as NutGetMillis()

Bye,

Ole

-- 
 _____________________________________________________________
|                                                             |
| Embedded-IT          Hard- und Softwarelösungen             |
|                                                             |
| Ole Reinhardt        Tel. / Fax:        +49 (0)271  7420433 |
| Luisenstraße 29      Mobil:             +49 (0)177  7420433 |
| 57076 Siegen         eMail:    ole.reinhardt at embedded-it.de |
| Germany              Web:         http://www.embedded-it.de |
|                      UstID / VAT:       DE198944716         |
|_____________________________________________________________|