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
With the recent integration of #96 / #102 -- we no longer hang the whole application while waiting for a handshake. But, handshaking of TCP, TLS+TCP, and IPC should complete in a timely fashion, and we should add a timeout that closes connections from peers that do not complete the handshake within a modest period of time.
We propose to set this to 5 seconds by default. Satellite connections can have very long (500ms or so) latencies, but 5 seconds should be sufficient for everywhere in local Earth orbit. Latency to the moon is about 1.3 sec.
One thing we could do to make this a little more forgiving is require forward progress, so that the handshake doesn't timeout in 5 absolute seconds, but times out if no progress is seen for 5 seconds.
This issue does not intend to address timeouts on established connections. That's an orthogonal issue and should be treated separately.
The text was updated successfully, but these errors were encountered:
5 seconds is probably not sufficient for all use cases. Satellite latencies can approach 2 seconds. This is fairly abysmal, but we'll want to set the default a bit higher. NNG chose 10 seconds.
With the recent integration of #96 / #102 -- we no longer hang the whole application while waiting for a handshake. But, handshaking of TCP, TLS+TCP, and IPC should complete in a timely fashion, and we should add a timeout that closes connections from peers that do not complete the handshake within a modest period of time.
We propose to set this to 5 seconds by default. Satellite connections can have very long (500ms or so) latencies, but 5 seconds should be sufficient for everywhere in local Earth orbit. Latency to the moon is about 1.3 sec.
One thing we could do to make this a little more forgiving is require forward progress, so that the handshake doesn't timeout in 5 absolute seconds, but times out if no progress is seen for 5 seconds.
This issue does not intend to address timeouts on established connections. That's an orthogonal issue and should be treated separately.
The text was updated successfully, but these errors were encountered: