Introduction
Suppose we develop a network application using reactive stream implementation. And we use HTTP/2 as a base application layer protocol. Reactive streams provide a flow control for stream processing, called back-pressure. A subscriber in reactive stream controls the size of streamed data by requesting its availability to connected publisher.
However, there also exists flow controls at computer networking protocol at application layer and transport layer each. So it means that 3-level flow controls are operating when we try to send streamed data to an end system.
TCP Layer
It is well known that TCP provides a flow control. It provides client-side a way to control how many TCP segments it can receive at a time. A client notices its available window (size) in TCP header to a connected end system.
=> tunes each TCP segment size at live.
TCP is full-duplex communication, so each end system maintains variables as trasmitter and receiver both.
sender:
receiver:
a receiver continuously sends 'rwnd' of 'window size' in the TCP header and tells its available buffer size.
```
rwnd = RcvBuffer - (LastByteRcvd - LastByteRead)
```
misc.
if a sender receives rwnd = 0, it may stop transmitting data. However TCP specify its action to repetitively send a signal with 1 byte data.
HTTP/2
Note that HTTP/1.1 and less does not support any flow control.
> Do the above requiremsents remind you of TCP flow control? They should, as the problem is effectively identical (see
>
Flow control is credit-based. Each receiver advertises its initial connection and stream flow control window (in bytes), which is reduced whenever the sender emits a
DATA frame and incremented via a WINDOW_UPDATE frame sent by the receiver.
Flow control cannot be disabled. When the HTTP/2 connection is established the client and server exchange
SETTINGS frames, which set the flow control window sizes in both directions. The default value of the flow control window is set to 65,535 bytes, but the receiver can set a large maximum window size (2^31-1 bytes) and maintain it by sending a WINDOW_UPDATE frame whenever any data is received.Reactive Stream
Back-pressure is a mechaism subscriber controls its acceptance of published data from publisher. If a subscriber and a publisher are seperated on the network, their throughput must be differed from each other. If the subscriber processes the accepted data with throughput at lower rate than the publisher, then remaining data on subscriber-side is being stacked over and over. This results in some storage overflow(this may lead fatal hardware failures!). The subscriber controls its acceptance rate by requesting a size for next published data in its callback.
Implementations of reactive stream supports many kinds of back-pressure strategies. There is no absolute strategy on various network conditions, and your application can handle back-pressure'd situation by how you want it to work :)
BUFFER
DROP
Upvote b
ReplyDelete+1
ReplyDelete