Hi Antoine,

First, thanks a lot to share with us the results of your research, it's interesting, even if, for me, I'm not the first concerned with that: Most of our network data we handle with AsyncIO have enough space with a simple UDP packet ;-)

Anyway, I have questions about your suggestions, see below:

2017-10-18 20:04 GMT+02:00 Antoine Pitrou <solipsis@pitrou.net>:

Also, since asyncio is the de facto standard now, I wonder if asyncio
might grow such a new API. That may be troublesome: asyncio already
has Protocols and Streams, and people often complain about its
extensive API surface that's difficult for beginners :-)

From my point of view, I like a lot to code TCP servers with the Streams API of AsyncIO.

When I see your piece of code for Tornado: https://gist.github.com/pitrou/0f772867008d861c4aa2d2d7b846bbf0
It looks very similar of the Streams API.

To my understanding, some AsyncIO libraries, like aiohttp, don't use Streams API of AsyncIO and implement a specific implementation, especially to have a full control on the buffers: based on the information provided inside the protocol, you are able to know if a small payload or a big payload will arrive on the wire, like Content-Length header with HTTP.

My question is: Do you think it's possible to have a simple API to fit at the same time small payloads and big payloads, without impacts on efficiency for all use cases ?

Or it's too much integrated with the protocol implementation itself to converge until a simple solution for all use cases ?

Maybe before to think about an AsyncIO improvement, it might be a new library at the first step ?

To let decide people to use this new buffering algorithm ?

Thanks for your responses.