art@dinorah.wustl.edu (Arthur B. Smith) (05/18/89)
Hello all!
This may be old hat to y'all, but it's new hat to me, and probably
to some others on these groups, so here goes.
I've been playing with internet domain (AF_INET) stream type
(SOCK_STREAM) sockets under Ultrix 3.0, and have found that they
behave quite a bit differently than (any of) the (conflicting)
documentation would indicate. The results I am about to describe come
from running two test programs, connector.c and listener.c which,
along with a typescript showing their use and results, are available
from dinorah.wustl.edu (128.252.118.101) via public ftp (for those who
are interested).
The documentation for the listen/connect/accept set of system calls
indicates that listen(2)'s second argument specifies the size of the
_queue_ for connections awaiting accepts, with an upper limit of five.
The man page for listen(2) (which DEC says I should believe) says that
if this queue overflows, the connect will fail with an error of
ECONNREFUSED. The Interprocess Communication Primer in the
Supplementary Documents (which DEC says I should not believe) says
that if the queue overflows, the request will be quietly ignored
(explicitly not sending ECONNREFUSED). Also, accept(2) is described
as a blocking call, but nowhere is connect(2) described as blocking,
although it is indicated that it may time out.
The actual behavior appears to be that
1) The "queue" is, in fact, a _stack_, so that if the server is busy
early connections may occur long after later connections, if at all.
2) The size of the "queue" (stack) is 8, even if you request a size of
5 with listen(2).
3) Once the server's "queue" is full, connect(2) blocks the client
until either the queue empties or the connect call times out.
ECONNREFUSED is never seen by client or server.
4) The timeout on the connection, which is not documented anywhere
that I could find, is on the order of a minute (+/- 15 seconds).
5) This is an unrelated note, but something that I discovered several
weeks ago (after DEC bumped it up from customer service to engineering
which took 3 days to find this): if you don't make sure that the
sin_zero component of the sockaddr_in structure is, in fact, zero'ed
memory when calling bind(2), the call may fail with error
EADDRNOTAVAIL. Don't look for this gem in the manuals, it aint there!
I would be interested in knowing how other systems that implement
internet domain stream type sockets behave. I invite any of you to
grab these programs and try them. Send me the results (by e-mail,
please), and I will post a summary after I have enough to be
worthwhile. Bear in mind that you may have to make some alterations,
particularly in the names/locations of the *.h #include'd files.
By the time you read this, I will have submitted an SPR to DEC on this
documentation (at least) error. I wouldn't expect them to change the
behavior (there seem to be precious few at DEC who even understand
sockets, let alone those who might be willing to deviate from the 4.3
sources), but maybe the documentation will be pulled into shape "in a
future release."
Please send your responses to:
internet: art@dinorah.wustl.edu
uucp: ...!uunet!wucs1!dinorah!art
Cheers!
-art smith
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
``I used to be disgusted, now I'm just amused.''
-- it aint true, but it helps to repeat that over and over.