not count
requests we are handling locally towards the limits. But we will need more than
that.
Another issue is we have the infrastructure for determining whether a request
will be accepted or not, reasonably reliably, before sending it. We could use
this without queueing.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20110827/e0b04971/attachment.pgp>
al
DoS: Good, assuming we solve the problem mentioned in the previous strategy
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL:
<https://emu.
comes a bit like this cartoon: http://flic.kr/p/5npfm2 How can this
be avoided?
Ian.
--
Ian Clarke
Founder, The Freenet Project
Email: ian at freenetproject.org
-- next part --
An HTML attachment was scrubbed...
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20110827/71354573/attachment.html>
I'm glad to see that the subject of complexity has come up, and if I
can speak to in a more general way...
Complexity is insidious - you start with a simple idea, the creativity
flows and over time, you are wedded to a highly coupled, inflexible
and obscure beast that is hard to distance yourself
I'm glad to see that the subject of complexity has come up, and if I
can speak to in a more general way...
Complexity is insidious - you start with a simple idea, the creativity
flows and over time, you are wedded to a highly coupled, inflexible
and obscure beast that is hard to distance yourself
Matthew,
This makes sense from the perspective of making incremental changes, but I
think we need to be more drastic than that. I think we need to go back to
the drawing board with load management. We need to find a solution that is
simple enough to reason about, and to debug if we have problems
On Saturday 27 Aug 2011 15:43:53 Matthew Toseland wrote:
> After trying out New Load Management on the network and seeing rather bad
> results, we need to reconsider load management. IMHO Old Load Management (the
> current system) is still not an acceptable answer.
>
> Ideal load management woul
After trying out New Load Management on the network and seeing rather bad
results, we need to reconsider load management. IMHO Old Load Management (the
current system) is still not an acceptable answer.
Ideal load management would:
- PERFORMANCE: Performance is the number of requests running in