-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
NAT traversal using hole punching #61
Comments
@geoffxy Do we have to use UDP? I read through the abstract + intro of the paper you linked in Slack. It seems that although the % of networks that allow hole punching through TCP is lower, it is still possible. TCP guarantees reliability so we won't have to worry too much about network issues afterwards. |
We'd need to test out TCP hole punching to see how reliable it is. It seems like UDP hole punching is what works most frequently, which would be more useful to us in establishing the connections. Though if we can get TCP hole punching working reliably it would probably be less work on the agent's side in terms of not having to switch the transport and not having to think too much about message size. From this, it looks like UDP's reliability isn't that bad though. http://openmymind.net/How-Unreliable-Is-UDP/ The CRDT should be resilient to reordering. The only problem will be inconsistencies due to lost messages. |
@typeintandem/lightly I think we can close this and move the keep-alive messages to a non-launch blocking issue. |
Moving everything in here over to Milestone 5 for housekeeping, closing down Milestone 3. |
The text was updated successfully, but these errors were encountered: