[En-Nut-Discussion] NutTcpAccept() timeout

[Don Ingram]

Harald Kipp wrote:
> Don,
> 
> IMHO I never really agree to a timeout requirement for connect()
> or accept(). Anyway, I agree that there may be specific reasons
> for implementing this.
> 
> If you don't care modifying the TCP stack, you may follow a previous
> post from Henrik Maier:
> 
>> NutTcpAccept() does currently not honour any socket time-outs. It 
>> might be useful for applications to perform some error management in 
>> case no server connects within a given time.
>>
>> I propose to change tcpsm.c so NutTcpAccept honours the read time-out.
>> In NutTcpStatePassiveOpenEvent change:
>>
>>     NutEventWait(&sock->so_pc_tq, 0);
>>     return 0;
>>
>> to:
>>     return NutEventWait(&sock->so_pc_tq, sock->so_read_to);
> 
> If I'm the only one with concerns, I can add it. I still think
> that it is useless, not required and not following the standard,
> but actually it won't hurt either.
> 

Harald,  I don't know any better ;-) but I'm with Henrik on this issue.

The NutTcpAccept() becomes a bit of a black hole.  I would like complete control 
over the thread so that if the operation doesn't complete within a given period 
I can restart it or take a different path.  As stated earlier, I can then also 
be sure that the thread is still alive.

  At present I still have a problem with units freezing after 8 hrs or so on a 
busy network. I suspect a stack issue as the CAN128 stacks are tight due to the 
internal SRAM location requirement.  Given my rather thin enut experience to 
date I am looking for the problem in my side of the code ;-)


-- 
Cheers

Don