A single message ws.send(data); comes in as two messages
chrisdone opened this issue · 5 comments
With this server:
(defvar server
(websocket-server
9009
:host 'local
:on-message (lambda (ws frame)
(let* ((b64-image (websocket-frame-text frame))
)
(with-current-buffer (get-buffer-create "*image-text-output*")
(insert "\nCHUNK:\n")
(insert b64-image))
)
)
:on-open (lambda (ws) (message "Client connected."))
:on-close (lambda (ws) (message "Client disconnected."))))
If I send
ws = new WebSocket("ws://localhost:9009/");
ws.onopen = function() {
ws.send(data);
};
where data
comes from here, :on-message
is called twice, one for each chunk.
That's not what I expected. I'd expect the whole .send()
payload to come in as one message. I can implement my own buffering, but I thought that the websocket API was supposed to take care of this?
So from what I can see about message fragmentation, messages are split into multiple frames. So your Emacs API would be more aptly named :on-frame
because it receives frames, which are part of some message.
So it seems like I can recreate a proper conceptual :on-message
by using websocket-frame-completep
to concatenate the contents of each frame until completep
is t
.
I think your existing API is good for streaming, so it'd be cool if it had both on-frame
and on-message
for the advanced or simple case. Closing, I can achieve what I need with this.
By the way, thanks for publishing this package, it's great! 👍 😄
My memory isn't perfect about this, but my recollection is that I should just be returning whole messages, not just frames. Looking at the code, websocket-process-input-on-open-ws
should repeatedly read frames until the message is completed. websocket-read-frame
is supposed to return nil if the frame is not completed, and it doesn't look like it does that. Perhaps that is the cause of this issue.
So, are you sure that closed is correct for this?
I'm not sure what's correct behavior for you. 🤔 But I encountered this when making a message that's large, e.g. 100kb. I think you could literally just replace the data
in my JS example with "a".repeat(100000)
to reproduce this. ☝️
After reviewing the code, you're right in your analysis of this. It is documented that on-message
actually deals with frames. Would you like to contribute a function to automatically concatenate messages to callback on a completed message? That might help other users.