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

[Belka]

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.