Application-level back-pressure VS TCP native flow-control

Question

I am investigating why some systems implement application-level back-pressure given that TCP provides native flow control.

I was reading, in particular, akka-streams and (an higher level discussion) reactive streams.

Is it only to abstract out the idea of asynchronous communication out of the network and out of the TCP protocol?

Other, more precise, questions:

• If the application (say akka-streams app) ends up communicating over TCP, will it fall back to TCP's native back-pressure?

• Does reactive streams implement application-level back-pressure on top of TCP by simply leaving TCP handle it?

Any help and pointer would be appreciated! Thanks :)

Answer 1

I think the underlying assumption of your question is that TCP is the only external communication within a stream pipeline.

Suppose your stream communicates over several IO channels such as file IO, database querying, and standard output to the console:

//Read Data from File --> DB Query --> TCP Server Query --> Slow Function --> Console

An akka-stream implementation would provide asynchronous, back-pressured, support through the entire pipeline. Therefore akka-stream has to provided application level back-pressure for calling long-running functions, querying databases, reading files, writing to the console, etc.

You are correct that akka's implementation of the TCP Server section of the stream relies on TCP's "native backpressure". From the documentation:

...by using Akka Streams you are freed of having to manually react to back-pressure signals, as the library does it transparently for you.