Re: [lwip-users] Is connect blocking?? was :How we can set timeout in blocking socket

[Kieran Mansley]

On Fri, 2009-03-13 at 23:37 -0300, Alain M. wrote:
> I found this old message... Please see below
> 
> Kieran Mansley escreveu:
> > On Wed, 2008-12-03 at 22:15 +0800, yueyue papa wrote:
> >> I am confused
> >>  
> >>>> You can use the SO_RCVTIMEO socket option to set the recv()
> >> operation's timeout
> >> it means I could set receive timeout for receive timeout, but I could
> >> not use it for connect timeout. Am I right?
> >> So write is is not time out, 
> >> Listen is no timeout
> > 
> > That is correct.
> > 
> > listen() is not normally a blocking call anyway.
> > 
> > recv() can time out if you set SO_RCVTIMEO
> > 
> > accept() will also time out if you set SO_RCVTIMEO
> > 
> > connect() and write() would need support for SO_CONTIMEO and SO_SNDTIMEO
> > which are not implemented (yet) in lwIP.
> 
> So, is it possible that connect() and write() block and never return?

I think that eventually the stack should give up trying to retransmit
and abort the connection.  When it does this I think it should notify
the API that will similarly abort the connect() or write() operation.
However, this can take a long time - TCP is a very patient protocol.
Also, note that I've not done this myself recently, nor looked at the
code to check this is correct, so it's just "I think" and "the stack
should"!

> Is it possible to make these functions to abort setting some flag from 
> another thread, or in any other way? (I am using lwip with FreeRTOS)
> 
> My problem is that if I try to connect to a server that does not exist, 
> I need to stop trying after some time and connect to the backup server...

Sounds like you need them to timeout after a shorter (user-defined)
length of time.  i.e. you need the code referenced above which isn't
implemented yet.

Kieran