Using VNC Client to control host

[Informatic]

Hey,

I've been thinking of adding VNC client to the webOS service (as an option) to control the host - what are your opinions on this? I can try implementing that. Of course this complicates the setup (ie. connection needs to be initiated from the TV side, after entering all the credentials there...), but besides that, security wise, is probably equal to our existing setup. (with added auth)

This has an advantage of being able to control more platforms, where magic4pc agent is not present (at least yet) - Linux, MacOS, Android...

There's some library for NodeJS already that seems fairly functional, after a quick glance (includes auth and pointer/key event support, which should probably be enough for us) - https://www.npmjs.com/package/rfb2

[Wouterdek]

I'm open to the idea, but have some reservations about VNC:

• I like the wide compatibility VNC offers. That's the main advantage of a standard protocol, no need to develop our own server for each platform.
• I don't like the idea of users having to manually enter ip addresses, passwords, ... through a TV remote. The current system aims to set these things up automatically as much as possible, and whatever needs to be done manually is done on the PC. If possible, I'd like to retain that. It seems "Listen-Mode" is what we are looking for, and is supported in multiple VNC packages[1] [2]. Not sure if it supported by the npm library though.
• Unless I'm wrong, TCP is more or less required for VNC. I prefer UDP, as latency is preferable over strict reliability in this usecase (there is no point in re-transmitting cursor positions), and TCP introduces some unnecessary overhead. However, this is probably fine for a local connection though.

[Informatic]

2. I am not sure if the library supports it OOTB, however it should be fairly easy to extend it to support this (since its designed to take in arbitrary open socket to handle messages stream on as well, IIRC). We can probably support both modes, if anyone *insists* on using proper client mode (even if it would require manual config file edits). For now we can just show TVs IP/MAC on status/config popup. 3. Makes sense. I don't think VNC supports any lossy transport. We should still recommend "native" agents for supported platforms, with a note that VNC is an alternative that can give worse experience.

…

On Sat, 22 Jan 2022, 13:54 Wouter De Keersmaecker, ***@***.***> wrote: I'm open to the idea, but have some reservations about VNC: - I like the wide compatibility VNC offers. That's the main advantage of a standard protocol, no need to develop our own server for each platform. - I don't like the idea of users having to manually enter ip addresses, passwords, ... through a TV remote. The current system aims to set these things up automatically as much as possible, and whatever needs to be done manually is done on the PC. If possible, I'd like to retain that. It seems "Listen-Mode" <https://stackoverflow.com/questions/5390759/vnc-in-reverse-direction> is what we are looking for, and is supported in multiple VNC packages [1] <https://github.com/TigerVNC/tigervnc/blob/ec5d0d9bb183b1af9028d928aa50cdcad5b00727/java/com/tigervnc/vncviewer/VncViewer.java#L210> [2] <https://archive.realvnc.com/products/vnc/documentation/4.6/docs/af1050529.html>. Not sure if it supported by the npm library though. - Unless I'm wrong, TCP is more or less required for VNC. I prefer UDP, as latency is preferable over strict reliability in this usecase (there is no point in re-transmitting cursor positions), and TCP introduces some unnecessary overhead. However, this is probably fine for a local connection though. — Reply to this email directly, view it on GitHub <#6 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAIUEXTGYEQHXJYHF47YQ2DUXKSH5ANCNFSM5MN4PXDQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[Wouterdek]

OK, sounds good to me!