P2P does acquire new sessions and drop them because of duplication

[SurfingNerd]

this happens in an endless loop.
Example:

2025-05-20 05:07:37  Worker devp2p2 TRACE network  0xc772…be13: Connecting to 194.233.75.136:27217
2025-05-20 05:07:37  Worker devp2p3 TRACE network  Received handshake ack from "194.233.75.136:27217"
2025-05-20 05:07:37  Worker devp2p3 TRACE network  Received EIP8 handshake auth from "194.233.75.136:27217"
2025-05-20 05:07:37  Worker devp2p3 TRACE network  Session read error: 6:Some(0xc772a3c324db7cea3bd234493afdb96724e1d48993e52ed97ef8bc8cf3709833d2be5c579866fa738f5ce29660f855131a0bad28c8482060ecee6a5a0678be13) (Ok(194.233.75.136:27217)) Error(Disconnect(DuplicatePeer), State { next_error: None, backtrace: InternalBacktrace { backtrace: None } })
2025-05-20 05:07:38  Worker devp2p2 TRACE network  0xc772…be13: Connecting to 194.233.75.136:27217
2025-05-20 05:07:38  Worker devp2p3 TRACE network  Received handshake ack from "194.233.75.136:27217"
2025-05-20 05:07:38  Worker devp2p3 TRACE network  Received EIP8 handshake auth from "194.233.75.136:27217"
2025-05-20 05:07:39  Worker devp2p1 TRACE network  Session read error: 3:Some(0xc772a3c324db7cea3bd234493afdb96724e1d48993e52ed97ef8bc8cf3709833d2be5c579866fa738f5ce29660f855131a0bad28c8482060ecee6a5a0678be13) (Ok(194.233.75.136:27217)) Error(Disconnect(DuplicatePeer), State { next_error: None, backtrace: InternalBacktrace { backtrace: None } })
2025-05-20 05:07:39  Worker devp2p2 TRACE network  0xc772…be13: Connecting to 194.233.75.136:27217
2025-05-20 05:07:39  Worker devp2p2 TRACE network  Received handshake ack from "194.233.75.136:27217"
2025-05-20 05:07:39  Worker devp2p2 TRACE network  Received EIP8 handshake auth from "194.233.75.136:27217"
2025-05-20 05:07:39  Worker devp2p3 TRACE network  Session read error: 6:Some(0xc772a3c324db7cea3bd234493afdb96724e1d48993e52ed97ef8bc8cf3709833d2be5c579866fa738f5ce29660f855131a0bad28c8482060ecee6a5a0678be13) (Ok(194.233.75.136:27217)) Error(Disconnect(DuplicatePeer), State { next_error: None, backtrace: InternalBacktrace { backtrace: None } })
2025-05-20 05:07:40  Worker devp2p1 TRACE network  0xc772…be13: Connecting to 194.233.75.136:27217
2025-05-20 05:07:40  Worker devp2p2 TRACE network  Received handshake ack from "194.233.75.136:27217"
2025-05-20 05:07:40  Worker devp2p2 TRACE network  Received EIP8 handshake auth from "194.233.75.136:27217"
2025-05-20 05:07:41  Worker devp2p3 TRACE network  Session read error: 3:Some(0xc772a3c324db7cea3bd234493afdb96724e1d48993e52ed97ef8bc8cf3709833d2be5c579866fa738f5ce29660f855131a0bad28c8482060ecee6a5a0678be13) (Ok(194.233.75.136:27217)) Error(Disconnect(DuplicatePeer), State { next_error: None, backtrace: InternalBacktrace { backtrace: None } })
2025-05-20 05:07:41  Worker devp2p2 TRACE network  0xc772…be13: Connecting to 194.233.75.136:27217
2025-05-20 05:07:41  Worker devp2p1 TRACE network  Received handshake ack from "194.233.75.136:27217"
2025-05-20 05:07:41  Worker devp2p1 TRACE network  Received EIP8 handshake auth from "194.233.75.136:27217"
2025-05-20 05:07:42  Worker devp2p2 TRACE network  Session read error: 8:Some(0xc772a3c324db7cea3bd234493afdb96724e1d48993e52ed97ef8bc8cf3709833d2be5c579866fa738f5ce29660f855131a0bad28c8482060ecee6a5a0678be13) (Ok(194.233.75.136:27217)) Error(Disconnect(DuplicatePeer), State { next_error: None, backtrace: InternalBacktrace { backtrace: None } })

There are already precautions done, that it does not happen, but it happens

diamond-node/crates/net/network-devp2p/src/host.rs

Lines 788 to 797 in de97f70

	fn connect_peer(&self, id: &NodeId, io: &IoContext<NetworkIoMessage>) {
	if self.have_session(id) {
	trace!(target: "network", "Aborted connect. Node already connected.");
	return;
	}
	if self.connecting_to(id) {
	trace!(target: "network", "Aborted connect. Node already connecting.");
	return;
	}

[diamond-info]

Shouldn't nodes sending unreliable data or operating inadequately be blocked for a certain time? This could solve the update problem when a small number of nodes switch to the new code, and most of the old nodes have not yet been updated and continue to send out old and now unreliable data.
At least two-level protection against large-scale network failure is needed. If a node is updated to the latest version, then the shared identifier (new ID key)* must first be checked, and if it does not match the new nodes, then receiving data from such nodes should be forcibly and fully blocked (consider this a Ddos attack on the updated nodes).
Only then should an additional temporary lock be applied in case of receiving invalid or error data from those nodes that have the correct identifier.

• In my understanding, an Id key is one or more checksums calculated from one or more main files after installing the updated node (automatically calculated when the node is started).
  Thus, it will be extremely difficult for an attacker to fake this value, since changing the data in the main files will not allow him get right sha 256 and simulate an updated node interacting correctly with the updated network.

[SurfingNerd]

We will reevaluate the requirement in 4.1