Ben Christensen

Thus: ```cpp enum class StreamCompletionSignal { COMPLETE, APPLICATION_ERROR, REJECTED, CANCELED, INVALID, }; ```

Consider this example: - REQUEST_STREAM(A) from client to server with N == 10 - server starts sending items that are 10MB each (fragmented however it wishes) - client is slowly...

As the HTTP/2 spec states: > Flow control operates at two levels: on each individual stream and on the entire connection. https://httpwg.github.io/specs/rfc7540.html#WINDOW_UPDATE and: > Using streams for multiplexing introduces contention...

> I am on the fence for defaulting to a lower data size than frame size (currently max of ~2GB) for this reason as it would also be a function...

I understand this is different from what TCP does, and I'm not claiming to reinvent congestion control. That's a whole different discussions for things like QUIC, Sprout, Giga, etc. I'm...

The WINDOW_UPDATE and prioritization aspects of HTTP/2 are separate. An "elephant flow" on a single multiplexed stream can starve the other multiplexed streams. That's what I'm trying to solve. REQEUST_N...

@tmontgomery Is there anything about this that we should address?

Do these slides correctly represent the relationship of TCP, HTTP/2, and ReactiveSocket? And if so, does ReactiveSocket actually need yet another?     ![reactivesocket-dec2016...

@nickgg How do you suggest the blending should occur considering the sequences involve more than one frame?

Is this still applicable?