do not delay TCP acks (Ed Swierk)

git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@1882 c046a42c-6fe2-441c-8c8c-71466251a162
This commit is contained in:
bellard 2006-05-01 11:18:01 +00:00
parent 773f2cdd3c
commit 4f552e3b9a

View File

@ -580,28 +580,11 @@ findso:
* congestion avoidance sender won't send more until * congestion avoidance sender won't send more until
* he gets an ACK. * he gets an ACK.
* *
* Here are 3 interpretations of what should happen. * It is better to not delay acks at all to maximize
* The best (for me) is to delay-ack everything except * TCP throughput. See RFC 2581.
* if it's a one-byte packet containing an ESC
* (this means it's an arrow key (or similar) sent using
* Nagel, hence there will be no echo)
* The first of these is the original, the second is the
* middle ground between the other 2
*/ */
/* if (((unsigned)ti->ti_len < tp->t_maxseg)) { tp->t_flags |= TF_ACKNOW;
*/ tcp_output(tp);
/* if (((unsigned)ti->ti_len < tp->t_maxseg &&
* (so->so_iptos & IPTOS_LOWDELAY) == 0) ||
* ((so->so_iptos & IPTOS_LOWDELAY) &&
* ((struct tcpiphdr_2 *)ti)->first_char == (char)27)) {
*/
if ((unsigned)ti->ti_len == 1 &&
((struct tcpiphdr_2 *)ti)->first_char == (char)27) {
tp->t_flags |= TF_ACKNOW;
tcp_output(tp);
} else {
tp->t_flags |= TF_DELACK;
}
return; return;
} }
} /* header prediction */ } /* header prediction */