Track the accept backlog and add an upper limit

[thomaseizinger]

See libp2p/specs#471 (comment).

[thomaseizinger]

Now that we have landed the refactoring, this is relatively easy to implement. We just need to track the ACK backlog internally (i.e. the number of streams we have opened but the remote has not yet acknowledged). Once that number reaches 256, we should return Poll::Pending from poll_new_outbound: https://github.com/libp2p/rust-yamux/blob/master/yamux/src/connection.rs#L160

[mxinden]

We just need to track the ACK backlog internally (i.e. the number of streams we have opened but the remote has not yet acknowledged). Once that number reaches 256, we should return Poll::Pending from poll_new_outbound: https://github.com/libp2p/rust-yamux/blob/master/yamux/src/connection.rs#L160

This would be step (1), i.e. the sender side.

Step (2) would be to implement the listener side. If I am not mistaken we acknowledge new incoming streams right away (please double check whether this is correct). Instead we should only acknowledge a new incoming stream once it has been passed to the user via Connection::poll_next_inbound.

[thomaseizinger]

We just need to track the ACK backlog internally (i.e. the number of streams we have opened but the remote has not yet acknowledged). Once that number reaches 256, we should return Poll::Pending from poll_new_outbound: https://github.com/libp2p/rust-yamux/blob/master/yamux/src/connection.rs#L160

This would be step (1), i.e. the sender side.

Step (2) would be to implement the listener side. If I am not mistaken we acknowledge new incoming streams right away (please double check whether this is correct). Instead we should only acknowledge a new incoming stream once it has been passed to the user via Connection::poll_next_inbound.

I think we implicitly do that already by acknowledging it with the first Data frame that is sent on the stream, i.e. not until the user actually uses the stream.

We should confirm this with a test.