Search code examples
encodingprotocolswebsocketdecoding

How can I send and receive WebSocket messages on the server side?


  • How can I send and receive messages on the server side using WebSocket, as per the protocol?

  • Why do I get seemingly random bytes at the server when I send data from the browser to the server? It the data encoded somehow?

  • How does the framing work in both the server → client and client → server directions?


Solution

  • Note: This is some explanation and pseudocode as to how to implement a very trivial server that can handle incoming and outcoming WebSocket messages as per the definitive framing format. It does not include the handshaking process. Furthermore, this answer has been made for educational purposes; it is not a full-featured implementation.

    Specification (RFC 6455)


    Sending messages

    (In other words, server → browser)

    The frames you're sending need to be formatted according to the WebSocket framing format. For sending messages, this format is as follows:

    • one byte which contains the type of data (and some additional info which is out of scope for a trivial server)
    • one byte which contains the length
    • either two or eight bytes if the length does not fit in the second byte (the second byte is then a code saying how many bytes are used for the length)
    • the actual (raw) data

    The first byte will be 1000 0001 (or 129) for a text frame.

    The second byte has its first bit set to 0 because we're not encoding the data (encoding from server to client is not mandatory).

    It is necessary to determine the length of the raw data so as to send the length bytes correctly:

    • if 0 <= length <= 125, you don't need additional bytes
    • if 126 <= length <= 65535, you need two additional bytes and the second byte is 126
    • if length >= 65536, you need eight additional bytes, and the second byte is 127

    The length has to be sliced into separate bytes, which means you'll need to bit-shift to the right (with an amount of eight bits), and then only retain the last eight bits by doing AND 1111 1111 (which is 255).

    After the length byte(s) comes the raw data.

    This leads to the following pseudocode:

    bytesFormatted[0] = 129
    
    indexStartRawData = -1 // it doesn't matter what value is
                           // set here - it will be set now:
    
    if bytesRaw.length <= 125
        bytesFormatted[1] = bytesRaw.length
    
        indexStartRawData = 2
    
    else if bytesRaw.length >= 126 and bytesRaw.length <= 65535
        bytesFormatted[1] = 126
        bytesFormatted[2] = ( bytesRaw.length >> 8 ) AND 255
        bytesFormatted[3] = ( bytesRaw.length      ) AND 255
    
        indexStartRawData = 4
    
    else
        bytesFormatted[1] = 127
        bytesFormatted[2] = ( bytesRaw.length >> 56 ) AND 255
        bytesFormatted[3] = ( bytesRaw.length >> 48 ) AND 255
        bytesFormatted[4] = ( bytesRaw.length >> 40 ) AND 255
        bytesFormatted[5] = ( bytesRaw.length >> 32 ) AND 255
        bytesFormatted[6] = ( bytesRaw.length >> 24 ) AND 255
        bytesFormatted[7] = ( bytesRaw.length >> 16 ) AND 255
        bytesFormatted[8] = ( bytesRaw.length >>  8 ) AND 255
        bytesFormatted[9] = ( bytesRaw.length       ) AND 255
    
        indexStartRawData = 10
    
    // put raw data at the correct index
    bytesFormatted.put(bytesRaw, indexStartRawData)
    
    
    // now send bytesFormatted (e.g. write it to the socket stream)
    

    Receiving messages

    (In other words, browser → server)

    The frames you obtain are in the following format:

    • one byte which contains the type of data
    • one byte which contains the length
    • either two or eight additional bytes if the length did not fit in the second byte
    • four bytes which are the masks (= decoding keys)
    • the actual data

    The first byte usually does not matter - if you're just sending text you are only using the text type. It will be 1000 0001 (or 129) in that case.

    The second byte and the additional two or eight bytes need some parsing, because you need to know how many bytes are used for the length (you need to know where the real data starts). The length itself is usually not necessary since you have the data already.

    The first bit of the second byte is always 1 which means the data is masked (= encoded). Messages from the client to the server are always masked. You need to remove that first bit by doing secondByte AND 0111 1111. There are two cases in which the resulting byte does not represent the length because it did not fit in the second byte:

    • a second byte of 0111 1110, or 126, means the following two bytes are used for the length
    • a second byte of 0111 1111, or 127, means the following eight bytes are used for the length

    The four mask bytes are used for decoding the actual data that has been sent. The algorithm for decoding is as follows:

    decodedByte = encodedByte XOR masks[encodedByteIndex MOD 4]
    

    where encodedByte is the original byte in the data, encodedByteIndex is the index (offset) of the byte counting from the first byte of the real data, which has index 0. masks is an array containing of the four mask bytes.

    This leads to the following pseudocode for decoding:

    secondByte = bytes[1]
    
    length = secondByte AND 127 // may not be the actual length in the two special cases
    
    indexFirstMask = 2          // if not a special case
    
    if length == 126            // if a special case, change indexFirstMask
        indexFirstMask = 4
    
    else if length == 127       // ditto
        indexFirstMask = 10
    
    masks = bytes.slice(indexFirstMask, 4) // four bytes starting from indexFirstMask
    
    indexFirstDataByte = indexFirstMask + 4 // four bytes further
    
    decoded = new array
    
    decoded.length = bytes.length - indexFirstDataByte // length of real data
    
    for i = indexFirstDataByte, j = 0; i < bytes.length; i++, j++
        decoded[j] = bytes[i] XOR masks[j MOD 4]
    
    
    // now use "decoded" to interpret the received data