I have a uvnc repeater configured and seemingly working well alongside a themed version of Single Click. I'm attempting to use noVNC as my viewer so I can use it cross-platform.
I've got everything set up so that both the SC server and noVNC viewer can connect to the repeater and it bridges the connections perfectly. However as soon as noVNC attempts to actually connect through the repeater to the SC server, it runs into two issues:
1) The SC server reports its RFB protocol as one that noVNC does not support (003.016), and once I get beyond that,
2) noVNC fails to negotiate an encoding type with the SC server, indicating that the SC server uses an unsupported encoding of type 16.
I opened an issue with noVNC here: https://github.com/kanaka/noVNC/issues/545
#1 is pretty straightforward; I added the RFB protocol version to the switch statement in noVNC to allow the connection to proceed. Unfortunately #2 is not straightforward in that it seems that noVNC doesn't have any code to support encoding type 16 (which seems to be FTP encoding?)
I was under the impression that the protocol for connecting typically allows for negotiation, meaning noVNC should be able to fall back to an encoding that both SC and noVNC support, but that doesn't seem to be happening here. Does SC only come bundled with the code to support FTP encoding? Or do you think noVNC might be failing to handle the negotiation of encoding properly?
If only FTP encoding is supported in SC, is it possible when using the web creator that we could opt to include other (more common) encoding types for better client compatibility?
If specifying allowed encoding is not possible with SC, are there docs indicating how FTP encoding works so it could be implemented in noVNC? This would be done here