WebSocket Chrome Receiving Data Problems

Question

I tried looking around for some information but could not find any. I am using the latest build: 21.0.1180.83 m.

I have a C++ server I am working on, and after the handshake I am sending Chrome the following: "10000001000000100110100001101001" Which should just be "hi", correct? But for some reason chrome is not doing anything. My server is sending the data correctly--I was messing around with the bits and had a chrome error saying: One or more reserved bits are on: reserved2 = 1, reserved3 = 1. So, I know that chrome is receiving correctly.

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

To my knowledge that should be correct, unless I am missing something ... Any help would be appreciated.

EDIT I solved my issue, it seems like I was not putting the bytes together correctly ...

Here is a piece of code i chopped together to fix ... (dont hate)

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;
}

Do either onerror or onclose callbacks run after you send a message? Can you post your message sending code? Handshake code might also be useful (just in case there is additional data at the end of your handshake that is interpreted as the start of a message by Chrome). Using wireshark to check you're really sending the data you expect might be interesting too. — simonc, Aug 30 '12 at 14:01
@simonc Nope, everything sends fine. Ill check out wire shark. Im pretty sure it has todo with what kanaka has suggested. — User, Aug 30 '12 at 17:16
@Ohmages : Can you please let me know about your solution? How did you solved it? I am also facing similar issue. Any help will be appreciated. — Rahul Shukla, Oct 30 '13 at 06:06

score 4 · Accepted Answer · edited Oct 07 '21 at 05:57

4

It looks like your byte order is backwards. The first byte that is going out on the wire is "01101001" which is:

0 - continuation frame
110 - rsvd 1 and rsvd 2 (but not rsvd 3)
1001 - ping opcode.

It appears that you have a little endian architecture and are trying to construct the frame/header with multiple bytes at a time which is where endianness comes into play. If you are going to construct the frame with more than one byte at a time, you will need to swap the values to use network byte order (i.e. big endian).

References:

edited Oct 07 '21 at 05:57

Community

1
1

answered Aug 30 '12 at 14:35

kanaka

70,845
23
144
140

I still cant seem to make it work. Even with modified constant string value. – User Aug 30 '12 at 17:11
I also just had a thought, the handshake code works, and chrome says the handshake is successful, so I am not sure why sending other data is any different ... as I construct the handshake the same way with just putting together strings. – User Aug 30 '12 at 17:41
I'm having a similar problem, to get your "hi" example working what was the final result of the bytes? – user1157885 Jan 24 '16 at 11:47

score 0 · Answer 2 · answered Jun 04 '14 at 00:59

This "problem" can also manifest in Chrome if any unframed data comes after the handshake, which is then followed by framed data. I just wanted to share that since I just debugged this exact issue for several hours. The implementation I started with was adding the accept string after the CRLF \ CRLF following the headers. Hope it helps someone else :)

WebSocket Chrome Receiving Data Problems

2 Answers2