RangeError with Raw encoding at websock.js

[daniq]

I have a custom app that communicates via RFB protocol. It use noVNC to display UI. Using Hextile encoding is ok, switching to Raw periodically produce the following exceptions:

recv_message, caught exception: 
    name: RangeError
    message: Source is too large
RangeError: Source is too large
    at Uint8Array.set (native)
    at Object.Websock._decode_message (http://localhost:8080/widget/include/websock.js:346:22)
    at Object.Websock._recv_message (http://localhost:8080/widget/include/websock.js:352:22)

I'm not seeing errors in Raw encoding at my app side, but they can be there) However I think anyway noVNC should deal with this gracefully.
Could someone give me a clue why it happens?

[kanaka]

@daniq can you add some debug to _decode_message to show how large data, u8 and _rQlen are before this error. You might be running into a limitation with typed arrays in your browser. Speaking of which, what browser and version are you running into this with? Also, have you tried with a different browser to see if the error is still present?

Unfortunately, due to the design of the RFB protocol, it's not possible to recover from errors processing the data stream. Well designed protocols have a length at the beginning of every data frame, but in RFB you must correctly process all the data in the stream, or you basically will get lost and not be able to sync up the stream again.

[DirectXMan12]

It's also possible that there are large messages involved that are overwhelming the receive queue before it gets a chance to resize.

For various reasons, noVNC's receive queue is statically allocated. It starts out at 4 MiB, and doubles in size if it ever grows beyond half its capacity. Since the adjustment occurs after the message is received, it's possible that you've sent a message that is larger than what the buffer can handle (this would be necessarily have to be greater than 2 MiB in size, and probably larger, depending on the conditions).

I can tweak the code to also make any necessary adjustments to the buffer ahead of time, but it would be nice to also confirm that there isn't some other underlying issue here that also needs to be fixed in noVNC. Could you confirm if you're sending large messages like that?

[daniq]

Thank you for quick and comprehensive replies.
Yes, in Raw encoding a big amount of data is sent (2-4Mb and more). I'm using latest Yandex browser (based on Chromium).

u8: Unint8Array[5261968]
this._rQlen = 0;

Tried Safari with the following error:

RangeError: Maximum call stack size exceeded.
(anonymous function)websock.js:75
rQshiftStrwebsock.js:140
_handle_server_cut_textrfb.js:1051
_normal_msgrfb.js:1107
_handle_messagerfb.js:555
(anonymous function)rfb.js:562
(anonymous function)

What helps me is to revert recently updated noVNC library to one of the previous versions where 'decode_message' looks like:

function decode_message(data) {
    //Util.Debug(">> decode_message: " + data);
    if (mode === 'binary') {
        // push arraybuffer values onto the end
        var u8 = new Uint8Array(data);
        for (var i = 0; i < u8.length; i++) {
            rQ.push(u8[i]);
        }
    } else {
        // base64 decode and concat to the end
        rQ = rQ.concat(Base64.decode(data, 0));
    }
    //Util.Debug(">> decode_message, rQ: " + rQ);
}

This version takes a punch.
NB: I'm using binary mode.

[DirectXMan12]

What helps me is to revert recently updated noVNC

That version doesn't have a fixed-size array, and is much slower in certain aspects. I'll update the code to handle such cases better.

[daniq]

Nice, thanks! Possibly it should be some array size constant to be available to change.
Will wait for the solution.

[DirectXMan12]

Hey, sorry for the delay (I've been busy at work lately). Can you take a look at #565? It should fix your issue.

[daniq]

Yep, I'll test it, thank you. But I can't promise you it will be soon.