[En-Nut-Discussion] NutTcpConnect() with timeout
hmnews at proconx.com
Thu Sep 26 14:02:22 CEST 2013
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.
More information about the En-Nut-Discussion