[En-Nut-Discussion] NutTcpAccept() timeout
hmlists at focus-sw.com
Fri Jul 21 01:51:12 CEST 2006
At last the discussion started...
> If you go with the ioctl option, I would suggest using two constants:
> SO_CONNECT_TIMEO and SO_ACCEPT_TIMEO. It's some 2 fields more to the
There is no need for two separate constants and fields. Accept and
connect are never used together. Either you implement a server or a
client and then use either accept or connect. Refer to Brett's case #2.
By the way the BSD API uses the receive t/o value for connect and
accept, so there is no different socket option for this phase. This
would save us the additional field in the socket structure.
As memory is precious, I personally like to avoid an additional field
and would opt to change NutTcpConnect and NutTcpAccept to honour the
RCVTIMEO socket option.
This has the following affect on existing applications:
a) Applications not using any time-out are _not_ affected as the default
setting would be infinite time-out. This applies to the samples and
probably to most applications anyway.
b) Applications using RCVTIMEO could be affected depending when they set
the socket option. If they set the option AFTER the NutTcpConnect they
are not affected. If they set it BEFORE, then NutTcpAccept may return
early. Further behaviour depends if the application handles the return
code or not. In case it does not handle the return code the application
would proceed and fail at some point later as the socket is not connected.
This "BSD style" t/o socket option approach has the benefit that the API
behaves more like the BSD API and what people would expect (as usual
nobody reads the manual and expects things to work as usual) and it
would not consume any additional memory resources.
Yes it might break some existing applications...
So I opt for Brett's case #1.
More information about the En-Nut-Discussion