THIER@ORCAD2.dnet.ge.com (03/30/91)
Some time back, I posted a query regarding determination of socket status,
once alerted to socket state changes via SIGIO and/or SELECT. Based on
the replies, I've implemented a SIGIO handler that works, somewhat. My
handler implements the following logic: (sockets are set non-blocking).
SIGIO Occurs.
Execute SELECT for all known data sockets. (I keep a list).
For all data sockets indicating activity:
Execute a RECV.
If -1 returned, raise exception (this is Ada code, by the way).
If 0 bytes received, do nothing. (I assume some sort of
socket opening/closing activity is occurring; I'm not
aware of any other conclusions I can draw with regard
to data sockets).
If > 0 bytes received, deliver data to message-management
task.
The message management task keeps track of message
boundaries. An embedded message header provides it with
a start-of-message marker, message length and whether
the sender wants to keep the connection open for further
traffic or not. If the connection is not to be retained and
the message has been received in full, the data socket is
closed and taken off the list. I don't currently execute
SHUTDOWNs on either end of the transfer.
Endif;
End Data Socket Processing.
Execute SELECT for all connection (LISTENing) sockets. (Another list).
For all connection sockets indicating activity:
Execute ACCEPT.
If -1 returned and errno = EWOULDBLOCK, do nothing (again, here I
assume that something other than a connection request is
taking place).
Elseif -1 returned and errno = something else, raise exception.
Else, assume valid connection requested and accepted. Add new
data socket descriptor to list.
Endif;
End Connection Socket Processing.
End SIGIO handler.
Now to my problem. I'm running a test case where I create one connection
socket, backlog set to 5. A sender program loops, creating a socket,
connecting to the receiver, sending one message (570 bytes), and closing.
This mostly works, but over time, some data sockets, with data sitting in
their input queues, are going unrecognized by my software. They just sit
there in CLOSE_WAIT (transmitting socket in FIN_WAIT_2), with the correct
octet count in their queues. I continue to get SIGIOs, processing other
connections and transfers. The one obvious possibility is that my data
socket list is being mismanaged, and thus I'm simply not setting up the mask
correctly prior to the SELECT call. I'm checking into this. My question is
this: Have I missed something in my basic logic? Are there other
specific conditions I've failed to test for? Most importantly, are there
any condtions under which a data socket, with data sitting in its input
queue, will NOT indicate activity on a SELECT call (assuming its mask bit
is properly set)? Thanks in advance.
p.s. I'd also appreciate any enlightenment on shutdown strategies. Right
now I just do closes.
John E. Thier
GE Defense Systems Division
Pittsfield MA.
thier@orcad2.dnet.ge.com