--reserved-peers connections drop

[stone212]

I'm running:

• Which Parity version?: 1.7.10
• Which operating system?: Linux
• How installed?: via installerbinaries
• Are you fully synchronized?: yes
• Which network are you connected to?: Private Blockchain
• Did you try to restart the node?: yes

On a private blockchain with 35 nodes, I have 6 bootnodes in the chain spec and two other reserved nodes, all 8 of these are listed in a reserved-peers.txt file, one enode on each line.

When I start another node with "parity --reserved-peers /path/to/reserved-peers.txt" I immediately get great connectivity (25 nodes) and then over a day or two it dwindles to about 4.

But it should bottom out at 8! because there are 8 nodes in reserved-peers.txt

I have tested network connectivity. Nodes can ping each other even when connectivity/peers is downto 4.

I have a thought but I have not found anything in the source code to back it up.

First, are there any rules of connectivity that supercede the reserved-peers? And if so is there a "cousin" rule? I see that Parity tries to swap out peers periodically. Maybe there is a rule that says "you can't dance with your cousin if you have danced with her in the past x hours" or maybe "you can't dance with your cousin if your other cousin already is dancing with her". ?

[5chdn]

This could be a bug, but can't tell without looking at your logs.

Can you run one of the nodes with -l sync=trace ?

[stone212]

Can you run one of the nodes with -l sync=trace ?

Yes but we've been through this before. Doing that generates a LOT of data. Gigabytes. How much of it do you want and how should I send it to you?

[stone212]

Also I'm starting to wonder if the devP2P rules simply supersede the --reserved-peers rule? Because I think the devP2P might have this behavior built in.

[5chdn]

Does it also drop without reserved peers? If yes, it's #7531

[stone212]

Does it also drop without reserved peers?

Yes, actually I had another open issue and you suggested I try with --reserved-peers to solve it.

If yes, it's #7531

That's a big jump. No only does #7531 use a different version of Parity but this issue here is a specific enough case that its cause could be different. Even if there is an underlying cause, this question I asked still would need to be answered because #7531 would not explain why --reserved-peers does not solve the issue as you once suggested. The question is:

Do the devP2P rules supersede the --reserved-peers rule? Because I think the devP2P might have this behavior built in, which would mean that this "issue" is to be expected and not any sort of bug.

Of course even if that is true, #7531 could still be an issue/bug. But if we can eliminate one thing, that would help. I am working on finding the answer in the source code but so far I have not found where the devP2P rules and --reserved-peers rules are given priority.