Re: [capnproto] Flow Control Implementation

['Kenton Varda' via Cap'n Proto]

RpcSystem::setFlowLimit() should work for this. Yes, this means the RPC
system will stop reading messages from the socket buffer if too many
requests are in flight. That will naturally cause TCP backpressure to kick
in. However, buffering still could happen on the client side if the client
isn't careful to limit how much data is in flight.

Another, more advanced option is to declare your main payload methods as
streaming with `-> stream`. This causes the RPC system *on the client side*
to automatically keep track of how many calls are in flight and apply
backpressure if it's too high. More info here:
https://capnproto.org/news/2020-04-23-capnproto-0.8.html

You could also combine both approaches if you do not trust clients to apply
flow control correctly. Note that `-> stream` flow control is only actually
implemented in C++ so far, so clients in other languages might ignore it.

-Kenton

On Tue, Jul 11, 2023 at 10:18 AM Linus Meierhoefer <
linusmeierhoefe...@gmail.com> wrote:

> Hi,
> I am trying to setup an rpc server in order to integrate it into my custom
> publisher-subscriber library. For this I need a flow control mechanism that
> doesn't depend on individual streams but on a global disk writing speed.
> That is: The flow limit should adapt to the in-flight-bytes of the disk IO.
> Moreover, if the flow limit is exceeded the rpc server should effectively
> stop reading packets from client sockets, pushing the backpressure logic to
> TCP. This should prevent memory overhead for the broker when a publisher
> tries to flood the server.
> I saw that there is flow control logic implemented in capnp but wonder how
> it actually operates? The header-documentation of *RPCSystem *says that
> "the RpcSystem will not read further messages from the stream" but does
> this imply that these overflow messages will reside in the sockets buffer
> and don't get transferred to the receivers memory? And how is backpressure
> implemented then?
> If the default flow control logic does not fit my use case, I guess I have
> to setup a custom event loop that stops polling from sockets fds when the
> disk flow limit is exceeded.
> It would be really helpful if you could share some of your knowledge.
> Thanks in advance
>
> --
> You received this message because you are subscribed to the Google Groups
> "Cap'n Proto" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to capnproto+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/capnproto/7f0cd6f2-f5a6-4b30-a7ac-78ca1fc33af3n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Cap'n Proto" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to capnproto+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/capnproto/CAJouXQ%3D3T12Rn4jSnPrQYWabsAg1Je%3DRA8qjM-meAqcc9K9CXg%40mail.gmail.com.

[capnproto] Flow Control Implementation

[Linus Meierhoefer]

Hi,
I am trying to setup an rpc server in order to integrate it into my custom 
publisher-subscriber library. For this I need a flow control mechanism that 
doesn't depend on individual streams but on a global disk writing speed. 
That is: The flow limit should adapt to the in-flight-bytes of the disk IO. 
Moreover, if the flow limit is exceeded the rpc server should effectively 
stop reading packets from client sockets, pushing the backpressure logic to 
TCP. This should prevent memory overhead for the broker when a publisher 
tries to flood the server. 
I saw that there is flow control logic implemented in capnp but wonder how 
it actually operates? The header-documentation of *RPCSystem *says that 
"the RpcSystem will not read further messages from the stream" but does 
this imply that these overflow messages will reside in the sockets buffer 
and don't get transferred to the receivers memory? And how is backpressure 
implemented then? 
If the default flow control logic does not fit my use case, I guess I have 
to setup a custom event loop that stops polling from sockets fds when the 
disk flow limit is exceeded. 
It would be really helpful if you could share some of your knowledge.
Thanks in advance

-- 
You received this message because you are subscribed to the Google Groups 
"Cap'n Proto" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to capnproto+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/capnproto/7f0cd6f2-f5a6-4b30-a7ac-78ca1fc33af3n%40googlegroups.com.