Как отключить кадры принудительного продолжения с помощью websocket-sharp в С#

При использовании библиотеки WebSocket-Sharp на C# для создания клиента WebSocket я обнаружил, что отправка сообщений не работает должным образом.

Если я отправляю серверу особенно длинную строку в виде текстового фрейма, библиотека WebSocket-Sharp усекает ее до 1016 символов, которые она отправляет в виде текста, но затем продолжает остальные данные в фрейме продолжения и преобразует их в двоичные данные вместо текста. .

Есть ли способ отключить это поведение? В моем случае это делает библиотеку непригодной для использования, так как сервер не отвечает после кадра продолжения.

Вот пример из журнала Fiddler:

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

person blizz    schedule 11.12.2014    source источник
comment
Проверьте, можете ли вы увеличить буфер, чтобы не нужно было обрезать кадр на 1016.   -  person vtortola    schedule 11.12.2014
comment
Нет возможности изменить размер буфера   -  person blizz    schedule 17.12.2014
comment
Из вашего исходного сообщения вы имеете в виду, что кадр отправляется как двоичный или что полезная нагрузка фактически закодирована как двоичная? Кадры продолжения не определяют себя как бинарные или текстовые, это может быть проблема сервера.   -  person vtortola    schedule 17.12.2014


Ответы (1)


Я смог изменить это поведение, изменив переменную FragmentLength в классе WebSocket.

Только что загрузил проект с открытым исходным кодом из GitHub, обнаружил, что длина по умолчанию до фрагментации составляет 1016, а максимальная длина - Int32.MaxValue - 14. Я перекомпилировал DLL после изменения FragmentLength на 1016 * 20 и сослался на измененную DLL. Задача решена.

person blizz    schedule 18.12.2014