Expected Behavior when Stream ID's Reach 32-bit Limit

[Kevin Swiber]

I'm implementing the framing layer of the SPDY protocol and ran into a question while writing specs around stream creation.

Per Section 2.3.2 of the SPDY Protocol, Draft 3 [1]:

"Stream IDs do not wrap: when a client or server cannot create a new stream id without exceeding 32bits, it MUST NOT create a new stream."

Is there an expected behavior after reaching the upper limit or is the protocol leaving this to an implementation detail (i.e., close connection, open new connection, start stream)?

Also, can someone clarify if each connection starts a new Stream ID sequence or is there a shared sequence between all connections?

Thanks.

[1] http://mbelshe.github.com/SPDY-Specification/draft-mbelshe-spdy-00.xml#StreamCreation

-- 
Kevin Swiber

Projects: https://github.com/kevinswiber
Twitter: @kevinswiber

[Fedor Indutny]

Hi!

Each connection starts it's own sequence. I think correct behaviour will be sending GOAWAY packet and continuing sending/receiving data over existing streams.

Cheers,

Fedor.

[Ashok Kumar]

Hi,

A GOAWAY is meaningful even if sent from by a client? 

--
.- ... .... --- -.-

[Roberto Peon]

I think the behavior is unspecified when I'd hits the 31 bit limit currently, which we certainly have to rectify.

Goaway works from the client as well... remember that the server can initiate streams too...

-=R

[Mike Belshe]

Going back and finishing up on old emails....


Actually, the spec does address stream-ID wrapping.  There was a slight mistake with it, but it specifies the following:

"Stream IDs do not wrap: when a client or server cannot create a new stream id without exceeding a 31 bit value, it MUST NOT create a new stream."

I believe this is a small performance compromise (needing to open a new connection after 2,147,483,648 streams having been created in a single direction on a session), while making it very easy for implementations to test this edge case...

Mike