Streaming Server

[Tronic]

Moved from #1791

A plain Python reimplementation of Sanic's built-in server and related restructuring also in ASGI backend and in response handling. Includes first-class support for streaming, improved performance and better ground for further development.

By the sheer volume of it, it also brings some breaking changes like the removal of custom protocol support but typical applications that do not do anything special with the server's internals should remain mostly unaffected.

Installation:

pip install git+https://github.com/huge-success/sanic@streaming

Issues of current git master, resolved in this:
Fix #1653
Fix #1722
Fix #1730
Fix #1749
Fix #1785
Fix #1790
Fix #1804
Fix #1824
Fix #1875
Fix #1988

[ahopkins]

@huge-success/sanic-core-devs Please take a look at this one. I'd like to get this merged by the end of the weekend. Even if it is not 100% perfect and release worthy, I want to get this merged because of the large number of changes that it entails. Having it merged into master will allow us to continue making other PRs without resolving too many conflicts. Release it not set until March, but I want to make sure there is plenty of time to test this in master.

[ahopkins]

This pull request has been mentioned on Sanic Community Discussion. There might be relevant details there:

https://community.sanicframework.org/t/new-streaming-api-and-other-major-changes/518/15

[ahopkins]

This pull request has been mentioned on Sanic Community Discussion. There might be relevant details there:

https://community.sanicframework.org/t/2021-release-managers-and-updates/781/1

[ahopkins]

I'll handle these. When done, I want to merge. @sanic-org/sanic-core-devs any other thoughts before I do so?

[ashleysommer]

Just looking over these merged changes now, to learn how Sanic works at a low level now.

I have noticed it looks like there is a possibility for the Request Middleware to run twice on a request.
Both the app.handle_request and app.handle_exception methods execute the Request middleware.

If the main handler encounters an exception after running the middleware, then the exception handler will execute and run the request middleware again.

Edit:
Perhaps request.request_middleware_started is already used to mitigate against that?

[ahopkins]

Yeah. That is the purpose of it. I think eventually I want to get rid of it and not have to carry that state trigger (there is not a similar one for response).

[ahopkins]

This pull request has been mentioned on Sanic Community Discussion. There might be relevant details there:

https://community.sanicframework.org/t/highly-different-cpu-usage-when-proxying-m2tp-udp-unicast-stream-to-a-streamed-sanic-response/795/10