WebSocketsProcessor_RFC6544 throwing "NotImplemented" exception

[paulmrozowski]

I'm sending binary data to the server and one request in particular seems to keep tripping this. In ProcessFrame, there is this code:

                else
                {
                    if(pendingCount == 0)
                    {
                        Process(context, connection, frame.Payload, frame.OpCode);
                    } else
                    {
                        throw new NotImplementedException();
                    }
                }

I've been trying to strip down an example to reproduce it, but not having much luck. I grabbed the raw request as it was logged by NetGain, then sent it through the TcpClient, but that works just fine. The big difference is the client side is using WebSocket-Sharp. I've pulled in the source code and can see it happen, but since I'm not really that familiar with the protocol it's hard for me to understand what/why it's happening. If it matters, the message is 1035 bytes long. What's interesting is that it says 1036 bytes are available?

But what I see in the Output Window is this:

[server] Receive, Success: 1035 bytes
Received: (1035 bytes are here)
[server]    processing with 1036 bytes available
Parsed header from: 02-FE-03-F8-78-E2-56-B7
[server]    processed 1024 bytes; 12 remaining
[server]    processing with 12 bytes available

BTW - Is there an easy way to actually view the activity when the client isn't a browser? I could do this with Wireshark but then I'd have to move the server to another machine/VM for testing. I'd rather not if there was some nice way of doing it.

[paulmrozowski]

This seems to be related to what WebSocket-Sharp calls the "FragmentLength". It looks like it was splitting anything larger than 1016 bytes into multiple fragments, which NetGain doesn't like. Bumping this up so the entire message could be passed without splitting seems to fix the problem.

[systemidx]

This issue is killing me. I'm unable to send any meaningful amount of information from client to server (in 4 byte, 512 byte, nor 32 kb chunks). Sending one big payload and sending many little payloads seems to have the same issue.

I'm using native JavaScript WebSocket as a client, if that makes any difference.

Is there any workaround for this?