I've been tracking a normal kad contact's (myself) requests, by keeping the request queue in which responded requests are just marked, and output the latest same opcode request to the same ip, when the flood criteria (time interval) could be activated in remote peer's side.
It turned out that some of requests, 0x21 mostly, also 0x43 and 0x44 sometimes, is so close to the last one, that would even make us banned by the remote peer.
For the following logs of mine:
12/15/2018 7:30:18 AM: Ignore Sending Kademlia packet opcode=0x21 to 89.73.xx.xx to avoid flood control of remote client, previous request is 0 ms before 12/15/2018 7:30:19 AM: Ignore Sending Kademlia packet opcode=0x21 to 77.73.xx.xxx to avoid flood control of remote client, previous request is 1093 ms before
As you can see, if the request packet sent to remote contact, our ip will be banned by them since the time delay from former same opcode request is less than 1/5 of 0x21 allowed, i.e., 6/5 == 1200 ms.
My suggestion is, when trying to send a kad request, and the remote side will surely filter it or even ban our ip, don't actually send it. Since even we send out the request, the remote side will not respond to it, if flood protection is activated at remote side.
I would like to have your opinions on that.
Edit1: Just checked my log files, there're 1,632 hits in 73 files, which means the requests that are not supposed to get responses is quite common.
This post has been edited by Enig123: 15 December 2018 - 11:41 PM