Seeing 'invalid frame header' and 'could not decode a text frame as UTF8' errors in chrome when connected to SuperWebSockets

[Costigan]

Hello, I'm seeing these errors in Chrome when connected to a SuperWebSockets server:

WebSocket connection to 'ws://10.10.81.15:10081/' failed: Invalid frame header WebSocket connection to 'ws://10.10.81.15:10081/' failed: Could not decode a text frame as UTF-8.

Do you know what can cause this? In my server, I'm using the default (text mode) connection and passing strings to the connection.

[VWoeltjen]

@kerryjiang - continue to run into this, and after some debugging, I believe I understand why.

In particular, this occurs when sending several large (~200k) text frames in quick succession.

At the TCP level, what we see is a well-formed text frame header (saying "I'm a 200k text frame") followed by the first ~64k (or more, or less) of one of those text frames. So far so good, but after around 64k (I don't know if that number is meaningful) there is suddenly the start of the subsequent text frame.

On the Chrome side, it sees the start of the first message, expects 200k of UTF-8 text, and throws a validation error when it reaches the 0x81 (the frame header.)

I believe the "Invalid frame header" has the same underlying cause but haven't demonstrated this.

On the SuperWebSocket side, we Send strings, these get formatted as WebSocket frames, and passed over to SuperSocket.

Once handed over to SuperSocket, these get queued to be sent asynchronously.

These get sent by invoking SendAsync on System.Net.Sockets.Socket.

At the system call level, a sendmsg call begins (we're running Mono on Linux). This does not send the complete message, and returns the number of actual bytes sent (~64k usually, although this number varies)

Back at the SuperSocket level, the OnSendingCompleted callback is invoked, which in turn consults ProcessCompleted.

This checks that e.BytesTransferred > 0, but does not check that the bytes transferred matches the full queue size. So, even though only part of that WebSocket frame was sent, SuperSocket thinks it's done and happily continues along its way.

...at least, that's my understanding of what's happening. I may have misconceptions about how these all fit together.

[kerryjiang]

If your analysis is true, you probably can fix it by switching to SuperSocket.WebSocket.

I believe the latest SuperSocket doesn't have this sending issue.

[VWoeltjen]

Thanks - I've tried this with SuperSocket.WebSocket v1.6.6 but still see this issue.

[kerryjiang]

OK, let me review the code again and then give you an update!