A single message ws.send(data); comes in as two messages about emacs-websocket

[chrisdone]

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.

[chrisdone]

By the way, thanks for publishing this package, it's great! 👍 😄

[ahyatt]

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?

[chrisdone]

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. ☝️

[ahyatt]

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.