Distinguish between two types of p2p nodes

[hashmap]

In peer to peer network nodes act as clients (initiates a connection) and servers (accepts connections) at the same time. However in reality some nodes can't play both roles, because they are behind nat/firewall etc.

We may want to distinguish between fully capable nodes (supernodes) and restricted ones. Why it may be useful?

• It doesn't make sense to advertise restricted nodes in peer discovery, it's impossible to connect to them.
• Two kinds of limit for peers number may be needed. When we start our node we are selfish and need to take some reasonable amount of peers, so we connect to supernodes, theoretically we can reach our peers number limit on that stage. However if we are a supernode it makes sense to reserve some number of slots for restricted nodes as a community service
• It's needed for (future) p2p routing. To send a message (eg tx slate) to a peer behind the nat which we are not connected to we need to find a supernode which has such connection already, so this type of discovery would benefit from it (similar to the first point).

To achieve this goal I'd suggest to extend Direction enum, now it has 2 variants Inbound and Outbound. Currently it reflects the fact which node initiated connection. We could add Duplex and treat it a bit differently:

• Inbound - a restricted node connected to a supernode (us)
• Outbound - a restricted node (we) connected to a supernode
• Duplex - two supernodes connected

During the handshake a peer which accepts the connection tries to establish a new connection to the client and if it succeeds closes the socket and marks the peer's direction as Duplex.

Only Duplex peers are discoverable in regular peer discovery we have now and future route discovery.

What do you think?

[quentinlesceller]

Very interesting idea @hashmap. I wonder if other cryptocurrencies have implemented such logic? Also could we simply check with a basic handshake if an Inbound peer is reachable before advertising it?

[hashmap]

It’s in my weekend reading/watching list.

Yes, that’s what I tried to describe, we need to open a backward connection for a short period of time for that.

[garyyu]

How about add NAT feature and make all nodes support Duplex? instead of increasing node type complexity.

[hashmap]

You mean NAT traversal? I spent some time researching it, currently I'm not sure we should support it at the moment.

• It's very complex, there are many types of NAT https://en.wikipedia.org/wiki/Network_address_translation#Methods_of_translation - full-cone, restricted-cone, port-restricted and notorious symmetric NAT. They requires different techniques https://en.wikipedia.org/wiki/NAT_traversal#Techniques few work well with symmetric NAT, those which works does things like sending packets to 1000 ports http://www.goto.info.waseda.ac.jp/%7Ewei/file/wei-apan-v10.pdf

• It may not work for particular user, NAT traversal is a probabilistic process, besides NAT we need to deal with firewalls etc. So in general relays for such nodes should still be supported. It's much more complex to support 2 methods, usually it makes sense for applications which need low latency (games, voip) where relay is the last resort. For us low latency is needed just for (competitive) miners, but for them it's doable to get a public IP, anyway they may require even more sophisticated solutions like bitcoin relay network/fibre etc.

• Implementation complexity. Unfortunately rust nat traversal libraries from low level ustulation/p2p https://github.com/ustulation/p2p to high-level maidsafe/crust https://github.com/maidsafe/crust rely on async io (mio/tokio) which doesn't play well with our p2p stack.

So as bare minimum we need to support restricted nodes, nat traversal would be a nice addition.

[sesam]

Useful, and we can implement this incrementally. No new wire protocol assumptions, right? If we short term complicate peer directory, it can be changed without partitioning the network. Realistically it'll get even more complex with optimal NAT STUN etc.

Also remember that Dandelion stem connection choice still needs to know it doesn't pick for outgoing stem path a node that "called us". Because it is then too easy to be a Sybil.

[dewdeded]

A common way (a lot of coins and projects do that) to make nodes, that can't be reached inbound over the public internet, into a "full" bi-directional nodes: 1.) Is by using an IP overlay network (like TOR, I2P) or/and 2.) an rendezvous protocol (e.g. SIP, Freenet, JXTA).

[ignopeverell]

It seems straightforward enough, but I'm not sure it leads to a fruitful longer-term path. So now you have a network of "supernodes" that can do routing. Do you make everyone route for you, opening yourself to spam? Or do assign minimal point-to-point routes? Either way it seems it'll become more complex than STUN, UDP hole punching or any of those rather quickly.