|
My theory is that, since this value was 0, the close signal was getting to my application before the data was (although I'm not sure why).
Because data is buffered. When you call send() to send data it puts the data in a "send buffer", and lets your program continue. In the background, it tries to send that data over the network. If the buffer is full when you call send(), then your program will wait (or "block') until there's space in the buffer again. (Unless your socket is in non-blocking mode, of course.)
The point is, it only waits until the data is safely in the send buffer, it doesn't wait until it has been delivered.
When you close() a socket, the socket goes into "Close-wait" status. It sends the data, and the close request, to the other end. It waits for the other end to process the data and send back a FIN datagram, and then it exits close-wait status.
If you have the timeout for close-wait status set to 0, then what? It doesn't wait for the other side at all, it simply throws away the data when you issue the close() call.
The workaround (I think I suggested this earlier) is to set a linger value on the socket. Then, close() becomes a blocking operation. The program will actually wait until the send buffer is empty (or the linger timeout expires) before closing the socket.
Of course, in this case, it's not your RPG program, but the Java one, that would have to specify a linger value.
Or, of course, you could set the close wait timeout to a long enough value to ensure that the data has a chance to arrive. (Which is what you did.) the problem with this is that you can't always control what a customer sets his TCP settings to...
As I suggested earlier, I don't like to rely on either the close-wait or the linger values. Instead, send some sort of "I'm done" code when you're done sending the data, and receive back an "I got it" code from the other side. After that, it doesn't matter who closes first or what data gets dropped when they close, since they both agreed that the data has arrived. Then the linger and close-wait timeout values are irrelevant, and you don't have to police the way that a customer sets up his TCP stack! :)
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
