[En-Nut-Discussion] NutTcpConnect() with timeout

[Henrik Maier]

On 26/09/2013 9:42 PM, Harald Kipp wrote:
> Not as easy to solve as it may look first.
>
> The connect initiates the SYN handshake in the background thread of the
> TCP state machine. The state machine decides, if the host is reachable
> or not.
>
> Returning from NutTcpStateActiveOpenEvent() without informing the state
> machine may introduce unforeseen race conditions.
>
> It may work with Henrik's application, but at least needs extensive
> testing before other "creative" application programmers run into
> unexpected trouble.

Now that you mention it, I have one case were we experience strange 
lockups (after about a 10 days) with a firmware which is using the 
time-out. It never occurred to me that this could be a contributing factor.

> One thing that I'm missing in Henrik's patch is, that the application
> has no chance to determine the cause of the error. I'd suggest to set
> ETIMEDOUT to distinguish this with EHOSTUNREACH set by the state machine.

Of course this should be added then.

>
> A minor confusion is, that it Henrik uses the _read_ time out. So far,
> we use the read time out value to define the accept() time out. Makes
> sense to me, as we are waiting for external activity. But isn't
> connect() the opposite of accept()? Shouldn't we use the write time out
> here instead?

I usually have both time-outs set to the same value any way and you are 
correct, connect is more like a write (active) so we better should use 
the write time-out.

Henrik