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