You can clone with
HTTPS or Subversion.
Accept Limit vs Initial Limit
Currently an endpoint advertises what it is capable of accepting:
• When a client sends SETTINGS_MAX_CONCURRENT_STREAMS =123 it is saying that it will accept up to 123 concurrent pushed streams.
• When a server sends SETTINGS_MAX_CONCURRENT_STREAMS =123 it is saying that it will accept up to 123 concurrent HTTP request streams.
Are there scenarios for an endpoint to advertise what it is capable of issuing? For example, is it useful for a server to know that a client will issue at most 123 concurrent HTTP request streams? Or is it useful for a client to know that a server will issue at most 123 concurrent push streams? If the answer is "no", then we can avoid complicating the protocol.
There is a race condition where the client can issue more streams to the server before the server can advertise its accept limit to the client. Note that a race condition in the reverse path is not possible because a client must issue a SYN_STREAM before the server can push anything, which means it can definitely send the initial SETTINGS frame before emitting the first SYN_STREAM. (And in the future, it will be mandatory for the client to send the SETTINGS frame upon connection) Furthermore, there is no clear rationale for the value of SETTINGS_MAX_CONCURRENT_STREAMS to “be no smaller than 100”. To offer clearer requirements, the following is suggested:
A server MUST be able to handle at least 8 concurrent streams initiated by the client. A server MUST NOT advertise a value less than 8. A client MUST generate a session error if it receives a value less than 8 from the server. The default value emitted by servers is 8. The default value emitted by clients is 0. It is recommended that servers pick a much larger value to allow parallelism.
This ensures that there is a minimum value so that we don’t fall into a race hole but is large enough so that client is not bottlenecked on RTT for the initial requests. A default client-side of 0 means the communication defaults to no-push. That is, a smart client has to proactively advertise a non-zero value for the server to enable push.
Could you please bring these up on the list? Otherwise they'll hide in the issues list.
Also, in the future, if things are separable as different issues, please make them so. E.g., here, I would have liked to see at least two issues; one for the minimum number of client-initiated streams, the other for defaulting to no-push.
I talked to Brian. Let's dedicate this issue #38 to "minimum number of client-initiated streams". And I'll create a new issue for focusing on "defaulting to no-push". And I'll bring both up to the mailing list.
Clarifying the use of SETTINGS_MAX_CONCURRENT_STREAMS. Related to, bu…
…t not a solution for #38.
For "minimum number of client-initiated streams", there is no requirement at this time to support this scenario and complicate the protocol. Closing.