[En-Nut-Discussion] NutTcpAccept() timeout
hmlists at focus-sw.com
Thu Jul 6 12:07:18 CEST 2006
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.
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.
> En-Nut-Discussion mailing list
> En-Nut-Discussion at egnite.de
More information about the En-Nut-Discussion