Streaming version of send

[sanketr]

It seems that the library doesn't have a streaming version for building websocket message. Here is the send code from the library:

 send :: Connection -> Message -> IO ()
    send conn msg = do
        case msg of
            (ControlMessage (Close _ _)) ->
                writeIORef (connectionSentClose conn) True
            _ -> return ()
        connectionWrite conn msg

Since we can call connectionWrite only once when sending the message, it seems all of the data must be accumulated in memory to build the message. So, the lazy bytestring is not very useful because we must accumulate it all for the message.

Is it trivial to build a streaming version of send on top of Websockets library (basically, be able to call write multiple times) ? Then, we could connect it with conduit, pipes or streaming.

It seems receive is streaming because it has lazy bytestring. But, send isn't despite lazy bytestring. Please correct me if I got this wrong.

My use case is receiving and sending large objects through websocket server (an API server which is just an intermediary between the client and storage). I could do chunking through multiple messages, and then sending close code to indicate whether it is finished or not. But, it seems cleaner to build a single message in streaming fashion rather than building another streaming protocol on top of websocket messages.

[jaspervdj]

I agree, a streaming version would be very nice. I also think it would not be extremely hard to add. We would mainly need to patch Network.WebSockets.Hybi13.encodeFrame so that it produces multiple frames for large lazy Bytestrings, and avoids calling BL.length (which is where it is currently fully evaluated).

[LeanderK]

i have a use-case where i need to just push the input from an IPC socket into an web socket, is this issue an deal breaker for this? It has to be somewhat performant (the workload for one connection is comparable to streaming video and it would have to handle multiple). I would guess just choosing smaller bytestrings could solve the problem.

[jaspervdj]

@LeanderK Yes, just splitting them up in multiple messages would do the trick.

[tolysz]

I was thinking about it, maybe if we put it in a new module with "Lazy" in the name :)