Change maxPrunePeers and maxPeersPerPruneMessage usage

[diegomrsantos]

Seems maxPeersPerPruneMessage should be used to limit the amount of peers allowed in a Prune message received and maxPrunePeers should be used to limit the amount of peers sent.

[diegomrsantos]

@Nashatyrev please review if it makes sense.

[Nashatyrev]

Hm, it's actually weird that:

• we are having 2 params to control that
• their ambiguous names
• they used incorrectly (this is what you are fixing)

I would ideally left just one param to both

• validate the number in inbound list
• limit the number of outbound

But the potential problem is that nodes based on earlier version and sending the unlimited list would be banned by nodes based on latter jvm-Libp2p versions. In other words I would try to avoid the particular situation when newer Teku nodes would ban older Teku nodes.

Because of that I would propose the following:
1 phase (for this PR):

• leave 2 parameters however maybe rename them. Maybe like: maxPrunePeersOutbound/maxPrunePeersInbound or whatever
• leave maxPrunePeersInbound == null (i.e. unbounded) for now for the reason I've mentioned above

2 phase (for the future PR when the first fix is adopted by the majority):

• leave just a single param maxPrunePeers

@diegomrsantos what do you think on this?

[diegomrsantos]

I think it's a good plan.

leave 2 parameters however maybe rename them. Maybe like: maxPrunePeersOutbound/maxPrunePeersInbound or whatever

How about those names maxPeersSentInPruneMsg and maxPeersAcceptedInPruneMsg?

leave maxPrunePeersInbound == null (i.e. unbounded) for now for the reason I've mentioned above

We could also set a default value for maxPeersAcceptedInPruneMsg here and set it to max Integer on Teku in phase 1.

What do you think?

[Nashatyrev]

How about those names maxPeersSentInPruneMsg and maxPeersAcceptedInPruneMsg?

Sounds good to me 👍

We could also set a default value for maxPeersAcceptedInPruneMsg here and set it to max Integer on Teku in phase 1.

What do you think?

Yeah, great idea!

[diegomrsantos]

Additionally, how would you test it?

[Nashatyrev]

Additionally, how would you test it?

You may want to check GossipV1_1Tests. Would be great if you add a unit test 👍

[diegomrsantos]

I added a test for maxPeersSentInPruneMsg, please review it. But not sure how to do it for maxPeersAcceptedInPruneMsg.

[Nashatyrev]

I added a test for maxPeersSentInPruneMsg, please review it. But not sure how to do it for maxPeersAcceptedInPruneMsg.

Thanks for the test 👍
Here is the one for the other param: diegomrsantos#1

[Nashatyrev]

LGTM

Just check and maybe merge another test I've suggested

[Nashatyrev]

nit: that take() call seems to have no effect (as a message exceeding the limit should be dropped before), but I would probably leave it just to be safe in case of future modifications

[diegomrsantos]

@Nashatyrev Thanks for merging it. I would like to create a PR to set the new parameters on Teku. How should I proceed about updating the jvm-libp2p version there?