You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm not an expert on this field, maybe I have lots of misunderstanding.
Any correction is welcome!
Motivation
Most computers in the world are behind some kind of NAT. The main restriction
or disadvantage for a Device under a NAT is that it cannot accept outbound
connections.
The establishment of a P2P network requires direct connection between any two
nodes.
CKB, as a network service that based on P2P network, also has to face such
generic peer-to-peer problems.
Proposals
I have 2 proposals to improve P2P over NAT.
Proposal 1. Enhance Built-in P2P Discovery Function
After reading several articles about file sharing technologies12, I
summarized a series of common steps that establish a P2P connection behind
NATs:
If all above protocols are not available, tries to do Hole Punching.
Hole Punching works on the assumption, that a NAT/firewall is configured to
allow outbound connections, but not inbound.
So, making outbound connection attempts from both devices to each other,
could cause the NAT/firewall on both sides to detect an (approved) outgoing
connection, which will then unblock the flow of data, enabling an actual
connection handshake.
As some articles mentioned, this technique works fine within a CGNAT3.
All of those P2P services are support NAT traversal.
Build our P2P connections over those services, NAT traversal would be
supported.
There is another challenge: for clients in network-restrictive countries or
regions (e.g. GFW), launch these P2P service over a VPN is required.
So, proxy support should be built-in in Tentacle, and when to use a proxy
should be configured: just when launch Tentacle, or whole time for all
connections over those external P2P services.
Tasks
I split this improvement into several tasks:
Enhance Built-in P2P Discovery Function
Automatic Port Forwarding
🚧 I have to learn more on them.
A sends S a request, that A want to build a connection with B.
S sends A’s address to B and B’s address to A.
A and B sends a message to each other.
A and B sends a message to each other, again.
Connection between A and B established.
Here is only the simplest description, some security issues should be
considered, for example, A (or B) shouldn't believe peers which given by S
simply.
The discussion of security part will be in the sub-issue.
P2P over NAT Improvement
Note
I'm not an expert on this field, maybe I have lots of misunderstanding.
Any correction is welcome!
Motivation
Most computers in the world are behind some kind of NAT. The main restriction
or disadvantage for a Device under a NAT is that it cannot accept outbound
connections.
The establishment of a P2P network requires direct connection between any two
nodes.
CKB, as a network service that based on P2P network, also has to face such
generic peer-to-peer problems.
Proposals
I have 2 proposals to improve P2P over NAT.
Proposal 1. Enhance Built-in P2P Discovery Function
After reading several articles about file sharing technologies12, I
summarized a series of common steps that establish a P2P connection behind
NATs:
First, tries UPnP IGD Protocol, NAT Port Mapping Protocol and
Port Control Protocol to do automatic port forwarding.
🚧 I have to learn more on them.
If all above protocols are not available, tries to do Hole Punching.
Hole Punching works on the assumption, that a NAT/firewall is configured to
allow outbound connections, but not inbound.
So, making outbound connection attempts from both devices to each other,
could cause the NAT/firewall on both sides to detect an (approved) outgoing
connection, which will then unblock the flow of data, enabling an actual
connection handshake.
As some articles mentioned, this technique works fine within a CGNAT3.
UDP hole punching is preferred.
Proposal 2. Support External P2P Services
In BIP-0155, there are 4 external P2P services are mentioned: Tor, I2P,
Cjdns and Yggdrasil.
All of those P2P services are support NAT traversal.
Build our P2P connections over those services, NAT traversal would be
supported.
There is another challenge: for clients in network-restrictive countries or
regions (e.g. GFW), launch these P2P service over a VPN is required.
So, proxy support should be built-in in Tentacle, and when to use a proxy
should be configured: just when launch Tentacle, or whole time for all
connections over those external P2P services.
Tasks
I split this improvement into several tasks:
Enhance Built-in P2P Discovery Function
Automatic Port Forwarding
🚧 I have to learn more on them.
Hole Punching
A new protocol should be added into CKB/Network:
Here is only the simplest description, some security issues should be
considered, for example, A (or B) shouldn't believe peers which given by S
simply.
The discussion of security part will be in the sub-issue.
Support External P2P Services
References
Documents:
Libraries:
Some P2P networks and clients which inspired me:
Thanks
@
driftluo, who answered punch of my questions about Tentacle.Footnotes
Why device behind NAT is sometimes connected without relays in Syncthing? ↩
Clever tricks to solve some generic P2P problems in Crust (Safe Network) ↩
Carrier-Grade NAT ↩
The text was updated successfully, but these errors were encountered: