-
Notifications
You must be signed in to change notification settings - Fork 113
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
No means of streaming incoming data #60
Comments
Also, to clarify: even if there is no need to support such large messages, the current implementation seems prone to a memory exhaustion attack against any server using it. |
Right, I was actually thinking of just capping the number of frames and/or their size/the total size when this came up. A streaming interface might be cool as well, but I think websockets are usually used in a message-per-message way (or at least that's how APIs in other languages seemed to work when I wrote it). |
I don't think a streaming interface necessarily conflicts with message-per-message. I was thinking something like this:
Or perhaps just specializing to strict |
I'll start off by admitting that I'm a novice when it comes to WebSockets, so maybe what I'm saying here doesn't make much sense. That said, consider this example program:
https://gist.github.com/snoyberg/9388796
The point is that the client sends a 10 million character message to the server. With the current API, there seems to be no way to do this in a streaming manner. Additionally, bumping that to 30 million characters causing runtimes to increase more than linearly, from 3.3s to 18.6s. (Maximum memory usage, however, does seem to rise perfectly linearly.)
I think that some kind of API exposing the frames themselves would make sense.
The text was updated successfully, but these errors were encountered: