Lynn W. Taylor wrote:
> Downloads could be throttled in the same manner -- making the clients 
> request slower will reduce the bandwidth being downloaded as well.

Yes.

> That could actually be done on the server side by assigning less work on 
> each request during high load times.

Not necessarily so... Provided the clients don't immediately pester for 
more. Back to the backoff time problem again.

[...]
> Did you know that it is possible to tunnel almost any other protocol 
> through DNS?

Yes. However... That's only useful if you can survive a 24 hour delay or 
so for updating the TXT records. There's other tricks but they're not 
practical here.

The DNS admins might get upset if people started abusing DNS records for 
broadcasting other than what is directly DNS related...


> Martin wrote:
[...]
>> Do not confuse a DDOS of *new* connections with what I think is 
>> happening for s...@h of simply a data amplification overload that then 
>> saturates and effectively degrades the link capacity.
>>
>>
>> My present view is that a *combination* of restricting the number of 
>> connections serviced, AND restricting the permitted data rates is needed.
>>
>>
>> The number of simultaneous connections that can be permitted to be 
>> serviced without any data rates limiting is really surprisingly low 
>> compared with "website mentality" that is to serve thousands of 
>> simultaneous connections.
>>
>> As an experiment, can s...@h limit the max number of simultaneous 
>> upload/download connections to see what happens to the data rates?
>>
>> I suggest a 'first try' max simultaneous connections of 150 for 
>> uploads and 20 for downloads. Adjust as necessary to keep the link at 
>> an average that is no more than just *80* Mbit/s.
>>
>>
>> Aside: For example I've got uploads limited to just 200kb/s so that my 
>> upload link is never DOSed by Boinc.
>>
>> Plausible?

The real test is to try the above...


Regards,
Martin

-- 
--------------------
Martin Lomas
m_boincdev ml1 co uk.ddSPAM.dd
--------------------
_______________________________________________
boinc_dev mailing list
[email protected]
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Reply via email to