clarify "when a handshake is sent, it is sent on all known paths"
dvanduzer opened this issue · 2 comments
The handshake doc refers to a "keepalive handshake" so perhaps there is some additional qualification needed about transport maintenance?
"At any point the transport being used to deliver packets may generate a keepalive handshake request which will start this process."
What are the circumstances a transport can/should do this, and what are the situations where a transport isn't allowed to do this? (e.g. if a Bluetooth radio suddenly reactivates, can it trigger a downgrade to CS1a because it's fresher than a wifi-based CS3a exchange?)
(maybe i'm also suggesting that exchange needs to track information about flapping CS & at values?)
edit: now i'm theorizing a logic bug in underspecified timeout behavior in udp and other transports.