<div dir="ltr"><div>Hi, <br></div><div>I think that that we cannot simply discard spots that are failing the senderverify check because of the very different flavors of cluster on the net.</div><div><br></div><div>And it's not just a matter of good or fake spots. The other important topic we have to deal with is the flooding itself. Consider that a single IP PC61packet (with a standard MTU of 1500 Bytes) can contain at least 20 spots (it depends which info are in the spot itself) or more.</div><div>So</div><div>a rate of 10KByte/s (80Kbit/s) generates 133 spots per second (10/1,5*20)</div><div>a rate of 125KByte/s (1Mbit/s) generates 1666 spots per second</div><div><br></div><div>Considering internet speed availability nowadays....... 1Mb/s is nothing in terms of bandwidth, but the effect on the cluster is huge.</div><div><br></div><div>At this point I would suggest a different approach.</div><div>We need to classify spots in different classes. Let's say gold and silver class.</div><div>In the gold class we move all the spots that are verified. In the silver the rest.</div><div>In case of a flooding attack we have to drop spots from the silver class first.</div><div><br></div><div>Usually queues are used to achieve this. Queues with different length and different "serving" speed.</div><div><br></div><div>Example: </div><div>Gold queue is 100 spots long and we serve 5 spots per second.</div><div>Silver queue is 50 spots long and we serve 2 spots per second.</div><div>When queues are full, spots are discarded.</div><div><br></div><div>I know that this is the theory....and implementation is not easy, but considering what happened last weekend, I cannot imagine another solution.</div><div><br></div><div>73s</div><div>Andrea iz2lsc</div><div><br></div><div><br></div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">--></div></div></div>