-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Signalling for Hole Punching #1057
Signalling for Hole Punching #1057
Conversation
config/config.go
Outdated
if cfg.EnableHolePunching && !cfg.Relay { | ||
return nil, errors.New("cannot enable hole punching; relay is not enabled") | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should enable this by default; but maybe that's for later, after we've done phase 1 testing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So this check gets in the way for testing with limited relays, as we will have the v1 relay disabled in this case.
const ( | ||
protocol = "/libp2p/holepunch/1.0.0" | ||
maxMsgSize = 4 * 1024 // 4K | ||
holePunchTimeout = 2 * time.Minute |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this also needs to be dialed down me thinks.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Keeping this to 1 minute for now. Can always fix after the alpha testing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@vyzo Addressed feedback and the PR is now open against a Staging branch.
const ( | ||
protocol = "/libp2p/holepunch/1.0.0" | ||
maxMsgSize = 4 * 1024 // 4K | ||
holePunchTimeout = 2 * time.Minute |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Keeping this to 1 minute for now. Can always fix after the alpha testing.
If you can find the time, it would be great to have your review on this one and it's not a big PR. |
@vyzo Looks like we are ready to go. Not merging though till I finish writing some solid unit tests. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
An important detail re: the implementation of QUIC hole punching with the use of the SimultaneousConnect option.
I am working on that, but the code here will need to change.
} | ||
|
||
func (hs *HolePunchService) holePunchConnectWithBackoff(pi peer.AddrInfo) { | ||
forceDirectConnCtx := network.WithForceDirectDial(hs.ctx, "hole-punching") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we also need WithSimultaneousConnect
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done.
@vyzo I'll block on this PR till you have the QUIC changes merged and we can then revisit this. |
they don't need to merge, just have an open pr for testing, ETA shortly. |
@aarshkshah1992 we are ready with the QUIC pr; let's test to see whether it works, and then we can merge that. |
|
||
// Close closes the Hole Punch Service. | ||
func (hs *HolePunchService) Close() error { | ||
hs.closeSync.Do(func() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The cancel func can be called multiple times. I believe that allows you to get rid of this Once here.
msg := new(pb.HolePunch) | ||
msg.Type = pb.HolePunch_CONNECT.Enum() | ||
msg.ObsAddrs = addrsToBytes(hs.ids.OwnObservedAddrs()) | ||
if err := w.WriteMsg(msg); err != nil { | ||
s.Reset() | ||
log.Errorf("failed to send hole punch CONNECT, err: %s", err) | ||
return | ||
} | ||
tstart := time.Now() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the start of the RTT measurement has to move before writing the message I think.
if err := rd.ReadMsg(msg); err != nil { | ||
s.Reset() | ||
log.Errorf("failed to read connect message from remote peer, err: %s", err) | ||
return | ||
} | ||
if msg.GetType() != pb.HolePunch_CONNECT { | ||
s.Reset() | ||
log.Debugf("expectd HolePunch_CONNECT message, got %s", msg.GetType()) | ||
return | ||
} | ||
obsRemote := addrsFromBytes(msg.ObsAddrs) | ||
rtt := time.Since(tstart) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
and the end of the RTT measurement has to move right after reading the message.
Note: we'll have to update the QUIC Hole Punching coordination logic if / when libp2p/go-libp2p-quic-transport#210 is merged. |
Question on retry procedure I wonder whether I am understanding the retry procedure implemented in this pull request correctly. Is the following a good summary?
In case the above is correct, I wonder why the two peers do not go through the @vyzo @aarshkshah1992 can you help me out here? |
I think it might make sense to implement it the way you suggest, with
another sync round to compute a the rtt anew.
…On Thu, Aug 12, 2021, 13:23 Max Inden ***@***.***> wrote:
*Question on retry procedure*
I wonder whether I am understanding the retry procedure implemented in
this pull request correctly. Is the following a good summary?
1. Both peers exchange the CONNECT and SYNC messages as described in
libp2p/specs#173 <libp2p/specs#173>.
2. Both peers, A on receiving the SYNC, B on RTT/2, try to connect to
the other.
3. On failure a peer retries to connect up to 5 times with a wait of 2
* time.Second between each attempt.
In case the above is correct, I wonder why the two peers do not go through
the CONNECT and SYNC procedure for each retry. Doing an additional CONNECT
and SYNC for each retry would prevent a flawed RTT measurement on the
first attempt to badly influence all following retry attempts.
@vyzo <https://github.com/vyzo> @aarshkshah1992
<https://github.com/aarshkshah1992> can you help me out here?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1057 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAI4SUXPCN43KHEIRTWXV3T4OOJFANCNFSM4X3WENDQ>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email>
.
|
Closing, since #1168 has been merged (into the feature branch at least). |
For #1039.
@vyzo
Replaces #711 to make it easier to review.
Based on https://github.com/libp2p/specs/pull/173/files.
TODO