Open dennis-tra opened 1 year ago
Great improvement suggestion!
1/2 RTT A to B
+1/2 RTT B to its default gateway
-1/2 RTT A to its default gateway
.
I double checked the RTTs computations, and I get the same result.
In the case there are multiple firewalls between A
and The Internet
, A's gateway
should be considered to be the last interface connecting to the Internet, or the furthest firewall from A
. So, in short, the distance between a node and its gateway should be the ping distance between A
and its own observed public address.
As we were discussing protocol improvements in #487 I'm just leaving this here as a not fleshed-out food for thought:
Currently, the protocol has the hidden assumption that the RTT measurement from one node to the other is equivalent to the RTT between both NAT's. This assumption holds true for most home networks where the router is a millisecond away. However, for VPN'd peers it's likely not true.
Let's say
A
wants to hole-punchB
.A
opens a dcutr stream via a relaying peerR
and sends the firstCONNECT
message.B
replies with aCONNECT
message - but now, this message also contains the observed RTT ofB
to its default gateway (which could be a VPN exit node - not sure if default gateways == VPN exit nodes). In the meantimeA
has also measured the RTT to its default gateway. Upon receipt of the second CONNECT message atA
,A
knowsA
andB
,B
and its default gatewayA
sends out the SYNC message and in the current specificationA
would wait 1/2 the RTT betweenA
andB
(1.
). The change here would be to wait for:1/2 RTT A to B
+1/2 RTT B to its default gateway
-1/2 RTT A to its default gateway
.I hope, I got the different RTT's right.
cc @physikerwelt