From: Willy Tarreau <w@1wt.eu>
To: David Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Subject: Re: TCP: orphans broken by RFC 2525 #2.17
Date: Mon, 27 Sep 2010 01:25:30 +0200 [thread overview]
Message-ID: <20100926232530.GK12373@1wt.eu> (raw)
In-Reply-To: <20100926.160838.246540910.davem@davemloft.net>
On Sun, Sep 26, 2010 at 04:08:38PM -0700, David Miller wrote:
> From: Willy Tarreau <w@1wt.eu>
> Date: Mon, 27 Sep 2010 00:54:40 +0200
>
> > On Sun, Sep 26, 2010 at 03:38:32PM -0700, David Miller wrote:
> >> From: Willy Tarreau <w@1wt.eu>
> >> Date: Mon, 27 Sep 2010 00:34:48 +0200
> >>
> >> > I don't see what is being violated nor what reliability has been
> >> > compromised.
> >>
> >> The TCP protcol's obligation to reliably deliver data between
> >> two applications, that is what has been violated.
> >
> > Once again, I don't see why, due to the orphans mechanism. Please
> > consider for a minute that the application-level close() is distinct
> > from the protocol-level close. The application-level close() just
> > instructs the lower layer to turn the connection into an orphan.
>
> A close() is equivalent to a shutdown() with both the send and
> receive masks set.
>
> You are telling TCP that you expect no more data to be received.
Agreed. But that's not a reason for killing outgoing data that is
being sent when there are some data left in the rcv buffer.
Honnestly David, after some thinking, could you still find a valid use
of the orphans as they are now ? I personally fail to do so. And what
drove me to the kernel on this issue is that I found the behaviour
inconsistent with the principle of the orphan itself.
Willy
next prev parent reply other threads:[~2010-09-26 23:25 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-26 13:17 TCP: orphans broken by RFC 2525 #2.17 Willy Tarreau
2010-09-26 17:02 ` Eric Dumazet
2010-09-26 17:40 ` Willy Tarreau
2010-09-26 18:35 ` Eric Dumazet
2010-09-26 18:49 ` Willy Tarreau
2010-09-26 21:01 ` Eric Dumazet
2010-09-26 21:46 ` Willy Tarreau
2010-09-26 22:19 ` David Miller
2010-09-26 22:10 ` David Miller
2010-09-26 19:16 ` Willy Tarreau
2010-09-26 22:14 ` David Miller
2010-09-26 22:13 ` David Miller
2010-09-26 22:34 ` Willy Tarreau
2010-09-26 22:38 ` David Miller
2010-09-26 22:54 ` Willy Tarreau
2010-09-26 23:08 ` David Miller
2010-09-26 23:25 ` Willy Tarreau [this message]
2010-09-27 1:12 ` David Miller
2010-09-27 5:39 ` Willy Tarreau
2010-09-27 5:48 ` Eric Dumazet
2010-09-27 6:04 ` Willy Tarreau
2010-09-27 6:44 ` David Miller
2010-09-27 6:42 ` David Miller
2010-09-27 7:34 ` Willy Tarreau
2010-09-27 7:42 ` David Miller
2010-09-27 19:21 ` Willy Tarreau
2010-09-27 23:28 ` Herbert Xu
2010-09-28 5:12 ` Willy Tarreau
2010-09-28 5:32 ` David Miller
2010-09-28 5:37 ` Willy Tarreau
2010-09-27 9:12 ` Julian Anastasov
2010-09-27 19:24 ` Willy Tarreau
2010-09-27 20:00 ` Eric Dumazet
2010-09-28 9:01 ` Julian Anastasov
2010-09-28 9:26 ` Willy Tarreau
2010-09-27 8:02 ` Herbert Xu
2010-09-27 20:00 ` Willy Tarreau
2010-09-27 20:08 ` Rick Jones
2010-09-27 20:20 ` Willy Tarreau
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100926232530.GK12373@1wt.eu \
--to=w@1wt.eu \
--cc=davem@davemloft.net \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.