5 ms·
Awesome project, and a great README! How does it handle NATs? And, if I understand correctly, the receiver needs to enter `pcp receive` within 5 mins from the s
by wngr 6y ago
Awesome project, and a great README!
How does it handle NATs?
And, if I understand correctly, the receiver needs to enter `pcp receive` within 5 mins from the sender initiating the send? Seems a bit unergonomic. Anyway, why do you think that kind of "sharding" is necessary?
- dennis-tra 6y agoThanks @wngr! I really appreciate that this project gets a little attention. Libp2p provides ways to establish a connection through NATs. For more information I recommend looking up the Identify [0] and Circuit Relay [1] protocols, as well as the NAT Traversal docs [2]. I implemented time based sharding because the DHT entries will remain there for up to 24h. So there is a significant chance for a channel ID collision that would result in connection attempts to peers that are long gone. This is indeed a bit unergonomic and I haven’t covered edge cases that come with that approach. Open for suggestions :) Best [0] https://docs.libp2p.io/concepts/protocols/#identify https://docs.libp2p.io/concepts/protocols/#identify [1] https://docs.libp2p.io/concepts/protocols/#circuit-relay https://docs.libp2p.io/concepts/protocols/#circuit-relay [2] https://docs.libp2p.io/concepts/nat/ https://docs.libp2p.io/concepts/nat/
- kevincox 6y ago> within 5 mins from the sender initiating the send? Based on a strict reading of the readme you actually need to receive in the same 5min window. This means that you have at most 5min. If you send at the end of the window you can have less than a second. A simple solution is to have the sender always round up (to the end of the current 5min window) and have the receiver search for windows rounded up and down. (Or have the sender broadcast two and the receiver look for one) If you want more time the sender can keep broadcasting a new window every 5min until the receiver connects.
- dennis-tra 6y agoThat's indeed correct and was exactly what I meant with > I haven’t covered edge cases So, thanks for your suggested solution! I think that's how I would implement it as well. The receiver looks for two windows and the sender broadcasts new entries when 5min are over.