Open DAOCUONG opened 2 years ago
That's cool. And I have some suggestions:
And now, when a peer (called Alice) connected the seeds (called Carol), the seeds will share the DHT infos (Someone called Bob) to the peer, Alice will try connect to Bob by his NAT address, if success, it will connected directly, if not, it will use relay. So, the next work is when Alice connected to Carol, Carol will share the Bob to Alice, and Carol will also share Alice to Bob. Alice and Bob will try send data to others.
But I have an idea about the hole punching and relay. If Alice wants to connect Bob with stable connection, it is better: 1) connected directly, anyone has a public IP or hole punching success, 2) relay from Carol. If Alice not wants to stable connection, and if they have public IP, they can connected to help build the DHT. But if they not have, maybe not need to hole punching for reducing the resources.
@sunhuachuang do we have message for sharing DHT Tablet yet? Relay node should have DHT record for alice and bob can alice ask relay node to share the DHT records?
@sunhuachuang
Yep, We had the DHT share functions, https://github.com/CympleTech/chamomile/blob/main/src/server.rs#L285 and https://github.com/CympleTech/chamomile/blob/main/src/session.rs#L847
I would like to help implement hole punching for understanding i think we need stun server to know peer public ip and port. Client will send udp packing to server with port and adding it public ip and address to DHT So that others can connect directly to it.
1)The two peers both open a UDP socket bound to a random local port The two peers both contact a server on the internet. This server responds and tells them what IP and port their packet was received from. Since the server is on the Internet the IP/port seen by the server is the external IP and port 2)The two peers exchange information about the external IPs and ports through some mechanism. The two peers start trying to send UDP traffic to each other. 3)Hopefully the external IP and port used by the NAT for the traffic to the server are the same as the external IP and port used for the traffic sent towards the other peer. So once both peers have sent packets out through their NATs the incoming packets match the mappings and peer to peer communication is established.
Note: This strategy will work reliablly with full cone, restricted cone or restricted port cone NATs. It will work most of the time with port-preservative symmetric NATs. It will not work with randomising symmetric NATs.
Sun can you provide some guidance for this ???