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

[Alain M.]

Multiple answer...

Harald Kipp escreveu:
> May I assume that you misunderstood the function?
> The retransmission timer samples the current system tick count. Later 
> the difference between the sampled value and the current tick counter 
> value is used to decide whether a retransmission should be initiated.

Yes, I missunderstood the problem :)

 > That would not fix it, because it may still receive a value of 0 after
 > approx. 49 days.

it could be a problem for some users

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

I also believe it is a very long time, but I also believe that some user 
could write a program that doesn't have auto reconect, so it would be 
better not to have a limit, or a t least have a very big one

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

I also agree with this ;)

----------------
Ole Reinhardt escreveu:
 > Shure. I only had 32 bits in mind and thought is should be the
 > same type as NutGetMillis()

that is an important consideration !

-------
So, IMHO both:
1) use u_long
2) don't test for 0, use the queue pointer

Alain
PS: I couln'find the relevant parts in the source, so I hope that I am 
not talking nonsense (again)