rpc: Add admin_addTrustedPeer and admin_removeTrustedPeer. by shazow · Pull Request #16333 · ethereum/go-ethereum

shazow · 2018-03-18T15:31:51Z

These RPC calls are analogous to Parity's parity_addReservedPeer and
parity_removeReservedPeer.

They are useful for adjusting the trusted peer set during runtime,
without requiring restarting the server.

Also includes a test which should help exercise #16189 as well.

shazow · 2018-03-22T16:58:43Z

Ping. Anyone up for a review? (Maybe @karalabe since you looked at #16189?)

shazow · 2018-04-03T02:32:48Z

I think the test failures are flakes. Anyone have a chance to take a look?

shazow · 2018-04-30T19:01:43Z

Rebased on latest master.

Polite ping for feedback please. :)

holiman · 2018-05-17T07:13:59Z

Apologies for the long lead-time. It tentatively looks good to me, but could either @fjl or @zsfelfoldi PTAL at this one?

holiman · 2018-05-17T09:29:43Z

Context for this PR: https://medium.com/@shazow/an-economic-incentive-for-running-ethereum-full-nodes-ecc0c9ebe22 (I like it!)

shazow · 2018-05-17T14:20:57Z

@holiman Thanks!

FWIW I've been using this patch in my live vipnode deployment for the last couple of weeks and it's working as expected.

ryanschneider · 2018-05-22T17:08:28Z

Any chance this could get tagged with the 1.8.9 milestone? I'd love to see this in the next release.

holiman · 2018-05-22T19:32:03Z

Please @zsfelfoldi take a look?

zsfelfoldi

Looks good to me in general, see comments

zsfelfoldi · 2018-05-23T19:20:19Z

+			trusted[n.ID] = true
+			// Mark any already-connected peer as trusted
+			if p, ok := peers[n.ID]; ok {
+				p.rw.flags |= trustedConn


Since this can happen any time during the peer's lifecycle, can't this write collide with a read in func (p *Peer) Info() ? I am not very familiar with this part but it looks like we assumed until now that flags don't change after the peer is connected. @fjl opinion? Should we not use locks or atomic read/write if we change the flags of live peers?

That's a good question. go test -race ./p2p didn't catch it but you might be right.

I'm happy to bolt the flags down with a mutex or atomic. Let me know what you'd prefer. :)

I think it's OK to just add the ID to the trusted set without modifying flags of existing connections. The flag is not used after handshake anyway.

@fjl Hm, I worry that has potential for breaking other code that relies on the peer state. Such as if you do admin.peers, it will return incorrect metadata, right?

We would need a lock then and I want to avoid that ;)

@fjl Just rebased and pushed another commit with more testing for this, still passes with -race on. I'm fairly convinced that these variables are only ever written and read inside the server event loop, so I don't think there is a race condition.

If you still prefer, I can get rid of updating the flags. We might be able to get rid of the flags altogether and just read the state from the server lookup maps on-demand, but that may be a somewhat larger refactor.

It passes because nothing calls p.Inbound in those tests. That would race. Maybe the best way to avoid a race is to just cache inbound flag in peer as a bool.

Sorry for being so pedantic about this, the PR is good otherwise.

@fjl Nah that's not pedantic; I don't want to introduce a race, but I was being fixated on the parts that I used.

Let me make some more tweaks, will ping again.

zsfelfoldi · 2018-05-23T19:21:26Z

+			// This channel is used by RemoveTrustedPeer to remove an enode
+			// from the trusted node set
+			srv.log.Debug("Removing trusted node", "node", n)
+			if _, ok := trusted[n.ID]; ok {


This check seems to be unnecessary, deleting a non-existent key should not cost more than checking its existence.

Good call, fixed.

shazow · 2018-06-07T14:48:35Z

@fjl I pushed a few changes, but I'm still unable to reproduce the race in testing for whatever reason: E.g. 291fcfb still passes, I tried that block in a separate goroutine also, not sure why it's not getting caught (let me know if you have a suggestion here). I do agree that it should be a race since AddTrustedPeer modifies the flags and p.Inbound() reads the flags. Maybe a bug in the Go race detector where it doesn't notice bitwise operations?

I also pushed 4e5f57a which moves the p.Inbound() check against a locally cached value set when the peer is created. Could probably get rid of the inboundConn flag altogether and update the code to just check the p.isInbound if we prefer?

In general, feels like the flags bitwise int should just be a bunch of bools to start with. What was the thinking behind the conn.flags int?

shazow · 2018-06-07T16:53:58Z

Ah managed to find the right combination of goroutine'ing to get the race conditions to trigger in ce10c1e, will play around with some fixes next.

shazow · 2018-06-08T01:53:06Z

I ended up wrapping the flag ops with atomic as @zsfelfoldi originally suggested (and rolling back the isInbound cached value for consistency), this makes the failing test pass and is a reasonably small change: 07ef2cc

@fjl Please take another look.

shazow · 2018-06-15T17:30:29Z

Ping. Please take another look. ❤️

These RPC calls are analogous to Parity's parity_addReservedPeer and parity_removeReservedPeer. They are useful for adjusting the trusted peer set during runtime, without requiring restarting the server.

shazow · 2018-06-21T16:24:48Z

Rebased latest master.

shazow · 2018-07-30T18:31:46Z

Ping ping.

tinybike · 2018-07-31T11:21:14Z

@karalabe @zsfelfoldi is there anything further this PR needs before merging?

zsfelfoldi · 2018-08-06T10:42:34Z

@shazow I am sorry, I totally forgot about this and then left for a long vacation. I checked it again, there is one small issue, see my comment. If that it fixed, I think we can merge it immediately.

zsfelfoldi · 2018-08-06T11:21:41Z

+	} else {
+		flags &= ^f
+	}
+	atomic.StoreInt32((*int32)(&c.flags), int32(flags))


This is not atomic :) Please use CompareAndSwap here just to be totally safe.

zsfelfoldi

I'll merge this now and fix the atomic issue myself because it was waiting for such a long time...

shazow · 2018-08-06T13:45:39Z

@zsfelfoldi Thank you!

evertonfraga · 2018-08-24T20:31:20Z

Amazing! thanks for the contribution @shazow

…16333)

…thereum#16333)" This reverts commit e65b81a.

…16333)

shazow requested review from fjl and zsfelfoldi as code owners March 18, 2018 15:31

shazow force-pushed the addremovetrustedpeer branch from d4fdc77 to fda995c Compare March 18, 2018 16:25

shazow force-pushed the addremovetrustedpeer branch from fda995c to c1670af Compare April 30, 2018 18:59

shazow force-pushed the addremovetrustedpeer branch from c1670af to 57b6379 Compare May 14, 2018 21:38

ryanschneider mentioned this pull request May 17, 2018

How to let geth always connect with another peer? #16735

Closed

zsfelfoldi reviewed May 23, 2018

View reviewed changes

shazow force-pushed the addremovetrustedpeer branch from c85443e to 2086d4f Compare June 5, 2018 19:47

shazow force-pushed the addremovetrustedpeer branch from b458860 to ce10c1e Compare June 7, 2018 16:53

shazow added 7 commits June 21, 2018 12:21

rpc: Add admin_addTrustedPeer and admin_removeTrustedPeer.

2a75fe3

These RPC calls are analogous to Parity's parity_addReservedPeer and parity_removeReservedPeer. They are useful for adjusting the trusted peer set during runtime, without requiring restarting the server.

p2p: Test for MaxPeers=0 and TrustedPeer override

773857a

p2p: More tests for AddTrustedPeer/RemoveTrustedPeer

699794d

p2p: Attempt to race check peer.Inbound() in TestServerDial

399aa71

p2p: Cache inbound flag on Peer.isInbound to avoid a race

dcca66b

p2p: Test for peer.rw.flags race conditions

193a402

p2p: Wrap conn.flags ops with atomic.Load/Store

6209545

shazow force-pushed the addremovetrustedpeer branch from 63236c2 to 6209545 Compare June 21, 2018 16:24

shazow mentioned this pull request Jul 4, 2018

Re-enable LES as option status-im/status-go#1025

Closed

4 tasks

zsfelfoldi reviewed Aug 6, 2018

View reviewed changes

zsfelfoldi approved these changes Aug 6, 2018

View reviewed changes

zsfelfoldi merged commit c4df674 into ethereum:master Aug 6, 2018

zsfelfoldi mentioned this pull request Aug 6, 2018

p2p: use safe atomic operations when changing connFlags #17325

Merged

karalabe added this to the 1.8.14 milestone Aug 6, 2018

shazow deleted the addremovetrustedpeer branch August 6, 2018 13:45

wanwiset25 pushed a commit to XinFinOrg/XDPoSChain that referenced this pull request May 20, 2024

rpc: Add admin_addTrustedPeer and admin_removeTrustedPeer. (ethereum#…

8242395

…16333)

wanwiset25 mentioned this pull request Jun 3, 2024

Increase txsize XinFinOrg/XDPoSChain#550

Merged

19 tasks

wanwiset25 pushed a commit to XinFinOrg/XDPoSChain that referenced this pull request Jun 19, 2024

rpc: Add admin_addTrustedPeer and admin_removeTrustedPeer. (ethereum#…

f3557e3

…16333)

wanwiset25 pushed a commit to XinFinOrg/XDPoSChain that referenced this pull request Jun 28, 2024

rpc: Add admin_addTrustedPeer and admin_removeTrustedPeer. (ethereum#…

e65b81a

…16333)

wanwiset25 added a commit to XinFinOrg/XDPoSChain that referenced this pull request Aug 23, 2024

Revert "rpc: Add admin_addTrustedPeer and admin_removeTrustedPeer. (e…

bdf38f8

…thereum#16333)" This reverts commit e65b81a.

wanwiset25 pushed a commit to XinFinOrg/XDPoSChain that referenced this pull request Oct 10, 2024

rpc: Add admin_addTrustedPeer and admin_removeTrustedPeer. (ethereum#…

9799f86

…16333)

gzliudan mentioned this pull request Nov 8, 2024

rpc: add admin_addTrustedPeer and admin_removeTrustedPeer XinFinOrg/XDPoSChain#731

Merged

19 tasks

gzliudan added a commit to gzliudan/XDPoSChain that referenced this pull request Nov 13, 2024

rpc: Add admin_addTrustedPeer and admin_removeTrustedPeer. (ethereum#…

f9f172a

…16333)

Conversation

shazow commented Mar 18, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

shazow commented Mar 22, 2018

Uh oh!

shazow commented Apr 3, 2018

Uh oh!

shazow commented Apr 30, 2018

Uh oh!

holiman commented May 17, 2018

Uh oh!

holiman commented May 17, 2018

Uh oh!

shazow commented May 17, 2018

Uh oh!

ryanschneider commented May 22, 2018

Uh oh!

holiman commented May 22, 2018

Uh oh!

zsfelfoldi left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

shazow commented Jun 7, 2018

Uh oh!

shazow commented Jun 7, 2018

Uh oh!

shazow commented Jun 8, 2018

Uh oh!

shazow commented Jun 15, 2018

Uh oh!

shazow commented Jun 21, 2018

Uh oh!

shazow commented Jul 30, 2018

Uh oh!

tinybike commented Jul 31, 2018

Uh oh!

zsfelfoldi commented Aug 6, 2018

Uh oh!

Choose a reason for hiding this comment

Uh oh!

zsfelfoldi left a comment

Choose a reason for hiding this comment

Uh oh!

shazow commented Aug 6, 2018

Uh oh!

evertonfraga commented Aug 24, 2018

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

8 participants

shazow commented Mar 18, 2018 •

edited

Loading