[En-Nut-Discussion] NutTcpAccept() timeout

[Henrik Maier]

Hi Harald,

I can sense your strong opposition in this matter.

But there are some real-time applications and protocols in particular in 
the industrial world which require control over the timing aspect of 
every communication stage including connect and accept.

The standard BSD socket API allows doing this by making the socket 
non-blocking, calling connect() and then calling select() with a 
time-out value. A similar approach applies to accept. These are quite 
common methods for all TCP/IP based protocols which require control over 
the connection time.

If TCP/IP time-outs are supported in Nut/OS, then they should be 
complete and cover all communication phases not only read and write.

To be compatible with existing applications, these calls could be either 
implemented as overloaded "Try" version of the connect and accept call:

    NutTcpTryAccept(sock, port, waittime);
    NutTcpTryConnect(sock, ip, port, waittime)

or using ioctl and specific socket options (SO_ACCTIMEO and 
SO_CONNTIMEO) to apply time-outs to these two operations.

I actually prefer the latter option as it keeps the API lean and neat.


Henrik
http://www.proconx.com



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
> 
> _______________________________________________
> En-Nut-Discussion mailing list
> En-Nut-Discussion at egnite.de
> http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion
> 
> 
>