Re: Re[2]: Some proxy needs

Hi Nicolas, list,

On Tue, Apr 10, 2012 at 12:36 PM, Nicolas Mailhot
<nicolas.mailhot@laposte.net> 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
>> <nicolas.mailhot@laposte.net> 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.

> 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.
>
> 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

Received on Tuesday, 10 April 2012 12:59:56 UTC