<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">Hi Yan,<br><br>Thanks for your suggestion . I am familiar with iperf but the issue with us that it is a prod network and it is advisable for me not to pump data on the network . Will try to the experiment between two desktops connected by a cross over cable. <br><br>What I was trying earlier was that I started FTP server on one end and connected to the server from the client side. <br><br> $ ftp 10.66.X.X<br>Connected to 10.66.X.X<br>220 (vsFTPd 2.2.2)<br>Name (10.66.74.141:zama): anonymous<br>331 Please specify the password.<br>Password:<br>230 Login successful.<br>Remote system type is UNIX.<br>Using binary mode to transfer files.<br><br><br>After that I disconnected the network cable from the server and was monitoring the status of the connection on the client side .<br>The status of the connection was like this before and after
disconnecting the network cable. <br><br>---<br>$ for i in {1..1000} ; do netstat -at | egrep "ftp" ; date ; sleep 60 ; done<br>tcp 0 0 edgebeauty.c:50179 shopfrobsoon.c:ftp ESTABLISHED <br>Wed Feb 23 11:47:53 IST 2011<br><br>tcp 0 0 edgebeauty.c:50179 shopfrobsoon.c:ftp ESTABLISHED <br>Wed Feb 23 11:48:53 IST 2011<br>tcp 0 0 edgebeauty.c:50179 shopfrobsoon.c:ftp ESTABLISHED <br>Wed Feb 23 11:49:53 IST 2011<br>...<br>...<br>Wed Feb 23 12:14:03 IST 2011<br>tcp 0 0 edgebeauty.c:50179 shopfrobsoon.c:ftp ESTABLISHED <br>Wed Feb 23 12:15:03 IST 2011<br>===<br><br>If we see that the time is more than 25 minutes when the server went down and the client has
still maintained the connection in established state. <br><br>My understanding is that the client should close the connection after TCP restarsmit timeout happens or my understanding is wrong. <br><br>Please clarify . <br><br>--Zaman<br><br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"><div class="plainMail"><br>Message: 2<br>Date: Tue, 22 Feb 2011 09:55:13 -0500<br>From: Yan Cai <<a ymailto="mailto:ycai@ecs.umass.edu" href="/mc/compose?to=ycai@ecs.umass.edu">ycai@ecs.umass.edu</a>><br>Subject: Re: [e2e] query on behaviour of tcp_keepalive and tcp<br> retransmit on Linux based systems<br>To: <a ymailto="mailto:end2end-interest@postel.org" href="/mc/compose?to=end2end-interest@postel.org">end2end-interest@postel.org</a><br>Message-ID: <<a ymailto="mailto:4D63CE50.8050606@ecs.umass.edu"
href="/mc/compose?to=4D63CE50.8050606@ecs.umass.edu">4D63CE50.8050606@ecs.umass.edu</a>><br>Content-Type: text/plain; charset="iso-8859-1"<br><br>Hi<br><br>According to your description, the expected behavior should be as follows.<br>At the beginning senders at one side can send data to the receivers at <br>the other side, and the receivers can receive data without any problem. <br>When some of the receivers become off-line, the affected senders should <br>no long receive positive acknowledgments, therefore, lowering their <br>congestion windows (i.e., sending rate). Since in your case the receiver <br>is off forever, some senders should further experience timeout events. <br>After a few timeouts, the sender should CLOSE this connection itself.<br><br>As far as I know, the whole procedure above should be automatically <br>invoked in the sender side. This is how TCP (sender) handles exceptions.<br><br>My suggestion is that you run a simple experiment
on your side to see if <br>TCP in your machine can work that way. The test can be done using i-perf <br>to send a long long live TCP flow, and then take off the receiver in the <br>middle of the transmission. The connection is expected to be closed very <br>soon after the receiver is off.<br><br>Hope it helpful.<br>Yan<br>On 2/22/2011 4:24 AM, Zama Ques wrote:<br>> We need some clarifications on TCP_keepalive . We are facing some <br>> issues on our Prod servers related to TCP functionality .<br>><br>> The issue is like this.<br>><br>> We have some machines at one end sending data in real time to another <br>> group of machines on the other hand . Now due to some hardware issues <br>> on the other hand , some of the machines becomes unresponsive/crashes. <br>> The client system which pumps data never came to know that the server <br>> went unresponsive . The connection remains in<br>> ESTABLISHED state and
the client always tries to send data thinking <br>> that the connection is alive because of which we are seeing backlog on <br>> client sides.<br>><br>> Our understanding is like this on how TCP will handle the connection.<br>><br>><br>> Q 1) Since the server went down , the client will try to the <br>> retransmit the data until it times out. What is the behavior of TCP <br>> after the timeout? Need clarification on<br>> the following things.<br>> a) Will the kernel will close the established connection after the <br>> timeout . Looks like no in our case as we still see the connection <br>> still in ESTABLISHED state after around more<br>> than 2 hours.<br>> b) Are there any kernel parameters which decides the when the client <br>> is timeout after retransmission fails. What is the behavior of TCP <br>> after the client retransmission timeouts.<br>><br>><br>> Q 2 ) There is something
called tcp_keepalive which if implemented in <br>> the kernel , by default it's there and comes to be around 2 hrs 2 <br>> minsutes , i think , the client will send some TCP probes after the <br>> keepalive time ineterval and if it cannot reach the server , then the <br>> established connection in the client side will be closed by the kernel <br>> . This is my understanding. But I can see that the connection still <br>> remains in established after the tcp_keepalive time . We waited for <br>> around 2 hrs 30 minutes but the connection remains in established <br>> state only. Tried reducing the keepalive time to be around 10 minutes <br>> , but the connection remains in ESTABLISHED state in client side .<br>><br>><br>> Where I went wrong .Please clarify my doubts raised above . What <br>> should we do to resolve the problem we are seeing above . Any help <br>> will be highly appreciated as we are
going through a hard time to <br>> resolve the issue .<br>><br>> Thanks in Advance<br>><br>><br><br>-------------- next part --------------<br>An HTML attachment was scrubbed...<br>URL: <a href="http://mailman.postel.org/pipermail/end2end-interest/attachments/20110222/50be8540/attachment-0001.html" target="_blank">http://mailman.postel.org/pipermail/end2end-interest/attachments/20110222/50be8540/attachment-0001.html</a><br><br>------------------------------<br><br>_______________________________________________<br>end2end-interest mailing list<br><a ymailto="mailto:end2end-interest@postel.org" href="/mc/compose?to=end2end-interest@postel.org">end2end-interest@postel.org</a><br><a href="http://mailman.postel.org/mailman/listinfo/end2end-interest" target="_blank">http://mailman.postel.org/mailman/listinfo/end2end-interest</a><br><br><br>End of end2end-interest Digest, Vol 83, Issue
4<br>***********************************************<br></div></blockquote></td></tr></table><br>