A frame has a stream id (one signed byte). When sending request messages, this
stream id must be set by the client to a positive byte (negative stream id
are reserved for streams initiated by the server; currently all EVENT messages
(section 4.2.6) have a streamId of -1). If a client sends a request message
with the stream id X, it is guaranteed that the stream id of the response to
that message will be X.
This allow to deal with the asynchronous nature of the protocol. If a client
sends multiple messages simultaneously (without waiting for responses), there
is no guarantee on the order of the responses. For instance, if the client
writes REQ_1, REQ_2, REQ_3 on the wire (in that order), the server might
respond to REQ_3 (or REQ_2) first. Assigning different stream id to these 3
requests allows the client to distinguish to which request an received answer
respond to. As there can only be 128 different simultaneous stream, it is up
to the client to reuse stream id.
Note that clients are free to use the protocol synchronously (i.e. wait for
the response to REQ_N before sending REQ_N+1). In that case, the stream id
can be safely set to 0. Clients should also feel free to use only a subset of
the 128 maximum possible stream ids if it is simpler for those
implementation.
2.3. stream
A frame has a stream id (one signed byte). When sending request messages, this stream id must be set by the client to a positive byte (negative stream id are reserved for streams initiated by the server; currently all EVENT messages (section 4.2.6) have a streamId of -1). If a client sends a request message with the stream id X, it is guaranteed that the stream id of the response to that message will be X.
This allow to deal with the asynchronous nature of the protocol. If a client sends multiple messages simultaneously (without waiting for responses), there is no guarantee on the order of the responses. For instance, if the client writes REQ_1, REQ_2, REQ_3 on the wire (in that order), the server might respond to REQ_3 (or REQ_2) first. Assigning different stream id to these 3 requests allows the client to distinguish to which request an received answer respond to. As there can only be 128 different simultaneous stream, it is up to the client to reuse stream id.
Note that clients are free to use the protocol synchronously (i.e. wait for the response to REQ_N before sending REQ_N+1). In that case, the stream id can be safely set to 0. Clients should also feel free to use only a subset of the 128 maximum possible stream ids if it is simpler for those implementation.