- Server sends highest version that it supports
- Client sends back the version that it wants to use
- Server sends a list of authentication & encryption methods it supports
- Client chooses from the list and sends its response
If no authentication is used:
- Server sends a message to the client saying auth went ok
- Client sends init message
- Server replies with its own init message
- Client sends pixel format and supported codecs and requests the first frame
- Server sends frame
If the client chose authentication, more steps are added in between. E.g. if the client chose TLS this happens:
- Server sends VEnCrypt version
- Client sends VEnCrypt version
- Server acks client's version and sends list of supported security subtypes
- Client chooses a subtype and sends it
- Server upgrades the connection to TLS which adds a couple of more round-trips (5 steps total for this item).
If, for example, each step takes 100 ms, you should have a total of 1.2 s without auth and 2.1 s with TLS.
Zealotry/enthusiasm tends to float to the top and is, perhaps, what you see on the surface when you look at any community.
However, I think that most users of open source software prefer it, not because of their political beliefs, but because of their curiosity. Open source software is made by the community for the community; not to entice outsiders or sell to any would-be customers. The main draw of open source software for a curious person is that they can look inside and tinker with it and they can modify it to conform to their needs.
Saying things like "I tried your software and it doesn't work for me" or "I left it and never looked back" (usually phrased in a less polite manner) doesn't really achieve anything constructive. An open source software developer isn't interested in that kind of "feedback". After all, they're not selling anything. They're just making software for their own needs and/or to satisfy their thirst for knowledge and understanding.
If you are not curious about the inner workings of software, then open source is not for you, and that's fine.
It would need to be tested and properly integrated with x11vnc. As the goal is to move away from X11, it doesn't seem likely that they would invest time into that.
Besides, if you have x11, you can still use RealVNC.
> It would need to be tested and properly integrated with x11vnc.
True, although if you already have wayvnc that's like a day of work; AFAICT x11vnc and wayvnc are nearly drop-in replacements.
> As the goal is to move away from X11, it doesn't seem likely that they would invest time into that.
It may be the goal, but is it the present? All the articles I can find about the pi transition to wayland say it's the default for the pi 4 and 5 but not anything else. Which is consistent with
> First of all, Raspberry Pi Connect needs your Raspberry Pi to be running a 64-bit distribution of Raspberry Pi OS Bookworm that uses the Wayland window server. This in turn means that, for now, you’ll need a Raspberry Pi 5, Raspberry Pi 4, or Raspberry Pi 400.
but raises the obvious point that supporting X11 would be helpful to support earlier models. (Along with 32-bit support, which I also am surprised at them not including.)
> Besides, if you have x11, you can still use RealVNC.
And if you use wayland, you could just use wayvnc directly. The whole point is to wrap it up in a nice package and add just enough central server to deal with connectivity.
I once worked for a multi-national food processing automation company.
We had an internal control system based on RT_PREEMPT Linux and busybox. This system was created before buildroot and yocto became a thing. It was compatible with the company's previous control system, which ran on bare-metal 68k. I was on the team that maintained and developed this Linux based system. This all ran on hardware that was developed and manufactured in-house.
The company had also acquired many smaller companies over the years, all of which came with their own way of doing things. Most used PLC, but not always from the same vendor, some even used elaborate mechanical clockwork.
The Linux based stuff was actually pretty good for gluing all this stuff together.
At some point, a consulting company came in, and shortly after that, the management decided that the company should focus on its "core competencies". So, they hired a guy to find a replacement for all the different control systems within the company: One system to rule them all. It was to replace all the software and the hardware.
We told them, that they should rather focus on creating and documenting common interfaces; replacing everything was very clearly an impossible task. They ignored this advice, entered a contract with a single PLC company and deprecated the system that I was working on along with everything else.
A few years later, they fired that guy they hired and the CTO, but in the meantime, we all kept working on the "deprecated" systems while the replacement was "just around the corner".
Anyway, whether they were going to proceed or not didn't really matter to me. It's all about the journey, not the destination. You can keep learning whether you're doing something useful or not. You can still craft software to the best of your abilities and take pride in the art. In fact, don't think of yourself as a software engineer. Think of yourself as a software artist!
> At the moment it doesn't look like flight traffic will be affected.
Yes, in fact the opposite. Air traffic controllers in Iceland were planning a strike, and they've now postponed it because of the eruption, they claim.
I am in Iceland now. The ATC strike has been in the morning, delaying flights 4-5 hours but not cancelling them. Flights are still coming in and out today. Last night another guest at our hotel saw the eruption from the plane.
It is most definitely closed. The only people in that area now are construction workers who are closing the gap between the two mountains Þorbjörn and Hagafell, in order to protect the power station.
They're closing the barricade where the road intersects it. The northern intersection seems to be a priority rather than the southern one, like I thought first.
On wayvnc git master and sway 1.8 (or git master), you can script things so that a "virtual" display gets created automatically when someone connects to VNC, and removed when they disconnect.
The problem with UDP for video is that, on a lossy network, you either end up sending a lot of key frames or reinventing TCP.
There is a trick for achieving low latency video with TCP: set SO_SNDBUF to the lowest possible value and do your own buffering. If your buffer grows too large, lower the bitrate and/or drop frames.
I'd argue that on a lossy network you will never have decent video (with decent latency) so for interactive sessions you don't really have to care about lossy network, it isn't worth the hassle anyway.
That is true, the network needs to be stable in any case, but the keyframes have "bursty" traffic, therefore increasing the latency compared to b-frames (and p-frames)
Ever since h264 there is a feature called intra-refresh, which allows you spread key frames over time, reducing the burstiness of the transmission (and therefore improving latency in most scenarios)
First TCP handshake:
Then VNC handshake: If no authentication is used: If the client chose authentication, more steps are added in between. E.g. if the client chose TLS this happens: If, for example, each step takes 100 ms, you should have a total of 1.2 s without auth and 2.1 s with TLS.