The regular libuv stream API has uv_read_stop, which lets you stop receiving data until you call uv_read_start again. tlsuv doesn’t have a comparable call; instead it seems your read callback will get called whenever data arrives.
This unfortunately makes flow control and backpressure impossible. If the server is sending data faster than the client can process it, there’s no way to slow it down — the only option is to keep buffering more and more data in memory. This is a real problem: I worked on a mobile app once that was crashing during data sync for this reason when it had a fast enough Internet connection.
There needs to be a way for the client code to stop uvtls from reading from the socket when the client can’t keep up. That in turn will activate TCP flow control and cause the server to slow the rate it’s sending data.
The regular libuv stream API has
uv_read_stop, which lets you stop receiving data until you calluv_read_startagain. tlsuv doesn’t have a comparable call; instead it seems your read callback will get called whenever data arrives.This unfortunately makes flow control and backpressure impossible. If the server is sending data faster than the client can process it, there’s no way to slow it down — the only option is to keep buffering more and more data in memory. This is a real problem: I worked on a mobile app once that was crashing during data sync for this reason when it had a fast enough Internet connection.
There needs to be a way for the client code to stop uvtls from reading from the socket when the client can’t keep up. That in turn will activate TCP flow control and cause the server to slow the rate it’s sending data.