Does “decred-seeder” really have to query my peer/node a couple of times per minute? I seems way over the top to me and it is spamming my syslog with lines like Jun 23 10:27:31 myhost dcrd[14875]: 10:27:31 2016-06-23 [INF] BMGR: New valid peer [2604:a880:800:10::1c0:1001]:37613 (inbound) (/dcrwire:0.2.0/dcrd:0.1.6/) Jun 23 10:27:31 myhost dcrd[14875]: 10:27:31 2016-06-23 [INF] BMGR: Lost peer [2604:a880:800:10::1c0:1001]:37613 (inbound) Jun 23 10:27:32 myhost dcrd[14875]: 10:27:32 2016-06-23 [INF] BMGR: New valid peer [2604:a880:400:d0::1:1001]:45561 (inbound) (/dcrwire:0.2.0/dcrd:0.1.6/) Jun 23 10:27:33 myhost dcrd[14875]: 10:27:33 2016-06-23 [INF] BMGR: Lost peer [2a03:b0c0:3:d0::6b6:d001]:56066 (inbound) Cheers.
I was the first to ask a question, so perhaps you'd like to tell me why I should (or shouldn't) accept the seeders' behaviour? First of all, I don't at all see the need for polling my node so often: at least two requests per minute, and often more than that. One single request per, say, 10 minutes ought to be more than adequate. I'd like to hear any arguments for 2+ requests per minute. Secondly, with a terminal that holds 57 lines, dcrd's messages tend to shadow other — and possibly more important — messages because it sends messages to syslog so often. Yes, I could set dcrd's loglevel to WARNING or ERROR, rather than INFO. Still, I feel that polling a node the way the seeder does now is a misuse of other people's resources, so for now I have mitigated the situation by blocking the seeders with iptables.
Actually, I think there is some issue with this known peers list. I noticed few times that when this list become full (something like max ~ 125 nodes I believe) decred daemon just stucks trying add / remove new nodes and at the end dies. All my missed solo tickets were caused by this problem. We already tried to discuss it here: https://forum.decred.org/threads/how-many-inbound-peers-do-you-have.3637/