Is there a way to implement backpressure for large (infinite) responses? about gun

[essen]

OK so I'm thinking of adding two things:

• A request option flow that defines the initial flow value. This value is the number of messages that Gun is allowed to send (soft limit). It's a value >= 1 to simplify things and because 0 makes little sense anyway. By default flow control is disabled (same as current behavior).
• The user can increment this value when necessary via the function gun:update_flow(Pid, StreamRef, Flow).

It's similar to HTTP/2's windows except we are talking about number of messages instead of bytes.

Gun decreases the flow value for each data message sent (gun_data for HTTP and gun_ws for Websocket).

When the value reaches 0 Gun will either:

• Stop reading from the socket entirely for HTTP/1.0, HTTP/1.1 and Websocket.
• Stop updating the window size for HTTP/2.

Because we cannot decrease only the stream's window size the server will continue sending data until it is depleted. This means that Gun might end up with a negative flow value and send more messages than desired, but a good use of HTTP/2 configuration options should limit that behavior.

Similarly, memory usage can be limited via a good use of HTTP/2 configuration options, for example max_frame_size_received.

When the value goes above 0 again Gun will start reading from the socket again or send a window update if HTTP/2.

Thoughts?

I'm not terribly happy about Websocket having no other option than stop reading from the socket but that's a limitation of the protocol and we can't do anything about that. The good news is that when Gun supports Websocket over HTTP/2 then the flow control will work for it as well.

[essen]

There is no such thing today. What could be interesting is setting up a rate option, which is simple enough for HTTP, not so easy for SPDY which has rate control built in the protocol (and later on HTTP2 too) and pretty much impossible for Websocket without blocking everything else too.

An active option would be bad, because for SPDY for example we would have to buffer everything and it would build up until it explodes. Instead using the protocol capabilities should be more robust.

Now I don't have plans for that anytime soon but this is something that should be added eventually.

[srstrong]

Loic, have you had any more thoughts on this? An {active, N} type option would be very useful; I can see how to drop it in relatively easily for a simple http-type connection, but http2 / ws look to be more complex

[essen]

No but now you should be able to implement a content handler that lets you do a ack before it continues (right now the default just sends a message, but you should be able to send a message and wait for a response back before returning as well). Or ack every X messages or whatever, kind of like {active,N}. This should be helpful even though not perfect because for HTTP/2 there's protocol elements better suited than just "function not returning".

If Websocket there's a similar Websocket handler interface.

[essen]

Ugh. What to do about push promises!

[essen]

I've opened #205 with the start of a flow control implementation for Erlang messages Gun sends for the response bodies. Need to add it to Websocket, answer a few questions in the todos and document of course.

[essen]

The implementation should be complete. Please take a look at #205 and provide feedback.

[essen]

Merged it. Please check it out in master. Enjoy!

[sumerman]

Yeah, sorry, I was quite busy with other things. Huge thanks for addressing this!

[essen]

No problem but do try before we reach an RC. There'll be pre-releases before that happens.

[sumerman]

No problem but do try before we reach an RC. There'll be pre-releases before that happens.

I don't work on a project I needed this for back when I created this issue. Although I might try figuring out if I have a task at hand where it can help :)

[essen]

Oh yeah that's old. No worries. Cheers!