akka HTTP (back pressure)

[Maatary Okouya]

Hi, 

I wonder if there is something in the HTTP protocol that allow to either speed up or slow down the transfer of byte. I understood that back pressure is available in TCP which i am not an expert on. However how does the HTTP protocol signal it to the TCP Layer. 

I could see in a webinar on the matter that using curl, one can use limit-rate and set a download rate for instance. Apparently this applies some form of back pressure on an AKKA HTTP implementation server. 

If someone could help clarify a bit this aspect that would be great. 

It seems to me that back pressure already exist in TCP/HTTP, and that AKKA Stream applies the same principle to more things than just TCP/HTTP. When it comes to TCP/HTTP, it just provide a nice interface on it. 

Kind regards,

M

[Richard Bradley]

> how does the HTTP protocol signal it to the TCP Layer. 

It doesn't; it delegates the flow control and back-pressure entirely to the TCP layer.

When you use "limit-rate" in curl, it will slow down its reads from the TCP socket, which will cause the remote server to slow down the speed at which it sends data due to TCP back-pressure.

An Akka HTTP server will notice this TCP back-pressure and slow down how fast it is generating data to send to the TCP socket (if the source of the data supports that) via the Akka Streams mechanism.

If you want to read more, try searching for "http protocol stack"

> It seems to me that back pressure already exist in TCP/HTTP, and that AKKA Stream applies the same principle to more things than just TCP/HTTP. When it comes to TCP/HTTP, it just provide a nice interface on it. 

That's right. 

Akka Streams can have back-pressure from any "Sink" they are attached to. 

In the case of Akka HTTP, the Sink is a TCP socket, which has back-pressure due to the pre-existing TCP mechanisms underlying the HTTP stream.

Hope this helps,

Rich

[Maatary Okouya]

Thanks for the clarification and the tip.

--
>>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>>>>>> Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to a topic in the Google Groups "Akka User List" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/akka-user/K7YbtPRIj80/unsubscribe.
To unsubscribe from this group and all its topics, send an email to akka-user+...@googlegroups.com.
To post to this group, send email to akka...@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[Maatary Okouya]

A Quick clarification: 

When you say:

<<<An Akka HTTP server will notice this TCP back-pressure and slow down how fast it is generating data to send to the TCP socket (if the source of the data supports that) via the Akka Streams mechanism.>>>

I wonder what is the actual need, pertinence of this. Indeed, if TCP already apply the back pressure and slows down, why do the HTTP server from which the data is sent, slow down as well. In other words, this yield to the question of :

How a typical server would handle it, and what added value the AKKA HTTP Server add ? Maybe the question could be reformulated as such: What is the risk of not slowing down the data generation ? Data Loss, Socket Buffer overflow ? Do we have example of that. Where u could cause an overflow with whatever else technology rather than AKKA HTTP.  For instance Spray does not support that, can i create the situation with it ? 

Please could you help clarify this ?

[Maatary Okouya]

Maybe my question would be easier this way

>>>When you use "limit-rate" in curl, it will slow down its reads from the TCP socket, which will cause the remote server to slow down the speed at which it sends data due to TCP back-pressure.

Let say that we have this scenario with spray, or another lib, that does not have back pressure. So what would have to the sender of the data ? a Buffer overflow ? I mean if the sender keep generating data at the same rate, putting the data to be send in the buffer (I imagine a call that is asynchronous, non-blocking). With a synchronous blocking call, the back pressure would be applied automatically by virtue of the call right ?  SO yes, could you elaborate a bit on that.

On Tuesday, June 30, 2015 at 1:56:57 PM UTC-4, Richard Bradley wrote:

[Richard Bradley]

On Tuesday, October 13, 2015 at 9:35:13 PM UTC+1, Maatary Okouya wrote:

Maybe my question would be easier this way

>>>When you use "limit-rate" in curl, it will slow down its reads from the TCP socket, which will cause the remote server to slow down the speed at which it sends data due to TCP back-pressure.

Let say that we have this scenario with spray, or another lib, that does not have back pressure. So what would have to the sender of the data ? a Buffer overflow ? I mean if the sender keep generating data at the same rate, putting the data to be send in the buffer (I imagine a call that is asynchronous, non-blocking).

I believe that the NIO socket would overflow its send buffer and drop data and/or abort the connection, yes.

I haven't tried it myself. There may be more info in the Java NIO docs, or you could try it and see.

 

With a synchronous blocking call, the back pressure would be applied automatically by virtue of the call right ?

Yes, in the sync case, the "write()" method would just block until the socket send buffer had emptied a bit, which would act as back-pressure on the sender.

 

Best,

Rich

[Konrad Malawski]

On Tue, Oct 13, 2015 at 11:28 PM, Richard Bradley <richard.brad...@gmail.com> wrote:

I believe that the NIO socket would overflow its send buffer and drop data and/or abort the connection, yes.

Yeah, when trying to write to a socket using asynchronous ops the write can fail, so the library (i.e. user) has to either re-try after a bit or drop the data.

--

Cheers,

Konrad 'ktoso' Malawski

Akka @ Typesafe

[Maatary Okouya]

Thanks guys for the input.