The maximum number of incoming streams doesn't need to be negotiated. It
is a value that is only announced by the peer, and has to be respected.
Furthermore, Chrome doesn't seem to care about the MSPC value anymore
(since MIDS was introduced), so there's no need to send this in the
handshake any more.
The params negotiator was just keeping track of the value set in the
quic.Config. The max flow control increments are not subject to
negotiation, but an independent implementation decision of every peer.
The idle timeout doesn't need to be negotiated, simply announcing it to
the peer is sufficient. We now close the session if there's no incoming
network activity for the duration of the local idle timeout, and we
send a PING frame after half the remote idle timeout (if keep alives are
enabled).
This simplifies the timeout logic a bit. Before the handshake has
completed, the only timeout is the handshake timeout. After the
handshake has completed, the only timeout is the idle connection timeout.
We were relying on the run-loop to set handshakeComplete to true, while
at the same time sending packets. select doesn't guarantee the order of
execution when multiple cases can run. The fix is setting
handshakeComplete to true directly.
There were several bugs here:
- We must always return an error when the peer tries to open a stream
from the wrong side.
- We must never return an error when GetOrOpenStream is called for a
stream that was already closed. GetOrOpenStream is called when a frame
on a stream is received, so this happens when we receive retransmissions
of STREAM frames for a closed stream. We only used to do that check for
peer-initiated streams, not for streams we opened ourselves.
This commit splits up handling of the crypto stream and the other streams in the framer, crypto setup, and the packer.
- Crypto stream data is handled separately and should never be sent unencrypted or FW-secure. Fixes#544.
- Non-crypto stream data is only sent with FW encryption on the server and only with non-FW or FW encryption on the client. Fixes#611.
The crypto stream is current excluded from flow control (#657), but that shouldn't be an issue in practice for now.
