-
Notifications
You must be signed in to change notification settings - Fork 35.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Addnode optimization and addnode access via RPC #1549
Conversation
addnode RPC: cool. getaddednodeinfo : An Object with duplicated keys ("connectedto") is going to cause problems in some languages. And I don't understand the multiple connectedto's-- if I addnode a node, I might get more than one connection to it? |
Changed to array. Sure, there are a number of scenarios where you may get more than one connection to a given -addnode (when the -addnode is dns and maps to multiple addresses). -addnode itself wont make more than one connection, but you may get an incoming connection, or happen to connect to another ip that is mapped to from your added node. |
Hm. I wonder if it should work instead like this: getaddednodeinfo -> "addednode": [ "dnsseed.bluematt.me", "foobarbaz.onion" ] getaddednodeinfo dnsseed.bluematt.me -> "address" : [ "95.154.99.150:8333", "..."] And leave the connected status (in/out/not connected) up to getpeerinfo? Otherwise I think the connected status needs to tristate, in/out/not. |
I wonder whether addnode is the right thing to expose - it is intended to be used for stable trusted nodes you know and is something more of a config setting. For an RPC, it may be more useful to have a one-shot command "connect now to X, no matter what". Eventually, I think the entire network config should be exposed via RPC, but I'd do that via some "setnetconfig [config]" call, rather than specific RPCs for every detail of the config. |
@gmaxwell In terms of listing the full list of addresses the added node resolves to...yes, that would be better. In terms of making the user make two/three calls to get at the info on whether or not a given added node is connected, I entirely disagree here. I'll add a in/out/not connected flag. @sipa The goal is to allow a long-running node to add trusted nodes without having to restart. In terms of having a one-shot connection, this was discussed back when addnode was changed, since it used to be a one-off, I was then of the opinion that addnode shouldn't be scrapped to allow for that and keepnode was clearer in this case... In any case, I agree that there should be an option for a one-off connection creator RPC, Ill throw that in when I touch this up (connecttonode?). |
@TheBlueMatt Yea, I actually wrote the tristate first and then thought some people might disagree with the duplication. I'm pretty sure we should have commands to edit addnode on running nodes. I'm tired of restarting my p2pool bitcoind's just to dork around with the addnode settings. Perhaps the oneshot could just be a addnode foo oneshot instead of another RPC? |
Tweaked as a result of suggestions. |
addnode ACK |
This needs rebasing. |
Test Plan (can someone run through this to make the powers-that-be happy) : Start a node with no outbound connections (-connect=0.0.0.0). RPC "addnode add". RPC "addnode add" where DNS Name is just a simple single IP. |
The powers that be will kick in a BTC or two bounty for somebody to execute the test plan (and save their debug.logs somewhere, so we really know they ran the test). Recruiting a tester from the #bitcoin IRC channel or from https://bitcointalk.org/index.php?board=12.0 seems to work. |
Also moves the DNS lookup of -addnode nodes into the repeated loop, allowing -addnode to follow DNS changes.
Automatic sanity-testing: PASSED, see http://jenkins.bluematt.me/pull-tester/f2bd6c28e6bddd75d56d580c28f45d2a8be065ab for binaries and test log. |
Ran the test as BlueMatt suggested. Everything worked correctly. A full report and relevant debug.log files are at |
Thanks @apoelstra , 1 BTC "thanks for testing" tip sent. ACK on code changes, pulling. |
Addnode optimization and addnode access via RPC
Addnode optimization and addnode access via RPC
* add masternodelist pubkey to rpc * add method in alphabetical order
Useful Changes:
Two new RPC commands:
eg:
getaddednodeinfo dnsseed.bluematt.me
[
{
"addednode" : "dnsseed.bluematt.me",
"connectedto" : [
"95.154.99.150:8333",
"80.221.217.69:8333"
]
}
]
or
getaddednodeinfo
[
{
"addednode" : "10.232.4.10",
"connectedto" : [
"10.232.4.10:8333"
]
},
{
"addednode" : "dnsseed.bluematt.me",
"connectedto" : [
"95.154.99.150:8333",
"80.221.217.69:8333"
]
}
]