[En-Nut-Discussion] NutTcpAccept() timeout
don at led.com.au
Thu Jul 6 10:47:49 CEST 2006
Harald Kipp wrote:
> 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;
>> 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 ;-)
More information about the En-Nut-Discussion