Re: Issues with select
Re: Issues with select
- Subject: Re: Issues with select
- From: Vincent Lubet <email@hidden>
- Date: Fri, 30 Apr 2004 09:49:31 -0700
It is a misconception to believe the exception FDS is meant to report
socket errors, rather it is to report the availability of out of band
data.
If there's a error during a non-blocking connect(), both the read FDS
and write FDS are set. The error is returned by the SO_ERROR socket
option.
Vincent
On Apr 29, 2004, at 2:25 PM, Aaron Ballman wrote:
I'm going to preface this with: I know this is going to be a
forehead-smacking problem.... ;-)
The issue is, when I call connect on the loopback and a port that
doesn't exist, for some reason the bit set for WRITE is being flagged
instead of an error. The socket is in non-blocking mode, and here's
(what I think) the relevant code:
.
.
.
// Define our select sets and zero them out
fd_set read, write, errors;
FD_ZERO( &read );
FD_ZERO( &write );
FD_ZERO( &errors );
if (CanRead()) {
FD_SET( mSocket, &read );
}
if (CanWrite()) {
FD_SET( mSocket, &write );
}
FD_SET( mSocket, &errors );
// Do the select with no timeout
static struct timeval timeout = { 0, 0 }; // return immediately
long result = v_select( mSocket + 1, &read, &write, &errors, &timeout
);
if (0 == result) {
// The timeout expired, or there are no
// pending operations to do. This is
// no big deal
} else if (result > 0) {
// We selected something, so we should handle it
// appropriatly. Also make sure we still have a valid
// file descriptor, otherwise that causes the FD_*
// functions to crash.
if (-1 != mSocket and FD_ISSET( mSocket, &read )) { // read-type
operations
if (mAccepting) {
// Since we're in the accepting state, we
// should complete the accept here.
DoAccept();
} else if (!mIsConnected) {
// We're now connected! Let the user know!
mIsConnected = true;
// Be sure to flag the fact that we just connected
// so that we can fire the event when appropriate
mJustConnected = true;
} else {
// We're already connected, and so we should
// just start grabbing the data
if (not RecvToBuffer()) return;
}
}
// Check for an invalid socket descriptor at this point
// since DoAccept or RecvToBuffer may have closed the socket
// down.
if (-1 != mSocket and FD_ISSET( mSocket, &write )) { // write-type
operations
if (!mIsConnected) {
// We weren't connected yet, so let's say
// we're connected
mIsConnected = true;
// Be sure to flag that we just connected so that we
// can let the user know
mJustConnected = true;
} else {
// Writing is no longer blocked since we
// got this message from select
mWrite_blocked = false;
// Try to send some more data out
// from our buffer
SendFromBuffer();
}
}
if (-1 != mSocket and FD_ISSET( mSocket, &errors )) {
if (not mIsConnected) {
// If we're not connected, then this is (most likely)
// a problem with resolving the DNS adress.
SocketError( netDNRErr );
} else {
// Otherwise, we're not connected anymore.
SocketError( netLostConnectionErr );
}
}
} else {
// We got an error, so we should query errno and
// respond
SocketError( v_errno );
}
.
.
.
Sorry for the monster code snippet... :-/ In any event. When I call
connect on 127.0.0.1:9009, I get into this method (it's a Poll
method), and FD_ISSET( mSocket, &write ) claims that we have a writing
operation to do. I interpret this to mean that we're connected. I
was going off the understanding that an error would be flagged in
"errors", not in "write" or "read". Consequently, if I try the same
stunt with www.google.com:9009, everything works as expected (the
errors flag gets set, the write flag does not).
So, am I just misunderstanding something here, or is this a bug that I
stumbled across? I'm using OS 10.3.3...and FWIW, I'm betting it's my
problem, not the OSes. :-P
Any suggestions/enlightening statements?
~Aaron
--
In response to a stupid question I once asked: "My brain uses patterns
to format responses to your inputs, but I don't have one for that. Do
you speak German?" ~ Zola
_______________________________________________
macnetworkprog mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/macnetworkprog
Do not post admin requests to the list. They will be ignored.
_______________________________________________
macnetworkprog mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/macnetworkprog
Do not post admin requests to the list. They will be ignored.