netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: stephen@dino.dnsalias.com (Stephen J. Bevan)
To: "Caitlin Bestler" <caitlin.bestler@gmail.com>
Cc: "Rick Jones" <rick.jones2@hp.com>,
	"Martin Schiller" <mschiller@tdt.de>,
	netdev@vger.kernel.org
Subject: Re: Suppress / delay SYN-ACK
Date: Thu, 12 Oct 2006 22:41:53 -0700	[thread overview]
Message-ID: <17711.10017.437640.120171@localhost.localdomain> (raw)
In-Reply-To: <469958e00610121458h45581840ke0367647a735c635@mail.gmail.com>

Caitlin Bestler writes:
 > More to the point, on what basis would the application be rejecting a
 > connection request based solely on the SYN?

Perhaps not the reason that Martin is interested in but ...

Say you are writing a transparent proxy i.e. when a TCP connection is
made through the box, rather than forwarding the TCP SYN, it is
delivered locally where it accepted and then the proxy makes a
separate TCP connection to original IP address.  Thus all traffic
flows through a user-space proxy that can cache, log, virus scan,
... etc. the traffic.  Say also that the proxy is for a protocol that
can mediate peer<->peer connections via a server (e.g. most IM
protocols).  Furher still assume that the client has the property that
if while trying to establish a peer<->peer connection it will back off
and use the server if it does not manage to establish the peer<->peer
TCP connection but if it does establish the connection then it will
not back off to use the server.  Thus if a client is behind the
transparent proxy the proxy terminates the TCP connection locally and
at that point the client thinks it has connected to the peer even
though the proxy has yet to establish a connection to the peer.

Should the proxy fail to do so all it can do is drop the
client<->proxy connection at which point the client does not connect
via the server and the user of the client is not happy since if the
proxy wasn't there everything would have worked just fine.  So, if the
proxy could delay the SYN/ACK until it has determined whether it can
really connect to the IP address in the SYN, then it can decide
whether to SYN/ACK or just not respond.

Of course, the much simpler solution is to fix the client program so
that it will still back off to the server even if it does manage to
make a TCP connection.  However, fixing other people's software is
easier said than done.  So if you are trying to $ell a tranparent
proxy solution, you need to handle it somehow.  Delayed SYN/ACK is one
such way, though not necessarily the best way.

  parent reply	other threads:[~2006-10-13  5:42 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-12  8:08 Suppress / delay SYN-ACK Martin Schiller
2006-10-12  8:38 ` Eric Dumazet
2006-10-12 10:13   ` Martin Schiller
2006-10-12 10:31     ` Evgeniy Polyakov
2006-10-12 10:39       ` Eric Dumazet
2006-10-12 10:53         ` Evgeniy Polyakov
2006-10-12 10:36     ` Eric Dumazet
2006-10-12 16:13 ` Rick Jones
2006-10-12 21:58   ` Caitlin Bestler
2006-10-12 22:12     ` jamal
2006-10-12 22:54     ` Rick Jones
2006-10-13  0:57       ` Stephen Hemminger
2006-10-13  4:11       ` Eric Dumazet
2006-10-13 16:39         ` Rick Jones
2006-10-13 20:13           ` Eric Dumazet
2006-10-13 21:50             ` Rick Jones
2006-10-16  6:52             ` Martin Schiller
2006-10-13  5:41     ` Stephen J. Bevan [this message]
2006-10-13  6:28       ` Martin Schiller
2006-10-16  7:02 ` Lennert Buytenhek
2006-10-17 12:04   ` Martin Schiller
2006-10-17 12:54     ` Eric Dumazet
2006-10-18  6:23       ` Martin Schiller

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=17711.10017.437640.120171@localhost.localdomain \
    --to=stephen@dino.dnsalias.com \
    --cc=caitlin.bestler@gmail.com \
    --cc=mschiller@tdt.de \
    --cc=netdev@vger.kernel.org \
    --cc=rick.jones2@hp.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).