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
{{ message }}
This repository was archived by the owner on Aug 11, 2020. It is now read-only.
There are several timers/timeouts that are relevant in a QUIC session...
The retransmission timer monitors when packets may need to be retransmitted.
The idle timer monitors lack of activity and will shut down the connection silently if there is no activity.
Another timer that we need but don't yet have is a connection/handshake timer. Specifically, it should start when a QuicSession is created and clear when the TLS handshake is completed (signaling successful establishment of the connection).
When the connection / handshake timer fires, we need to decide whether to: (a) allow the user to determine the next action, (b) attempt to tear down the QuicSession with an ImmediateClose() (which will attempt to send a CONNECTION_CLOSE to the peer, or (c) attempt to tear down the QuicSession with a SilentClose() which will tear down the QuicSession without attempting to notify the peer.
Option 2 is ideal because we want to be able to tell the peer that we're abandoning the connection but it is problematic because lack of communication with the peer might be what caused the handshake timer to fire -- that is, it might not be possible to notify the peer. I'm thinking that Option 1 is likely the best choice -- essentially, just allow the user to determine what to do.
There are several timers/timeouts that are relevant in a QUIC session...
The retransmission timer monitors when packets may need to be retransmitted.
The idle timer monitors lack of activity and will shut down the connection silently if there is no activity.
Another timer that we need but don't yet have is a connection/handshake timer. Specifically, it should start when a
QuicSession
is created and clear when the TLS handshake is completed (signaling successful establishment of the connection).When the connection / handshake timer fires, we need to decide whether to: (a) allow the user to determine the next action, (b) attempt to tear down the
QuicSession
with anImmediateClose()
(which will attempt to send aCONNECTION_CLOSE
to the peer, or (c) attempt to tear down theQuicSession
with aSilentClose()
which will tear down theQuicSession
without attempting to notify the peer.Option 2 is ideal because we want to be able to tell the peer that we're abandoning the connection but it is problematic because lack of communication with the peer might be what caused the handshake timer to fire -- that is, it might not be possible to notify the peer. I'm thinking that Option 1 is likely the best choice -- essentially, just allow the user to determine what to do.
Related: #39
The text was updated successfully, but these errors were encountered: