On Jul 5, 2006, at 4:22 PM, Justin T. Gibbs wrote:
Hmm. Seems we close the window unexpectedly and the remote side
doesn't
retransmit when we open it.
Yes, interesting that. :-)
Normally the stack only sets the window size to 0 in the event of
severe congestion, it's used to tell the other side to stop sending
traffic for an interval, although the other side should retry with
zero-data-length ACK-only packets after a delay, or once your side
sends a packet opening the window.
FreeBSD's acks stop once the window is fully
open... aren't the acks supposed to retried longer? If not, shouldn't
fetch eventually see a socket close event instead of hanging forever?
RFC-793 says:
"The sending TCP must be prepared to accept from the user and send at
least one octet of new data even if the send window is zero. The
sending TCP must regularly retransmit to the receiving TCP even when
the window is zero. Two minutes is recommended for the
retransmission
interval when the window is zero. This retransmission is
essential to
guarantee that when either TCP has a zero window the re-opening of
the
window will be reliably reported to the other.
When the receiving TCP has a zero window and a segment arrives it
must
still send an acknowledgment showing its next expected sequence
number
and current window (zero)."
The fact that you aren't seeing any ACK's back from this remote
server suggests that perhaps a stateful firewall is involved which is
getting confused and/or dropping the state entry once it sees the
zero-window-size packet from your machine.
There may be something wrong on the FreeBSD side as well, of course--
the fact that it grows the window by sending nearly twenty or more
ACK packets in the span of about one millisecond without waiting for
any ACKs from the other side is pretty wacky in it's own right.
--
-Chuck
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
