aggressive open_bi

[szguoxz]

Streams are cheap and instantaneous to open unless blocked by flow control. As a consequence, the peer won’t be notified that a stream has been opened until the stream is actually used.

This feature causes me a bug, and took me hours to figure out.
The work around for me is to send a u8 when open_bi and read_u8 after accept_bi. If I don't do it, my accept_bi will got stuck.

Then I start to question of this design. Or, should we have an easy way to open an aggressive bi channel? So I don't have to do the write_u8, read_u8 hack?

[Ralith]

This is how QUIC works. The side which will first transmit on a stream should be the side responsible for opening it. This will be more prominently documented in the next release:

quinn/quinn/src/connection.rs

Lines 317 to 319 in 0e9a196

	/// **Important Note**: The `Connection` that calls [`open_bi()`] must write to its [`SendStream`]
	/// before the other `Connection` is able to `accept_bi()`. Calling [`open_bi()`] then
	/// waiting on the [`RecvStream`] without writing anything to [`SendStream`] will never succeed.

quinn/quinn/src/recv_stream.rs

Lines 31 to 38 in 0e9a196

	/// # Common issues
	///
	/// ## Data never received on a locally-opened stream
	///
	/// Peers are not notified of streams until they or a later-numbered stream are used to send
	/// data. If a bidirectional stream is locally opened but never used to send, then the peer may
	/// never see it. Application protocols should always arrange for the endpoint which will first
	/// transmit on a stream to be the endpoint responsible for opening it.