[comp.sys.hp] non-blocking_socket_questions

len@bronto.itstd.sri.com (07/30/90)

I have two questions with regarding use of the socket interface on an
HP 9000/370 running HPUX 7.0 B.  The first involves using select to
determine when a write to a socket will not block.  I have created
a socket, made it non-blocking using the FIONBIO ioctl, bound it to
and address, and connected it to another socket.  Then I call select
as follows:

FD_SET(sock, &wfds);
select(..., &wfds, ...);

Select returns and tells me that my socket is ready for writing and so
I write using sendto until I'm told that the write would block (EWOULDBLOCK).
I then go back to the select and wait until I'm told that my socket is
ready for writing again.  The problem is that select lies and tells me
that my socket is ready for writing even though it is not.  After select
tells its ok to write I call sendto write away and it tells me the write
would block.  So I go back to select and it tells me I can write.  So
I write and I'm told the write would block.  This loop repeats itself
until finally I can write but it looks to me like a form of busy wait
instead of what I want.

I have tried this with the connection I'm trying to write to going between
two HP's on the same ethernet and between two HP's on seperate ethernets
connected via a gateway (Cisco).  Select lies in both cases with the
only difference being that in the first case there are fewer passes
through the bogus wait loop since the ethernet is faster than the gateway.

Does anyone know if this is a known bug or if its the way HP intended or
if I'm setting up for non-blocking io improperly?

The second question also involves connected sockets.  I am using recvfrom
to read data from the connection.  I do not want to use recv or read.
The problem is that using recvfrom on a connected socket does not tell
me the address of the peer or sender.  Recvfrom does this on a datagram
socket.  The manual pages actually document this so the fact that it
happened was not a surprise (at least after careful reading of the man
page).

The question is why doesn't recvfrom tell me the address of the peer?
And since it does not, why does the last parameter, which when
recvfrom is called contains the address of an integer with the value
sizeof(struct sockaddr_in), remain unmodified upon return of recvfrom
even though recvfrom did not fill in the address of the peer?  I would
have thought the integer at that address would have been set to 0
to indicate that the address of the peer was not filled in.  Is there
a compelling reason such as performance to use recv for sockets which
are connected?

Any help or insight relating to these two questions would be much
appreciated.  Please respond to me directly.  If there are interesting
responses I will post a short summary.

Thanks,

Len Schlegel
len@itstd.sri.com
415-859-4630