HPUX & C socket programming problem

[suranji]

We have 2 socket applications running on 2 different machines.

1. The socket server is running on HP-UX. (Version 11.0)
2. The socket client is running on SCO-UNIX (Open Server 5.0)

The scenario is as follows:
1. The client will send a request message (540 characters) to the socket server and waits for the response from the server.
2. The server will reply with a response message (540 characters) using the write( ) function.

We simulate a link failure scenario by unplugging the network cable of the client machine from the network
after the client has sent the request message to the server and before the server can
reply with a response message using the C write( ) function.

We notice the following:
1. The C write( ) function returns successfully.

QUESTION: Shouldn't the write( ) function return an error??

So we try out another method.
1. We, first,set the send buffer size to 540 (which is the size of our message) using the setsockopt function (sockfd, SOL_SOCKET, (char*)sendBufSize, 540) on the connected socket.
2. Followed by, we issue the select function on the socket to test whether it is write ready. If it is not write ready, we will assume there is a link failure. However, it always return write ready.

QUESTION: BUT how can it return write ready when the send buffer is not cleared (due to the link failure)

3. The segment for the server code is attached below for your reference.
4. The FD_ISSET always returns non zero.

n=write(sockfd, response, 540);

tv.tv_sec = 20;
tv.tv_usec = 0;
FD_ZERO(&wset);
FD_SET(sockfd, &wset);

returnVal=0;
returnVal=select(sockfd+1, NULL, &wset, NULL, &tv);

fprintf(logfd, "SExternal: after select() statement\n");
fflush(logfd);

if (returnVal >= 0) {
if (FD_ISSET(sockfd, &wset)) {
fprintf(logfd, "SExternal: write ready\n");
fflush(logfd);
} else {
fprintf(logfd, "SExternal: write not ready!!!\n");
fflush(logfd);
}
}

[rick jones]

no, the write() call should not return an error. write() completes when the data is successfully transfered to the _kernel_ there are no semantics to write() that mean the data made it to the remote system.

further, TCP detects failure after retransmission timeouts. that will take some period of time based on ndd settings. you do not necessarily want tcp to go belly-up if someone simply unplugs and reconnects a cable once and again, so even if there is a disconnect indication sent from the NIC, TCP (likely IP actually) would not necessarily say things were toast immediately. it might start tring to find another way to get the data there.