Re: Re[2]: Some proxy needs

[Roberto Peon <[e-mail]>]

On Apr 10, 2012 6:01 AM, "Per Buer" <[e-mail]> wrote:
>
> Hi Nicolas, list,
>
> On Tue, Apr 10, 2012 at 12:36 PM, Nicolas Mailhot
> <[e-mail]> wrote:
> >
> > Le Mar 10 avril 2012 11:23, Per Buer a écrit :
> >> Nicholas, list,
> >>
> >> On Tue, Apr 10, 2012 at 8:56 AM, Nicolas Mailhot
> >> <[e-mail]> wrote:
> >>>
> >>>
> >>> > So, if the proxy farm fails to hash incoming requests on source IP
or
> >>> > target URL then this might happen.
> >>>
> >>> That breaks load balancing as soon as your network is big enough, with
> >>> different parts that get active at different points of the day.
> >>
> >> Sorry if I seem to miss the point, but why would it break? Are you
worried
> >> that one point in the farm would get too hot?
> >
> > I'm worried first that the activity distribution changes over time (so a
> > static table does not work), and second that any network-wide state
(such as
> > an hashtable) is a contention point and potential spof.
>
> The load balancers derrive the correct  proxy from the URL through a
> hash algorithm.
> The only state would lie on the number of active proxies. Altering the
> number of proxies
> requires a bit of thinking and you might  want to rehash at some point
> which will of
> course be painful. Sorry if I might state the obvious here but this is
> really quite
> stateless and there is no SPOF here and no contention point. We've
> used this on quite
> large scale with reverse proxies and it works like a charm.

This isn't stateless, and claims that it is are in error. The state is
external to the connection (as you have identified earlier). The fact that
it is external doesn't make it any less important.

You are right that there isn't a SPOF... there are N points of failure
instead, any of which can cause problems.
>
> > Making an individual
> > gateway smarter is simple (scaling the farms is just the matter of
adding new
> > boxes). Making balancing smart and robust when some gateways or even
some
> > physical processing sites can go down at any time is hard.

The above statement is important!
-=R

> >
> > That's why direct browser-to-proxy communication will always be
preferred and
> > more reliable than depending on a magical holistic hashtable balancer.
> > Round-robin is dumb but robust and stateless.
> >
> >>> And anyway even if your solution was possible, you still get unhappy
users
> >>> that serial refresh because they're not seeing initial progress in
their web
> >>> clients
> >>
> >> If the loadbalancer was balancing on target URLs the request would end
up at
> >> the same proxy. The proxy should be smart enough to coalesce the
request
> >> into the ongoing one and this one could feed the user a couple of
bytes so
> >> at the client understands that there is some progress on the download
as
> >> some proxies have done for years.
> >
> > Can't do when inspecting for malware.  (..)
>
> Sure. This has been done for years. It was an absolute necessity when
dealing
> with earlier versions of IE. Feeding it the first 10 bytes of
> something was considered
> safe enough and would keep the browser from timing out. So giving it
> one byte every
> 30 seconds or so would buy us 5 minutes.
>
> I think this is perfectly doable withing the current framework and
without the
> need to add further complexities to the protocol.
>
> --
> Per Buer
>