Asnchronous streaming, output buffer and slow clients

[Nick Kostyria]

Hello.
Please tell me, how I can detect what the output buffer is overflowed?
I want to paused when slow client does not have time to receive data.
And then I want resume streaming when output buffer is empty.
Please tell me how to do this correctly for a non-blocking PSGI server.
Thanks.

[Andy Colson]

You dont have to worry about it.  The OS will take care of it for you.

--

---
You received this message because you are subscribed to the Google Groups "psgi-plack" group.
To unsubscribe from this group and stop receiving emails from it, send an email to psgi-plack+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Eric Wong]

It REALLY depends on the server you're using...


For public-inbox[1], I ended up writing a custom PSGI server
(since I already needed a C10K NNTP server) to handle
backpressure when generating gigantic responses using a
"pull"-based model rather than a traditional "push" one[2]

I wrote more about push vs. pull models on the rack-devel (Ruby)
list here, since rack uses the "push" model:

https://public-inbox.org/rack-devel/20161115-slow-cli...@80x24.org/


The end result is public-inbox-httpd and -nntpd can stream
arbitrarily large responses while never having more than a
single email loaded in memory for a given client connection.

But yeah, it is very specialized and requires a fair bit of
knowledge about response sizes, pipelining backpressure, and
careful coding to manage the state machines.


To that end, having lightweight concurrency (e.g. Coro for Perl
or "auto-fibers" for Ruby) built into the language to expose a
synchronous flow to the scripter would be much easier. And I'm
hoping I can get "auto-fibers" into Ruby for 2.7.


[1] git clone https://public-inbox.org/ public-inbox

see:
lib/PublicInbox/HTTP.pm
lib/PublicInbox/HTTPD/Async.pm
git grep -F pi-httpd.async

[2] the "push" vs. "pull" terminology is common from audio APIs

[Eric Wong]

Andy Colson <jaco...@gmail.com> wrote:
> You dont have to worry about it. The OS will take care of it for you.

Not true for large responses. The OS does not have infinite memory
to buffer responses in socket buffers.

With HTTP/1.1 pipelining, even generating bunch of small
responses can add up, especially if a client can't (or won't)
read the responses quickly.

[Kostirya]

Thanks.
So PSGI before 1.1 version has two models: push ands pull, has not it?
Then I do not understand why poll_cb was removed from writer methods
at 1.1 version.

ср, 19 дек. 2018 г. в 12:39, Eric Wong <e...@80x24.org>: