SC encoding fallbacks not available?

[jas8522]

Hey there,

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.

[Rudi De Vos]

The old SC was build before rfb extended himself to allow flavor ( tight/real/ultra) to announce himself via the protocol.
SC needed a special code on startup, to do we used the at that moment free 16 protocol.
( We wanted that the viewer got a accept popup, until now thiw was only supported on the server site)
Afterwards we saw that this breaks the rfb protocol.

Only Sc is affected, winvnc full has been modified to follow 100% the rfb protocol.

[jas8522]

I'm not quite clear on what that means for this issue...

I should note that my interpretation of the encoding type 16 above was wrong. It seems to actually be only ZRLE encoding that the SC server is enforcing, which noVNC currently does not support.

So back to my original question... is it possible for SC to negotiate an encoding type like TIGHT rather than ZRLE so that it can be compatible with a viewer like noVNC? I ask because I know that almost every other VNC server supports multiple encoding types and it seems like that would be a much simpler solution than implementing an entire encoding type in noVNC.

I'm perfectly fine with the custom RFB version -- I can modify noVNC to allow for that version. But I haven't yet figured out how to implement ZRLE in noVNC, so having SC support other encoding types would be extremely helpful!

Thanks,

Jordan

[Rudi De Vos]

SC is old... and was made to create a 150k exe, it doesn't have all encoders in it.
Tight is not supported ( reason at that time was the huge jpeg lib)

A common encoder would be hextile, noVNC must support this standard encoder.