Websocket closes its connection on access from async method

[binarytrails]

https://github.com/sevaivanov/small-projects/tree/master/python/websockets/thread-asyncio

[aaugustin]

Your "serve" coroutine exits immediately after sending "welcome". At that point the websocket is closed.

You need while True: await asyncio.sleep(...) or equivalent to prevent the coroutine from terminating.

See the documentation for details.

[binarytrails]

I don't agree. Why would I do a loop in the server coroutine when it serves already its purpose? On a new websocket connection I add the websocket to the Queue which works if you see error.log. There is no need for a while loop... The error seems more related to the Queue not being able to stock the websocket instances.

[aaugustin]

You're welcome to disagree with the API of the library but I can't help you in that case.

websockets is designed and documented to close the websocket connection when the "handler" coroutine exits. This is what happens, whether you agree or not, and changing it would be very backwards-incompatible.

[binarytrails]

Wouldn't keeping alive a handler by while True: await asyncio.sleep(...) consume a lot of resources for each maintained websocket?

[aaugustin]

The resource consumption is so low I cannot measure it.

I tried running 100000 sleeps in parallel:

>>> lots_of_sleep = [asyncio.sleep(60) for _ in range(100000)]
>>> asyncio.get_event_loop().run_until_complete(asyncio.gather(*lots_of_sleep))

Starting them consumes some CPU; then once they're all sleeping top reports 0.0% CPU used.

I tried again with 1000000 but I couldn't start the coroutines:

RuntimeError: Event loop stopped before Future completed.

With the current design, each websocket connection requires two alive coroutines. If one of them is just blocked while True: await <something very long that consumes no CPU and no I/O> I don't think you will be able to measure its resource consumption compared to the other one, which performs the actual work and holds at least one open socket.

Managing 100k connections in a single Python process would be a good result and my proposal has 0,0% overhead in that case. I don't know if it consumes something or nothing at all because I don't know how to get a better resolution.

Usually you have to bypass the OS' TCP stack long before you reach that scale...

[binarytrails]

Thank you for your input. It is solved with binarytrails/smoll@3b9e9d3.