Currently we limit the connection in the same NAT address: only one connection is allowed .
/// Checks whether there's any reason we don't want to accept an incoming peer
/// connection. There can be a few of them:
/// 1. Accepting the peer connection would exceed the configured maximum allowed
/// inbound peer count. Note that seed nodes may wish to increase the default
/// value for PEER_LISTENER_BUFFER_COUNT to help with network bootstrapping.
/// A default buffer of 8 peers is allowed to help with network growth.
/// 2. The peer has been previously banned and the ban period hasn't
/// expired yet.
/// 3. We're already connected to a peer at the same IP. While there are
/// many reasons multiple peers can legitimately share identical IP
/// addresses (NAT), network distribution is improved if they choose
/// different sets of peers themselves. In addition, it prevent potential
/// duplicate connections, malicious or not.
fn check_undesirable(&self, stream: &TcpStream) -> bool {
At this moment, I don't want to change this behaviour, but In case someone have multiple node servers running in the same NAT, these servers can't connect to each other because above limitation.
A simple solution to solve this is to use the SSDP (Simple Service Discovery Protocol), allowing the node servers discovery each other in same LAN and connect each other.
Currently we limit the connection in the same NAT address: only one connection is allowed .
At this moment, I don't want to change this behaviour, but In case someone have multiple node servers running in the same NAT, these servers can't connect to each other because above limitation.
A simple solution to solve this is to use the SSDP (Simple Service Discovery Protocol), allowing the node servers discovery each other in same LAN and connect each other.
A Rust SSDP crate can be used for this: https://github.com/GGist/ssdp-rs
Note: To avoid the LAN ip address publishing to peers network, the
GetPeerAddrsprotocol response should skip all these LAN ip addresses.