[Haskell-cafe] [tryReadAdvChan :: AdvChan a -> IO (Maybe a)] problems

[Neil Davies]

Belka

Now that you've got some metrics to know when you have a successful  
design, start examining the trades.

Most systems have a turning point in their performance as load is  
increased, you need manage the traffic so that the offered load does  
not push the system over that point (or if it does, not for too long -  
it doesn't have to be perfect all the time, just suitably good - this  
is where stochastic come it, another story).

What you are doing here is trading efficient use of the infrastructure  
(e.g. you are not going to try and run the servers close to 100%) for  
responsive behaviour.

This is one of the reasons why people create multi-levelled web manage  
architectures - you could think of the design as having an initial  
stage that can analyse and identify the traffic an characterise it -  
ideally it should be able to cope with line rate or at least a known  
upper bound (which the load balancer in front knows and can be  
configured for), it can then pass the real traffic on for processing.

This all comes down to creating back pressure: typically by mediating  
between producer and consumer with a finite queue - then configuring  
that queue to have the right length so that the back pressure is felt  
at an appropriate point, too long and the experienced delay is too  
large, too short and you are changing modes of behaviour too quickly -  
again it that stochastics/queueing theory stuff.

Avoiding starvation is easy, FIFO service does that - but you'll find  
that's not enough you also need to bound the service time for certain  
requests people often think that 'priority' is the right answer but  
usually that is too naive. Resources are finite, giving one source of  
demand 'priority' means that the other sources loose out and that  
trade is highly non-linear and creates its own denial-of-service.

Neil

On 2 May 2009, at 06:27, Belka wrote:

>
> Thanks, Niel. :)
> You actually motivated me to determine/specify defense requirements  
> <- that
> I should have done long before writing here.
> Now I'm not experienced in DDoSs defending, so my reasoning here  
> might be a
> bit voulnerable. Few basic requirements:
> 1. Server has services that shouldn't be endangered by computational
> resource starvation. That is why I use load balancing for SAR  
> (Services
> under Attack Risk). I even use 2 types of load controls: one per  
> each SAR,
> and the second - above all ARSes.
> 2. Even when under attack SAR should be able to serve. Of course, it's
> effective input capability becomes much lower, but requirement here  
> is to
> provide possible maximum of effectiveness. That is why
> 2.1. identification of bad request should be fast, and
> 2.2. request processing should be fair (without starvation on  
> acceptance
> time).
>
> After projecting this /\ specification on architecture plan, the  
> need in
> *good* tryReadChan is now less sharp. However, it still would be  
> very useful
> - I also have other applications for it.
>
> The *good* tryReadChan would be atomic, immediate, and with  
> determinate
> result (of type Maybe)...
> ----------
> By the way, for
>> Actually, am I wrong thinking, that it can't be helped - and the
>> degradation
>> from cute concurency synchronization model of Chan is unavoidable?
> I have an idea of such solution (without getting down to lower level
> programming), - called it "fishing": one should complicate the flow  
> unit
> (FlowUnit), that is being passed in the Channel. The FlowUnit  
> diversifies to
> real bizness data, and service data. That way I now may gain control  
> over
> blocking....
>
> But this solution is not simple and lightweight.  If anybody is  
> interested,
> I could describe the concept in more details.
>
> Belka
>
>
> Neil Davies-2 wrote:
>>
>> Belka
>>
>> You've described what you don't want - what do you want?
>>
>> Given that the fundamental premise of a DDoS attack is to saturate
>> resources
>> so that legitimate activity is curtailed - ultimately the only
>> response has to be to
>> discard load, preferably not the legitimate load (and therein lies  
>> the
>> nub of the problem).
>>
>> What are you trying to achieve here - a guarantee of progress for the
>> system?
>> a guarantee of a fairness property? (e.g. some legitimate traffic  
>> will
>> get
>> processed) or, given that the DDoS load can be identified given some
>> initial
>> computation, guarantee to progress legitimate load up to some level  
>> of
>> DDoS
>> attack?
>>
>> Neil
>>
>>
>
> -- 
> View this message in context: http://www.nabble.com/-tryReadAdvChan-%3A%3A-AdvChan-a--%3E-IO-%28Maybe-a%29--problems-tp23328237p23343213.html
> Sent from the Haskell - Haskell-Cafe mailing list archive at  
> Nabble.com.
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe