lkml.org 
[lkml]   [1996]   [Apr]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
SubjectRe: 1.3.87 broken tcp ?

Ok, does this small patch help 1.3.87? I'm just reversing one of the
patches (and one that might well result in the behaviour you see).

Linus

-----
diff -u --recursive --new-file v1.3.87/linux/net/ipv4/tcp_input.c linux/net/ipv4/tcp_input.c
--- v1.3.87/linux/net/ipv4/tcp_input.c Fri Apr 12 15:52:12 1996
+++ linux/net/ipv4/tcp_input.c Sat Apr 13 10:15:18 1996
@@ -172,26 +172,15 @@
tcp_send_reset(sk->saddr,sk->daddr,th,sk->prot,NULL,dev, sk->ip_tos,sk->ip_ttl);
return;
}
-
- /*
- * We got out of sequence data.
- * This turns out to be tricky. If the packet ends at the
- * edge of the window, then we MUST ack the packet,
- * otherwise a lost ACK packet can stall the TCP.
- * We deal with this case in tcp_queue().
- * On the other hand, if the packet is further to the
- * left of the window, then we are looking a retransmitted
- * packet. If we ACK it we can get into a situation that
- * will later induce a fast retransmit of another packet.
- * This can end up eating up half our bandwidth.
- */
-
- /* This case is NOT supposed to be able
- * to happen. Test for it?
- */
- if (sk->acked_seq == end_seq)
- printk("Impossible out of sequence data case.\n");
- return;
+
+ /*
+ * 4.3reno machines look for these kind of acks so they can do fast
+ * recovery. Three identical 'old' acks lets it know that one frame has
+ * been lost and should be resent. Because this is before the whole window
+ * of data has timed out it can take one lost frame per window without
+ * stalling. [See Jacobson RFC1323, Stevens TCP/IP illus vol2]
+ */
+ tcp_send_ack(sk);
}

/*


\
 
 \ /
  Last update: 2005-03-22 13:37    [W:0.110 / U:1.484 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site