Messages in this thread Patch in this message | | | Date | Sat, 13 Apr 1996 10:32:17 +0300 (EET DST) | From | Linus Torvalds <> | Subject | Re: 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); } /*
| |