Go-ethereum: cmd/geth: --lightpeers does not limit light peer connections

[lmars]

System information

Geth
Version: 1.7.3-stable
Git Commit: 4bb3c89d44e372e6a9ab85a8be0c9345265c763a
Architecture: amd64
Protocol Versions: [63 62]
Network Id: 1
Go Version: go1.9.2
Operating System: linux

Expected behaviour

As per the usage, --lightpeers is supposed to represent:

Maximum number of LES client peers

so I would expect that running geth with --maxpeers 25 --lightserv 25 --lightpeers 20 means I have at most 20 light peers at any one time, leaving 5 slots to connect to full nodes to get new blocks.

Actual behaviour

I have 25 light peers and no full peers:

$ geth attach --exec 'for(i in admin.peers) { console.log(admin.peers[i].caps) }' | grep -v undefined | sort | uniq -c
     20 les/1
      5 les/1,les/2

Steps to reproduce the behaviour

Run geth with --maxpeers 25 --lightserv 25 --lightpeers 20 and observe admin.peers after a while.

[karalabe]

Your script only tests if there's les capability with your peers. You might be connected on eth too with them, which would make the issue a non issue.

[lmars]

@karalabe but then wouldn't I see eth/NN in the caps list? When my node is in this state, it stops getting new blocks and falls behind.

[karalabe]

Ah, that's indeed a problem then. @zsfelfoldi ?

[lmars]

Looking at the code, it seems that --lightpeers just reduces the max number of full peers, but does not limit the number of light peers, should it not be the other way around?

[GoodMirek]

Same issue observed here.
instance=Geth/v1.8.0-unstable-3f40b22d/linux-amd64/go1.9.2

[holiman]

I assigned @zsfelfoldi just now. Could you please TAL at and fix this so that

• The lightpeers does not automatically decrease the number of real peers,
• But instead acts as a cap on the number of light peers allowed.

[veox]

@lmars I believe this has been implemented in PR #16010.

[karalabe]

Yup.