Mailing-List: contact user-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@hbase.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: <BANLkTikapJ+txcJ7iC-3Gwh3Db3P+FcpAA@mail.gmail.com>
References: <BANLkTikvcHKaLF_eeHZBWEDakAY4QwNHjA@mail.gmail.com>
 <BANLkTik_ofvk-TsQ069=tFwb-Qv52knJcQ@mail.gmail.com>
 <BANLkTimd744thY2xC7OmsPoq0A6yD-ZYEw@mail.gmail.com>
 <BANLkTim4hYy5sobL_4HeALvjCs-jBM=Scw@mail.gmail.com>
 <BANLkTinTKmDsxDchkJ0CkEts1u_NOq99NQ@mail.gmail.com>
 <BANLkTik4QMvPRfa8vU6beTS01FgYYqnoiw@mail.gmail.com>
 <BANLkTinPx9Gpzr_KBJF5ixJXPgO+BKbwBg@mail.gmail.com>
 <BANLkTim7d90tvanXnCXcuxBYa1KjPspHgQ@mail.gmail.com>
 <BANLkTikTubVjZaw1pR2+gVce--2idOhzeA@mail.gmail.com>
 <BANLkTi=0bEfwcCN9EajfH8G9HUH1i4We4Q@mail.gmail.com>
 <BANLkTikva4oMcXywxUgw=JL2PHqf0ua1Hg@mail.gmail.com>
 <BANLkTikdwon2Rm96ngZN16uAdCRJP2+vHw@mail.gmail.com>
 <BANLkTinvWnqjydjFs4EZ4mVxWdEGB_PVwQ@mail.gmail.com>
 <BANLkTikapJ+txcJ7iC-3Gwh3Db3P+FcpAA@mail.gmail.com>
From: Ted Dunning <tdunning@maprtech.com>
Date: Thu, 21 Apr 2011 23:22:17 -0700
Message-ID: <BANLkTinTKD88HY5upyA2pW8EERde_4P8pA@mail.gmail.com>
Subject: Re: 0.90 latency performance, cdh3b4
To: user@hbase.apache.org
Content-Type: multipart/alternative; boundary=bcaec51a7d4c55291704a17be2f0

--bcaec51a7d4c55291704a17be2f0
Content-Type: text/plain; charset=ISO-8859-1

Yeah... but with UDP you have to do packet reassembly yourself.

And do source quench and all kinds of things.

Been there.  Done that.  Don't recommend it unless it is your day job.

We built the Veoh peer to peer system on UDP.  It had compelling advantages
for us as we moved a terabit of data per second 5 years ago, but it was
distinctly non-trivial to get right.  The benefits we had included:

- we could make our flows very aggressive, but less aggressive than TCP.
That made them feel like smoke relative to web-surfing.  (not a benefit
here)

- we could handle thousands of connections if necessary (not a benefit here)

- we could penetrate firewalls more easily by state spoofing (not a benefit
here)

- our protocol did magical window reassembly from multiple sources (not a
benefit here)

But getting this to work was weeks of work and months of testing with
thousands of different clients.  I wouldn't want to repeat that without
serious reasons.


On Thu, Apr 21, 2011 at 11:12 PM, Dmitriy Lyubimov <dlieu.7@gmail.com>wrote:

> > What do you see here D?
>
> I am not sure. I am not very good at understanding network frames. but
> tcp kind of spends a lot of resources to ensure the flow. While udp
> wouldn't bother with all that nonsense.
>

--bcaec51a7d4c55291704a17be2f0--