Open snoyberg opened 10 years ago
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:
data FramedData a = FrameEnd | FrameContent a
getFrameData :: WebSocketData a => Connection -> IO (FramedData a)
Or perhaps just specializing to strict ByteString
s at that point, and leaving it up to the streaming layer above to convert to Text
as necessary.
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.