How mutch websocket connection can one daphne handle at the same time about daphne

[proofit404]

I guess this is the result of connection handling mechanics. Websocket handshake will be in open state until websocket.connect consumer return {'accept': True} or similar result. If websocket.connect channel is full, incoming connection is closed with 503 error code. I don't know why time to connect increases exponential. Default channel capacity is 100 so it explains the last situation. Try to increase websocket.connect capacity with channel_capacity argument of channel layer.

[andrewgodwin]

Daphne shouldn't be closing connections without any response - is there any console logging from it when this is happening? Do you know what WebSocket close code you get in the browser?

[ostcar]

There is no console logging at all (except of the CONNECT, HANDSHAKING and DISCONNECT messages). I also don't get any WebSocket close code. It seems, as if the tcp socket is closed before the websocket handshake is finished. The golang error message is: connection reset by peer

I run my tests again and came to much better results (but there are still lost connections). It "feels" like it is better, when i flush the redis db. But I am not sure. I also get the same errors, when I switch to the asgi inmemory backend.

I looked in the redis-db and it seems, that there are as as many keys in the form "asgi:websocket.send!PVPpOgmJFeV" as there are lost connections.

I tried for some time to reproduce the error with only a few clients by altering some parts of daphne or the asgi_redis backend but could not make it.

I have nomore ideas, how to debug this.

[andrewgodwin]

No error at all is unexpected; even if it errors out somewhere in the Python processing you should get a Twisted traceback at minimum. I'm not sure there's much I can do at this point, but any more information might help!

[ostcar]

You can get the same behaviour, when you lower the open file limit for daphne (withulimit -n 20). Then you also get a closed connection without any error message or traceback.

But this is not the problem with this issue. With this issue you can have all connections opend in the end. When you set a low open file limit, then there can't be more then $(ulimit -n) - 10 open connections.

[andrewgodwin]

Entire websocket handling code is rewritten to not be as nasty and I haven't been able to replicate this, closing.