MAX_CONCURRENT_STREAMS=1

Question

Sorheart OP

Created Aug ’16

Replies 8

Boosts 0

Views 4.5k

Participants 5

I'm using the new http/2 apns api, and recently I'm facing this problem:

After I sent about 50k notifications, I've received GOAWAY frame from APNS server, and it says:

Maximum active streams violated for this endpoint.

Does someone else face the same problem?

Or can someone tell me what this means?

I can't find familiar error definitions in RFC 7540.

---------------------------------------

After set log level to debug, I've found more information:

It always happened like this:
Received settings from APNs gateway: {HEADER_TABLE_SIZE=4096, MAX_CONCURRENT_STREAMS=1, INITIAL_WINDOW_SIZE=65535, MAX_FRAME_SIZE=16384, MAX_HEADER_LIST_SIZE=8000}
Received settings from APNs gateway: {HEADER_TABLE_SIZE=4096, MAX_CONCURRENT_STREAMS=500, INITIAL_WINDOW_SIZE=65535, MAX_FRAME_SIZE=16384, MAX_HEADER_LIST_SIZE=8000}
Received GOAWAY from APNs server: Maximum active streams violated for this endpoint., errorcode is: 7, last stream id is: 1355

MAX_CONCURRENT_STREAMS set to 1, then to 500, then connection break off.

Boost

Answer 1

jwilm_onesignal OP

Aug ’16

The SETTINGS frame may contain a SETTINGS_MAX_CONCURRENT_STREAMS value, and the client should care not to multiplex more streams than is specified there.

0

Answer 2

jwilm_onesignal OP

Aug ’16

We are seeing this error as well for a few apps despite not violating maximum concurrent streams. One thought is that the GOAWAY frame perhaps contains the wrong error message, and there's some other problem. We've also considered that perhaps the settings contain the wrong value for max concurrent streams, but we are using the max for other applications without issue, and this observation rules out that theory.

0

Answer 3

jwilm_onesignal OP

Aug ’16

Looked into this a bit more; it appears that the SETTING_MAX_CONCURRENT_STREAMS starts at 500 for a new connection. We open some number of streams, and everything is great. Later, a new settings frame arrives with SETTING_MAX_CONCURRENT_STREAMS = 1. Shortly after that, we receive a GOAWAY frame.

Here's a log of frames sent and received once the new settings frame arrives.

Settings frame received

set_max_concurrent_streams: 1

Sending a SETTINGS ack

Headers for stream 6347

Data chunk for stream 6347

End of stream 6347

GOAWAY frame received

Note that the only frame we send is the SETTINGS ACK before receiving GOAWAY. I did notice that, shortly before receiving the settings frame, we sent a HEADERS frame which initiates a new stream. It may appear on an APNs server that they send new SETTINGS, receive a request for a new stream, and then send a GOAWAY. The GOAWAY frame should probably not be sent in this case if the client's ACK for the SETTINGS has not been received.

0

Answer 4

wengineer OP

Aug ’16

As per the log I see in my app, I always get a settings frame with MAX_CONCURRENT_STREAMS=1 when one of my request results in Non-200 Non-410 Response. Can you confirm if that is the case with you as well.

0

Answer 5

jonchambers OP

Aug ’16

Have you folks filed a bug report with Apple yet?

0

Answer 6

jonchambers OP

Aug ’16

…and for what it's worth, I can reliably reproduce the "max concurrent steams" issue in production by sending a single notification with a bogus token.

0

Answer 7

jwilm_onesignal OP

Aug ’16

Which part of the issue are referring to? It's perfectly valid for the server to send another settings frame with a different value of max concurrent streams (even 1 or 0, although the later is discouraged) long after the initial settings have been agreed upon. The issue in my mind is the subsequent GOAWAY frame potentially sent before the client acks new settings.

0

Answer 8

CoreOSTechE OP

Aug ’16

I am pleased to let you know, the problem has been fixed.

0