клиентский пакет websocket - PullRequest
1 голос
/ 18 декабря 2011

Я пытаюсь реализовать последние спецификации websocket.Однако я не могу пройти через этап снятия маски после успешного рукопожатия.

Я получаю следующий кадр веб-сокета:

<<129,254,1,120,37,93,40,60,25,63,71,88,92,125,80,81,73,
51,91,1,2,53,92,72,85,103,7,19,79,60,74,94,64,47,6,83,
87,58,7,76,87,50,92,83,70,50,68,19,77,41,92,76,71,52,
70,88,2,125,90,85,65,96,15,14,20,107,31,14,28,100,27,9,
17,122,8,72,74,96,15,86,68,37,68,18,76,48,15,28,93,48,
68,6,73,60,70,91,24,122,77,82,2,125,80,81,85,45,18,74,
64,47,91,85,74,51,21,27,20,115,24,27,5,37,69,80,75,46,
18,68,72,45,88,1,2,40,90,82,31,37,69,76,85,103,80,94,
74,46,64,27,5,60,75,87,24,122,25,27,5,47,71,73,81,56,
21,27,93,48,88,76,31,57,77,74,11,55,73,68,73,115,65,81,
31,104,26,14,23,122,8,75,68,52,92,1,2,110,24,27,5,53,
71,80,65,96,15,13,2,125,75,83,75,41,77,82,81,96,15,72,
64,37,92,19,93,48,68,7,5,62,64,93,87,46,77,72,24,40,92,
90,8,101,15,28,83,56,90,1,2,108,6,13,21,122,8,82,64,42,
67,89,92,96,15,93,19,56,28,8,65,101,31,94,16,105,28,10,
20,56,30,14,65,56,27,93,71,106,16,11,17,63,25,4,17,57,
73,89,17,59,29,88,29,106,24,27,5,46,65,72,64,54,77,69,
24,122,66,93,93,49,5,12,8,109,15,28,76,59,90,93,72,56,
76,1,2,41,90,73,64,122,8,89,85,50,75,84,24,122,25,15,
23,105,25,5,19,106,26,14,20,111,25,27,5,53,77,85,66,53,
92,1,2,110,26,13,2,125,95,85,65,41,64,1,2,108,27,10,19,
122,7,2>>

В соответствии с определенным здесь базовым протоколом кадрирования (http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-17#section-5.2) у меня есть:

fin:1, rsv:0, opcode:1, mask:1, length:126

Маскированное приложение + данные полезной нагрузки выглядят так:

<<87,58,7,76,87,50,92,83,70,50,68,19,77,41,92,76,71,52,70,88,2,125,90,85,65,96,
15,14,20,107,31,14,28,100,27,9,17,122,8,72,74,96,15,86,68,37,68,18,76,48,15,
28,93,48,68,6,73,60,70,91,24,122,77,82,2,125,80,81,85,45,18,74,64,47,91,85,
74,51,21,27,20,115,24,27,5,37,69,80,75,46,18,68,72,45,88,1,2,40,90,82,31,37,
69,76,85,103,80,94,74,46,64,27,5,60,75,87,24,122,25,27,5,47,71,73,81,56,21,
27,93,48,88,76,31,57,77,74,11,55,73,68,73,115,65,81,31,104,26,14,23,122,8,75,
68,52,92,1,2,110,24,27,5,53,71,80,65,96,15,13,2,125,75,83,75,41,77,82,81,96,
15,72,64,37,92,19,93,48,68,7,5,62,64,93,87,46,77,72,24,40,92,90,8,101,15,28,
83,56,90,1,2,108,6,13,21,122,8,82,64,42,67,89,92,96,15,93,19,56,28,8,65,101,
31,94,16,105,28,10,20,56,30,14,65,56,27,93,71,106,16,11,17,63,25,4,17,57,73,
89,17,59,29,88,29,106,24,27,5,46,65,72,64,54,77,69,24,122,66,93,93,49,5,12,8,
109,15,28,76,59,90,93,72,56,76,1,2,41,90,73,64,122,8,89,85,50,75,84,24,122,
25,15,23,105,25,5,19,106,26,14,20,111,25,27,5,53,77,85,66,53,92,1,2,110,26,
13,2,125,95,85,65,41,64,1,2,108,27,10,19,122,7,2>>

В то время как 32-битный ключ маскирования:

<<37,93,40,60,25,63,71,88,92,125,80,81,73,51,91,1,2,53,92,72,85,103,7,19,79,60,
74,94,64,47,6,83>>

Согласно http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-17#section-5.2:

j                   = i MOD 4
transformed-octet-i = original-octet-i XOR masking-key-octet-j

однако я, похоже, не получаю свой оригинальный октет, отправленный со стороны клиента, который в основном представляет собой пакет xml. Любое направление, исправление, предложения приветствуются.

1 Ответ

1 голос
/ 19 декабря 2011

Я думаю, что вы неправильно прочитали раздел формирования данных спецификации протокола.

Ваша интерпретация первого байта (129) верна - fin + код операции 1 - последний (и первый) фрагменттекстовое сообщение.
Следующий байт (254) подразумевает, что тело сообщения маскируется и что следующие 2 байта обеспечивают его длину (длина 126 или 127 означает более длинные сообщения, длина которых не может быть представлена ​​в 7 битах. 126 означает, чтоследующие 2 байта содержат длину; 127 означают, что это следующие 4 байта).
Следующие 2 байта - 1, 120 - означают длину сообщения 376 байтов.
Следующие 4 байта - 37,93,40,60 - ваша маска.
Остальные данные - это ваше сообщение, которое должно быть преобразовано по мере написания, давая сообщение

...