Minecraft Version

1.21.x

Version

1.115.1

Details

I'm messaging with a Websocket server with my CC computer. Whenever I send a specific binary message to my computer over the websocket, the CC side appears to interpret the socket to have been closed.

Another WS client has no issue with the message, so the only option left to me is the underlying Websocket implementation in CC. With a very quick search and no familiarity with the codebase, I couldn't find where to investigate it myself, so I'm reporting this here.

Minimal reproducible example Python server (depends on websockets) https://gist.github.com/Zakru/d8f5e4efe36a1aca863bcc4f04bf0d0e
CC-side client https://gist.github.com/Zakru/2bc152978f72643dee45042e2bb3bcdb

The packet in question can be found in Base64 encoding in the Python server example. You should be able to run the server, and then the demo client. The client will immediately get nil from ws.receive(), as though the socket was closed, even though a message has been sent by the server. I can consistently reproduce this with the demo server running on my machine and a computer running the demo client in a singleplayer world (with appropriate HTTP rule configuration).

_HOST = ComputerCraft 1.115.1 (Minecraft 1.21.1)

Logs in case they can be of any use https://gist.github.com/Zakru/021d88660e1d25a6c0994126c13502c2

I will be able to work around this issue, but this seems like pretty odd behavior. Is there a magic number mistakenly detected somewhere?

CC:T has max websocket message size limit config. Your message is way over the limit. Receiving nil means the message was removed as it was too large (or server sent empty packet). It'll throw an error if you attempt to use a closed socket.

Just doing quick math on mobile, so it's probably off a bit. But you have something like 2496 lines of 70 characters being sent, each character itself is a byte, so total bytes is 2496 * 70 = 174,720 bytes. Default max size is 128 * 1024 = 131,072 bytes.

Thanks for pointing that out. The payload is actually the binary under the B64, so it's exactly 5 bytes over 128 * 1024. Apparently I missed the fact that the limit exists because messages seem to get silently truncated to that length. I think this should be an error instead, but that's secondary. Because regardless of the limit...

All the other messages I have sent are received without any issue, other than the truncation. And if you check the demo server code, there are some commented-out lines that test different slices of the packet. All of the slices presented are under the size limit and some still cause the issue. So that rules out max message length as a potential cause.

Thanks for the report! So this is being caused by the max packet length, but there's a couple of other things interacting, which make it a bit more confusing.

• The max message limit applies to the on-the-wire message, rather than the data you actually send. I haven't poked too much here, but websockets uses the per-frame deflate extension, so I suspect that's what's adding the extra data to the payload.
• This should close the websocket with a descriptive message. However, there's a bug in our error-handling code that prevents this.
• Similarly, Websocket.recieve returns nil when the websocket is closed, but does not include the error message. We should fix this.

I think the websocket closing code needs a bit of a rework (see also #2096). Will have a think about how this should work.

Apparently I missed the fact that the limit exists because messages seem to get silently truncated to that length

Oh, we should never truncate messages. Do you have a reproducer for this?

Thanks for the report! So this is being caused by the max packet length, but there's a couple of other things interacting, which make it a bit more confusing.

There are examples in the demo server where messages shorter than 128 KiB are sent, and the issue still occurs. I think it's safe to say this isn't a length limit issue. I re-read your comment. So if the websocket uses deflate, perhaps this message is just the only one in my dataset that happens to not deflate under 128 KiB? If this is indeed a length issue on my end, then yeah, error messaging/documentation improvements would be nice. Especially since it seems poor compression can even cause issues in messages under 128 KiB.

Oh, we should never truncate messages. Do you have a reproducer for this?

Nevermind, there was no truncation. The other >128KiB messages arrive fully. Apologies, when I did the experiments, I was looking at the length of the payload after my application-specific header which happened to also be 128 KiB. I plead 3 AM.