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
We did the opposite thing of what the spec says to do. This meant that we would fail to hole-punch with rust nodes because both sides would attempt to be the dialer.
The spec is a bit confusing since roles get flipped in the middle. But essentially:
A connects to B.
B initiates the /libp2p/dcutr protocol.
After synchronizing, A and B dial each other. A is the client and B is the server.
This means the side handling the stream is the client, and the side initiating the stream should be the server.
#3044 exposes a flag to enable the spec behavior, but it is default set to legacy behavior. There are no backwards compatible migrations in that PR.
To close this issue we should implement a backwards compatible change. One suggestion by Sukun is:
On the side that in the new code will be the Server, can we add a random wait time after which the server will switch the role to Client and initiate the security negotiation?
The text was updated successfully, but these errors were encountered:
We did the opposite thing of what the spec says to do. This meant that we would fail to hole-punch with rust nodes because both sides would attempt to be the dialer.
The spec is a bit confusing since roles get flipped in the middle. But essentially:
/libp2p/dcutr
protocol.This means the side handling the stream is the client, and the side initiating the stream should be the server.
#3044 exposes a flag to enable the spec behavior, but it is default set to legacy behavior. There are no backwards compatible migrations in that PR.
To close this issue we should implement a backwards compatible change. One suggestion by Sukun is:
The text was updated successfully, but these errors were encountered: