Hello, I had a TCP related question. I wrote a simple TCP based server (infinite loop) on Solaris 10 u5 which sleeps for 1 sec before reading data. Then I wrote a simple client which which sends data continuously, I found that after sending some data my client was getting blocked as it could not send more data. I used "snoop" to discover that the server side TCP had sent "WIN=0". Then I exited the client by using "CTRL +C". Question We all know that if the client exits then it should trigger close and flush buffer''s. But the connection was still in "ESTABLISHED" state. And after few seconds the data transmission continued even without the client program being alive. Why ? So does it mean that even if my program exits the data will be sent ? Regards Vikas -- This message posted from opensolaris.org
Vikas, VIKAS MR wrote:> Hello, > > I had a TCP related question. I wrote a simple TCP based server (infinite loop)> on Solaris 10 u5 which sleeps for 1 sec before reading data. Then I wrote a > simple client which which sends data continuously, I found that after sending > some data my client was getting blocked as it could not send more data.> I used "snoop" to discover that the server side TCP had sent "WIN=0". > Then I exited the client by using "CTRL +C".Yes, the server send a window closed because there was already max per socket data pending to be read.> > Question > We all know that if the client exits then it should trigger close and flush buffer''s. > But the connection was still in "ESTABLISHED" state. And after few seconds the data > transmission continued even without the client program being alive. Why ? > So does it mean that even if my program exits the data will be sent ?For how long was the client connection in established state? Keep in mind that the client probably still wrote a bunch of data to the socket before you CTRL-C''d it. That data was already sitting on tcp xmit queue and can still be transmitted in between if server had opened up the window. And even though your client has exited, the TCP state machine for that socket needs to go through FIN-ACK sequence and complete the close. Cheers, Sunay
Thanks for the reply, Yes, as you say that there was data sitting in the TCP xmit queue before the client exited. The connection was open for a long time (more than half and hour). But always I had the problem that if the server dies in between then the client never knows if the data transmission was successful. So we need to implement our own handshake over and above the TCP handshake. How can we ensure that the client is notified if the data was not successful ? Here will the SO_LINGER option work well ? -- This message posted from opensolaris.org
VIKAS MR writes:> Yes, as you say that there was data sitting in the TCP xmit queue before the client exited. The connection was open for a long time (more than half and hour). > > But always I had the problem that if the server dies in between then the client never knows if the data transmission was successful. So we need to implement our own handshake over and above the TCP handshake. > > How can we ensure that the client is notified if the data was not successful ? Here will the SO_LINGER option work well ?It depends on your application. One common way to do this is to use "shutdown(fd, SHUT_WR);" on the client to cause TCP to send FIN. After the server has read the last byte from the client, it will get a zero-length read (end-of-file indication), and it can then write its last data and close the connection. The client, after doing the shutdown, then waits in a "read(fd, ...);" call to wait for that last data from the server. When it gets an end-of-file, it knows that the server has closed the connection. To make things more robust, the server can set the linger time, and its close() call will then block until the data are acknowledged by the client. There are other ways to hand these cases, but they depend on the nature of your application -- what sorts of messages the client and server send to each other, how and when the messages are sent, and what failures you need to protect against. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677