2

When using the WebSocket-Sharp library in C# to build a WebSocket client, I am finding that sending messages doesn't work properly.

If I send the server a particularly long string as text frame, the WebSocket-Sharp library truncates it to 1,016 characters, which it sends as text, but then continues the rest of the data in a continuation frame and converts it into binary instead of text.

Is there any way to disable this behavior? It makes the library unusable in my case since the server doesn't respond after the continuation frame.

Here is an example taken from a Fiddler log:

22:06:33:8486 WSSession5.WebSocket'WebSocket #5'
MessageID:  Client.28
MessageType:    Text
PayloadString:  *//Original data redacted//*
Masking:    60-96-90-D9

22:06:33:8642 WSSession5.WebSocket'WebSocket #5'
MessageID:  Client.29
MessageType:    Continuation
PayloadString:  5F-6F-61-75-74-68-5F-74-6F-6B-65-6E-22-3A-22-22-2C-22-6C-6F-63-61-74-69-6F-6E-5F-61-67-65-22-3A-22-22-2C-22-6C-6F-63-61-74-69-6F-6E-5F-6E-61-6D-65-22-3A-22-55-53-22-2C-22-6D-69-64-73-69-7A-65-5F-61-76-61-74-61-72-22-3A-22-22-2C-22-6D-69-6E-75-73-5F-73-63-6F-72-65-22-3A-22-22-2C-22-74-75-6D-62-6C-72-5F-62-6C-6F-67-5F-75-72-6C-22-3A-22-22-2C-22-6F-63-63-75-70-61-74-69-6F-6E-22-3A-22-22-2C-22-72-65-6C-61-74-69-6F-6E-73-68-69-70-5F-73-74-61-74-75-73-22-3A-22-22-2C-22-74-75-6D-62-6C-72-5F-62-6C-6F-67-5F-6E-61-6D-65-22-3A-22-22-2C-22-73-68-61-72-65-5F-75-72-6C-22-3A-22-22-2C-22-73-6C-75-67-22-3A-22-63-68-69-67-6F-74-79-22-2C-22-73-6E-69-70-70-65-74-22-3A-22-22-2C-22-73-6E-69-70-70-65-74-5F-65-78-70-6C-6F-72-65-5F-73-65-61-72-63-68-5F-68-74-6D-6C-22-3A-22-22-2C-22-73-6E-69-70-70-65-74-5F-65-78-70-6C-6F-72-65-5F-76-32-22-3A-22-22-2C-22-73-6E-69-70-70-65-74-5F-66-61-76-65-73-22-3A-22-22-2C-22-73-6E-69-70-70-65-74-5F-66-61-76-65-73-5F-73-65-61-72-63-68-5F-68-74-6D-6C-22-3A-22-22-2C-22-73-6E-69-70-70-65-74-5F-68-74-6D-6C-22-3A-22-22-2C-22-73-6E-69-70-70-65-74-5F-70-69-63-6B-65-72-22-3A-22-22-2C-22-73-6E-69-70-70-65-74-5F-70-69-63-6B-65-72-5F-68-74-6D-6C-22-3A-22-22-2C-22-73-74-61-74-75-73-22-3A-22-22-2C-22-73-68-61-72-65-64-22-3A-2D-31-2C-22-73-63-6F-72-65-22-3A-2D-31-2C-22-6D-75-74-75-61-6C-5F-66-72-69-65-6E-64-5F-63-6F-75-6E-74-22-3A-2D-31-2C-22-6C-69-6B-65-73-22-3A-2D-31-2C-22-6B-61-72-6D-61-22-3A-2D-31-2C-22-69-74-65-6D-73-5F-73-68-61-72-65-64-22-3A-2D-31-2C-22-66-6F-6C-6C-6F-77-69-6E-67-5F-63-6F-75-6E-74-22-3A-2D-31-2C-22-66-6F-6C-6C-6F-77-65-72-5F-63-6F-75-6E-74-22-3A-2D-31-2C-22-61-67-65-22-3A-2D-31-7D-2C-22-73-74-61-74-75-73-22-3A-22-53-45-4E-54-22-2C-22-63-61-63-68-65-49-64-22-3A-30-2C-22-69-6E-63-6F-6D-69-6E-67-22-3A-66-61-6C-73-65-2C-22-72-65-61-64-22-3A-66-61-6C-73-65-7D-2C-22-69-6E-73-65-72-74-5F-69-66-5F-6D-69-73-73-69-6E-67-22-3A-74-72-75-65-2C-22-61-6C-6C-6F-77-5F-63-61-6D-65-72-61-22-3A-66-61-6C-73-65-2C-22-73-69-6C-65-6E-74-22-3A-66-61-6C-73-65-2C-22-74-79-70-65-22-3A-22-4F-4E-5F-53-45-4E-44-5F-4D-53-47-22-7D
Masking:    60-96-90-D9
vtortola
  • 34,709
  • 29
  • 161
  • 263
blizz
  • 4,102
  • 6
  • 36
  • 60
  • Check if you can make the buffer bigger so it does not need to cut the frame at 1016. – vtortola Dec 11 '14 at 10:46
  • There is no option to change the buffer size – blizz Dec 17 '14 at 04:04
  • From your original post, you mean that the frame is sent as binary or that the payload is actually encoded as binary? Continuation frames do not defined themselves as binary or text, it may be a server problem. – vtortola Dec 17 '14 at 12:49

1 Answers1

2

I was able to change this behavior by modifying the FragmentLength variable in the WebSocket class.

Just downloaded the open source project from GitHub, found that the default length before fragmentation is 1016, and max length is Int32.MaxValue - 14. I recompiled the DLL after changing FragmentLength to 1016*20 and referenced the modified DLL. Problem solved.

blizz
  • 4,102
  • 6
  • 36
  • 60