limiter.md

@fjl @holiman and anyone who might be interested (whenever you have free time, not urgent) : this is a WIP PR (absolutely untested and partly unfinished) where I implemented a fairly simple (400 LOC total + utils.WeightedRandomSelect, does not use the NodeStateMachine :) ) DDoS protector. The reason I spent time with it at this early stage is that I think the token market interface really needs to be designed with this aspect in mind. Polling rates and unhealthy competition (arms race) can be a problem with markets, especially in a decentralized and uncontrolled, somewhat chaotic environment. The reason I am showing it to you is because I think something like this could be a recommendation (maybe even an EIP) for our entire DHT and I am interested in your opinons from both a security and DHT centric perspective. So basically what it does is

• keeps request queues by both IP address (string) and enode.ID
• has a single processing loop that even does time.Sleeps between serving them so that the DHT logic can never hurt other processes
• has a probabilistic selection based throttling mechanism (which behaves trivially and deterministically when there is no extreme usage but tries to give a sufficient chance to the proven useful connections during extreme traffic).
• 50% of serving probability weights are distributed equally between active individual IP addresses. Multiple enode.IDs can request from the same IP in which case the IP's weight is further distributed equally.
• the other 50% is proportional to value / sumValue where the "value" is anything that is an indicator of usefulness.
• the first half protects from DoS but gives limited protection againgst DDoS, the second one ensures that already proven connections can not be easily broken even with heavy DDoS so there is much less incentive to even try and spend money on. Basically an attacker can only hinder the forming of new connections but that will not do real damage very soon. This is also a Kademlia recommendation to prioritize older contiuous connections. Maybe for a Kademlia the weight could simply be the connection age. For lespay it is money received from the enode.ID on server side, total service value on the client side. Multiple dimensions of value can also be easily added if necessary, each dimension getting a guaranteed total percentage of service.

https://github.com/zsfelfoldi/go-ethereum/blob/les4udp/les/utils/limiter.go https://github.com/zsfelfoldi/go-ethereum/blob/les4udp/les/utils/costfilter.go