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 ?

On Tuesday, June 30, 2015 at 1:56:57 PM UTC-4, Richard Bradley wrote:
>
> > 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
>
> On Tuesday, June 30, 2015 at 6:18:02 PM UTC+1, Maatary Okouya wrote:
>>
>> 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
>>
>>
>>

-- 
>>>>>>>>>>      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 the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Reply via email to