Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Accepting back-pressure from slow websocket clients #1367

Closed
njsmith opened this issue Nov 5, 2016 · 4 comments
Closed

Accepting back-pressure from slow websocket clients #1367

njsmith opened this issue Nov 5, 2016 · 4 comments
Labels

Comments

@njsmith
Copy link

njsmith commented Nov 5, 2016

Long story short

If a websocket client is slow to read data from the network -- perhaps because of a network failure, or because of a malicious client -- then AFAICT there's no way for an aiohttp websocket server to detect this and slow down sending or drop that client. Instead, the server will just keep sending data and the data will queue up indefinitely inside the server. In some cases, such as a websocket server that sends out an ongoing stream of updates without reading responses (e.g.: a chat server or something like a live twitter feed), then this makes it possible to trivially trigger memory leaks on servers by sending them just a few packets.

Steps to reproduce

Point this client:

import sys, asyncio, aiohttp

URL = sys.argv[1]

async def constipate(url):
    session = aiohttp.ClientSession()
    async with session.ws_connect(url) as ws:
        await asyncio.sleep(100000000)

asyncio.get_event_loop().run_until_complete(constipate(URL))

At this server:

from aiohttp import web

async def endless_update_stream(request):
    ws = web.WebSocketResponse()
    await ws.prepare(request)
    while True:
        ws.send_str("x" * 100000)

app = web.Application()
app.router.add_get("/", endless_update_stream)
web.run_app(app, port=8081)

But remember to hit control-C before the server runs your machine out of memory and it starts swapping to death.

Solution

The simplest solution would be to add an async drain method to websocket handlers, similar to asyncio.StreamWriter. Probably a better solution would be to make send_str and friends async methods so that users didn't have to remember to call drain explicitly, but of course this has API compatibility issues.

@thehesiod
Copy link
Contributor

I may be off but I think this blog post may be worth reading: https://vorpus.org/blog/some-thoughts-on-asynchronous-api-design-in-a-post-asyncawait-world/

@fafhrd91
Copy link
Member

should be fixed in master

@fafhrd91
Copy link
Member

Thanks for pointing to the problem

@lock
Copy link

lock bot commented Oct 29, 2019

This thread has been automatically locked since there has not been
any recent activity after it was closed. Please open a new issue for
related bugs.

If you feel like there's important points made in this discussion,
please include those exceprts into that new issue.

@lock lock bot added the outdated label Oct 29, 2019
@lock lock bot locked as resolved and limited conversation to collaborators Oct 29, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

3 participants