[En-Nut-Discussion] NutTcpAccept() timeout

[Henrik Maier]

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.


Henrik