Re: TCP connect in Non Blocking Mode
- From: Rainer Temme <Rainer_Temme@xxxxxxxxxxxxxxxxxxxxxx>
- Date: Sat, 26 Apr 2008 18:57:01 +0200
David Schwartz wrote:
Acutally, select() poll() do NOT check for readablity but for
the ability to call read() without being blocked in the call.
Since the connection is refused by the RST, read() should
return iommediately with result -1 and errno set to ECONNREFUSED.
And select() should indicate that a read() can be called without
being blocked.
But a 'write' can be called without being blocked too, so checking for
readability is at best redundant. If the connection succeeds, it will
be writable but not readable, so checking for 'read'ability won't
detect connection success.
This is why the typical pattern is to check an asynchronous 'connect'
attempt only for writability.
Whether a socket will become readable after connect
also depends on the protocol used ... SMTP and FTP
are exaples of protocols where the serverside
will send an immediate message to the client
after successful connection.
Anyhow, my suggestion was to set the bit in the readset
as well as in the writeset. You might regard this as redundant
but (as even you had to admit) it will not harm.
By the way ... setting the bit in the exceptionset will also
not harm.
Rainer
.
- Follow-Ups:
- Re: TCP connect in Non Blocking Mode
- From: Rainer Weikusat
- Re: TCP connect in Non Blocking Mode
- References:
- TCP connect in Non Blocking Mode
- From: Prabhu
- Re: TCP connect in Non Blocking Mode
- From: Rainer Temme
- Re: TCP connect in Non Blocking Mode
- From: David Schwartz
- Re: TCP connect in Non Blocking Mode
- From: Rainer Temme
- Re: TCP connect in Non Blocking Mode
- From: David Schwartz
- TCP connect in Non Blocking Mode
- Prev by Date: Re: /dev/urandom too slow on my system
- Next by Date: Re: stack, pop, push and min in o(1)
- Previous by thread: Re: TCP connect in Non Blocking Mode
- Next by thread: Re: TCP connect in Non Blocking Mode
- Index(es):
Relevant Pages
|