3

いろいろと情報を探してみましたが、見つかりませんでした。私は最新のビルドを使用しています: 21.0.1180.83 m.

私が取り組んでいるC++サーバーがあり、ハンドシェイクの後、Chromeに次のように送信しています: "10000001000000100110100001101001" しかし、何らかの理由でクロムは何もしていません。サーバーはデータを正しく送信しています。ビットをいじっていて、次のようなクロム エラーが発生しました。1 つ以上の予約済みビットがオンになっています: 予約済み 2 = 1、予約済み 3 = 1。つまり、クロムが正しく受信していることがわかります。

ws.onmessage = function (evt) 
     { 
        var received_msg = evt.data;
        alert(received_msg);
     };

私が何かを見逃していない限り、私の知る限り、それは正しいはずです...どんな助けもいただければ幸いです。

編集私は私の問題を解決しました。バイトを正しくまとめていなかったようです...

これは、修正するために一緒に切り刻んだコードの一部です...(嫌いではありません)

string construct_data ( string data ) {
    string return_value = "";
/*    0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-------+-+-------------+-------------------------------+
     |F|R|R|R| opcode|M| Payload len |    Extended payload length    |
     |I|S|S|S|  (4)  |A|     (7)     |             (16/64)           |
     |N|V|V|V|       |S|             |   (if payload len==126/127)   |
     | |1|2|3|       |K|             |                               |
     +-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - +
     |     Extended payload length continued, if payload len == 127  |
     + - - - - - - - - - - - - - - - +-------------------------------+
     |                               |Masking-key, if MASK set to 1  |
     +-------------------------------+-------------------------------+
     | Masking-key (continued)       |          Payload Data         |
     +-------------------------------- - - - - - - - - - - - - - - - +
     :                     Payload Data continued ...                :
     + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
     |                     Payload Data continued ...                |
     +---------------------------------------------------------------+*/
    char unmasked  = 129;
    char size;

    if ( data.size() <= 125 ) {
        size = data.size();
    } else  if ( data.size() > 125 && data.size()  <= 65535) {
        size = 126;
    } else if ( data.size() > 65535 ) {
        size = 127;
    }

    stringstream it_um;
    stringstream it_s;
    for ( int i = 0; i < 1 ; i++ )
        it_um << unmasked;
    for ( int i = 0; i < 1; i++ )
        it_s << size;

    std::string raw_unmask;
    std::string raw_size;

    raw_unmask = it_um.str();
    raw_size = it_s.str();

    string raw_data = raw_unmask + raw_size + data;

    return_value.append(raw_data);

    return return_value;
}
4

2 に答える 2

4

バイトオーダーが逆になっているようです。ネットワーク上で送信される最初のバイトは「01101001」です。これは次のとおりです。

  • 0 - 継続フレーム
  • 110 - rsvd 1 および rsvd 2 (ただし rsvd 3 は除く)
  • 1001 - ping オペコード。

リトル エンディアン アーキテクチャがあり、一度に複数のバイトでフレーム/ヘッダーを構築しようとしているようです。これがエンディアンの出番です。一度に複数のバイトでフレームを構築する場合は、ネットワーク バイト オーダー (ビッグ エンディアン) を使用するように値を交換する必要があります。

参考文献:

于 2012-08-30T14:35:03.390 に答える
0

この「問題」は、フレーム化されていないデータがハンドシェイクの後に来て、その後にフレーム化されたデータが続く場合、Chrome でも明らかになる可能性があります。この正確な問題を数時間デバッグしたばかりなので、それを共有したかっただけです。私が始めた実装は、ヘッダーに続く CRLF \ CRLF の後に受け入れ文字列を追加することでした。それが他の誰かに役立つことを願っています:)

于 2014-06-04T00:59:10.387 に答える