addnode are administratively added connections that the operator prefers to have connected. Make bitcoind a bit more insisting on having these connected.
connect is far more forceful. I don't think this is an issue.
NAK. (sorry). Bypassing the limit makes this prone to accidentally abusive use by confused users (I've very frequently seen people add addnode lists with hundreds of nodes expecting it to make their nodes faster, when doing so has the opposite effect), and the 5 second retry is itself abusive (e.g. imagine a popularly known node that is full with hundreds of people addnoding it).
I'd have no complaint with fixing it so that addnoded peers took priority over other connections and bumped them out, or starting at 5 seconds and doing a capped exponential backoff off on retries though.
It is confusing that RPC addnode behavior differs entirely from addnode parameters.
Agree that consistency between RPC and cmd line is nice
getpeerinfo is another I think that works differently rpc v cmd . IF I recall correctly. also addnode has different "states" like once .. as I said above .. CONNECT is probably what you want if determinism is your goal .. the topology assumes (from what I have read and observed) addnode is untrusted vs connect which is trusted. ( I am talking about my experience and what I do ) YMMV's massively.
shit .. actually some hierarchical rules would be nice ..
-addnode=<ip> Add a node to connect to and attempt to keep the connection open LESS THAN
-connect=<ip> Connect only to the specified node(s)
God I wish I could code worth a damn anymore.
NACK in its current state. If a node disconnects you, there could be some other problem. Connecting every few seconds is undesirable.
Agree that consistency between the different ways to addnode would be nice, as the option/command is called the same that creates expectation of sameness.
I haven't run bitcoind much lately, but I had around 500 addnodes back in November.
Pretty sure I made a comment about how it tried to reconnect to them too fast & how the delay should be a config option, if I had been running standard 5000 timeout instead of 150, it never would have gotten past the addnodes. I suppose for your average user, it'd just cause more confusion, however.
I just edit(ed) the source and changed it to 10 minutes.
sön 2014-03-16 klockan 15:57 -0700 skrev Ivan Frimmel:
connect is far more forceful. I don't think this is an issue.
connect is a bit too intrusive, not only very aggressively adding connections but also disabling listening for incoming connections.
Regards Henrik
tis 2014-03-18 klockan 16:31 -0700 skrev Ivan Frimmel:
shit .. actually some hierarchical rules would be nice ..
-addnode= Add a node to connect to and attempt to keep the connection open -connect= Connect only to the specified node(s)
That's how they work, except that addnode does a quite poor job at keeping connected due to
a) It being capped by outgoing connection limit, which means that once it's dropped it is quite unlikely to get connected again.
b) The default (hardcoded) retry interval is quite long.
Regards Henrik
tis 2014-03-18 klockan 16:02 -0700 skrev Warren Togami:
It is confusing that RPC addnode behavior differs entirely from addnode parameters.
Not that different, if ignoring the oneshot alternative available via rpc.
config:
addnode=host
rpc:
addnode host add
both end up equal in vAddedNodes
But at most times the rpc call is quite useless as the outgoing connection pool is generally kept full so no connection will be made to the added node. Same problem is also seen if a connection to an added node is dropped, it then never reconnects due to the outgoing connection pool always being full by new outgoing connections filling it up until the addnode 5 minutes retry timer expires.
Regards Henrik
@hno The solution I'd proposed to that was to allow a 9th connection if there are unconnected addnodes and any non-addednoded outbound connections, and if we end up with 9 successfully connected drop the least recently connected non-addnoded peer. This would prevent the bad behavior without opening things up to people inadvertently wasting resources by dropping in a big list.
ons 2014-03-19 klockan 12:06 -0700 skrev James Eze:
I haven't run bitcoind much lately, but I had around 500 addnodes back in November.
Are you sure those were addnodes and not connect? Or had you made other modifirations to allow this many addnode connectins?
By default there is a hardcoded limit of 8 outgoing connections, p2p and addnode seeded. Only bypassed by connect= and oneshot connections.
Regards Henrik
- Bypass outgoing connections limit for addnode nodes
@gmaxwell Yes dropping non-addnode connections in favor for addnode does make sense. I will see if something like that can be done in a reasonable manner.
Meanwhile I am withdrawing the retry interval change, only keeping connection count bypass in this patch. Changes to retry timer should be done separate.
yes, they were addnodes. at that time, I ran bitcoind with maxconnections of 900
Automatic sanity-testing: PASSED, see http://jenkins.bluematt.me/pull-tester/p3888_2aa7ca56081530d71de7535f5a2fc8d787577be7/ for binaries and test log. This test script verifies pulls every time they are updated. It, however, dies sometimes and fails to test properly. If you are waiting on a test, please check timestamps to verify that the test.log is moving at http://jenkins.bluematt.me/pull-tester/current/ Contact BlueMatt on freenode if something looks broken.
Closing this as there is no consensus to merge.