On Thu, 10 May 2001, jayanth wrote:
> I would like to back out the DELAY_ACK macro changes for now. The
> ttcp code behavior has changed because of the addition of the
> DELAY_ACK macro.
>
> The macro is forcing the ttcp code to send an immediate SYN, ACK
> for an initial ttcp segment which has the SYN/FIN/PSH flag set.
> Instead the SYN,ACK should be delayed such that next segment
> should be SYN/FIN/PSH from the server side.
I'm hesitant to comment, because I don't really have a patch :-) but
I'll give it a whirl anyway.
Thing is, delack is still broken. It just isn't nearly as broken now
as it was before the patch. I'm pretty sure what you are seeing now,
worked before only because of the brokenness. The way to go here is
to fix this problem. Besides, if you back out the latest delack
change, ttcp will be affected by the old delack problems anyway.
I don't have a testbed for ttcp, so I'm flying blind, but how about
where you wrote:
> if (DELAY_ACK(tp) && (tp->t_flags & TF_NEEDSYN))
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> At this point the DELAY_ACK macro returns false because there is a
> callout_pending(). Hence the TF_ACKNOW will be set.
If the new ttcp SYN,ACKs *always* get delayed, having something like:
if ( (DELAY_ACK(tp) || this_is_a_ttcp_connection) &&
(tp->t_flags & TF_NEEDSYN))
- or -
if ( tcp_delack_enabled &&
(!callout_pending(...) || this_is_a_ttcp_connection) &&
(tp->t_flags & TF_NEEDSYN))
...depending on what The Right Thing is when tcp_delack_enabled = 0.
I don't know ttcp, so of course "this_is_a_ttcp_connection" should be
replaced with the corresponding boolean.
-Paul.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
