1.3.3 dev

[Rudi De Vos]

1) Dual mouse messages are blocked at viewer level ( same position and status)
2) Added colaboration mode (server)

One viewer has the mouse, the other show a cursor (hand)
On click, the controling viewer switch.


https://uvnc.eu/download/133/UltraVNC_1 ... _Setup.exe
https://uvnc.eu/download/133/UltraVNC_1 ... _Setup.exe

[SkyBeam]

2) Added colaboration mode (server)

One viewer has the mouse, the other show a cursor (hand)
On click, the controling viewer switch.

I actually like this feature. Would it make any sense to use it also to switch between remote and local input?
At the moment the second cursor (hand) is shown only when 2 viewers are connected. Switching between viewers is done using mouse click. But any time the local mouse is moved it's stealing the focus from the viewer immediately.
I think I have read some pages back that there is some issue with some touchpad drivers causing the local mouse cursor to toggle between two pixels or cause constant invalid input. If in such case the local input would not steal the focus but instead show as "local input hand" it would resolve this problem. Specifically as I guess such touchpads would generate x/y move events but no click events.
Also when using UVNC for remote support it would allow local users to point to specific items without actually stealing the focus and prevent nervous local users stealing the focus by just moving the mouse. A click would still allow them to get the focus intentionally.

It would also be possible to introduce a mode where each change of controlling viewer (excluding local user taking control) would pop up a notification (like the toolbar on top of the screen) asking for confirmation. This would allow a mode where each user can actually request control but requires the current user (or the local user as he can take focus any time) to confirm when another user asks for control effectively allowing some moderation. This would require a configuration preference toggle to allow either anyone getting the focus or just local user currently controlling user to grant permissions.

[Jojo67]

Hello Rudi

Would it be possible to add the following improvement in the next server release ?

We use VNC on about 850 PC under XP, Win7 & Win10, in 3 factories.
VNC Server is configured to accept all incoming connections, with VNC password (for full control) and VNC View Only password (for viewing). My problem is that many PC are starting viewers on the same target PC (for example 5 PC with viewers connected to the same "target server") and that situation can cause performance decrease on the target due to high CPU & Network load.
I will use the Idle-Timeout parameter to force all the viewers to automatically disconnect themselves after 5min for example and disable the AutoReconnect function (if that is possible with AutoReconnect = 0 ?).

But I would love a new function in the "Multi viewer connections" settings :
"Allow maximum number of simultaneous connections to X" (where I would set X=3) :
that implies that only X viewer can be connected at a time and when a new connection comes then the oldest connection is closed and the new one wins (so in fact there are a maximum of X simultaneous connections alive).

This is helpful in the following situation : a computer in production needs assistance, so the hotliner will connect to that target... but the hotliner too needs help from the software developer, so the developer can also start a connection simultaneously and both can see/correct the failure. These 2 new connections must "win" when they are already other computers connected to this target (so the oldest connection will be closed).

I hope my explanations are sufficient.
Thanks for your good job on UltraVNC !

[Rudi De Vos]

So some option like

Max connections [] 0 = unlimited
(*) kick oldest
(_) refuse new

[Sainsuper]

hi, just a questions
this new multiviewer function works in repeater mode too? with a single id?

[Rudi De Vos]

The multipointers works with all vncviewers. ( Tight,Real,Tiger...unix/mac)
It's independed of the way you connect

The current implementation is a server only change.

[Thomas Levering]

1) Dual mouse messages are blocked at viewer level ( same position and status)

if Old or Other Server
block at viewer level, is not working (no new code on github to debug/test self)

2) Added colaboration mode (server)

Sometimes if Resize a Window, the Cursor is wrong. (Hand -> Resize Symbol -> Normal Arrow)

3) @Sainsuper
Repeater + DSM + Only one ID is not working

[Jojo67]

So some option like

Max connections [] 0 = unlimited
(*) kick oldest
(_) refuse new

Yes Rudi, should be fine so... if you can include that in the next dev release it would be perfect and i can test it for you. Thanks.

[Rudi De Vos]

git updated

The multipoint works independed of the viewer of the way you conect to the server.
The hand is no cursor, but a bitmap we draw on a overlay window

moveMouse() {
if (has_contyrol)
injectmouse()
else
draw the image of an hand on the overlay window
}

On the server we created an overlay window, transparent + passthrough for each connection without control.
The hand is a normal draw image and handled as a normal screen update, this make is slower as the server need to detect the change and send it as screen update.
As soon as you take control, the window is destroyed and the viewer without control create is window.

[Rudi De Vos]

Code: Select all

    Rudi De Vos wrote:
    So some option like

    Max connections [] 0 = unlimited
    (*) kick oldest
    (_) refuse new



Yes Rudi, should be fine so... if you can include that in the next dev release it would be perfect and i can test it for you. Thanks.

A little issue found after implementation.
The viewers autoreconnect.
Kill oldest, oldest auto reconnect and new oldest is killed, he also reconnect.
This keeps looping forever.

[Jojo67]

Hi Rudi

And when in this case i set as default AutoReconnect = 0 to disable the "AutoReconnect" feature on the viewers ?

Otherwise, perhaps a message box could appear in the case of max clients already connected ? with the possibility of aborting and closing the viewer or the option "Kill the oldest client" to allow connection...

In all cases when the max connection is reached with "Refuse new" the new client that tries to connect must have a message box saying "Maximum clients reached (X clients) - Aborting connection !".

Joel

[Rudi De Vos]

Perhaps... we can mis use the blacklist
Adding the oldest viewer to the blacklist before killing will prevent for x time to connect from that ip address, reconnect wil fail if the blacklist time is higher then the reconnect settings.

yep, in case you set refuse and max is reached the viewer get a message -> max viewer reached

[Rudi De Vos]

Just noticed that the Crash test build also include the maxviewer with blacklist
https://uvnc.eu/download/133/crashrpt_133_2.zip
Settings are in advanced server properties
Give it a try.

ps: you also need to include the crashrpt files in the zip, required for this test build.
For functionality testing the behaviour is the same, it only generate a minidump on crash.
viewtopic.php?t=37238

[Jojo67]

Hi Rudi

I will be able to make some tests with "MaxConnections" this Friday (because i'm on Home-office at the moment).
I will tell you the results as soon as possible.

Bye.

[jlee3]

Is there a limitation of multi-monitor spanning with UVNC or is there a setting I need to do? I'm using a 4-GPU system trying to display out to 4 monitors. With 3 monitors enabled, UVNC displays the monitor span properly. However, once I enable the 4th monitor, all monitors other than the primary displays a grey screen in UNVC while spanned.

[Rudi De Vos]

downloads
https://uvnc.eu/download/133/UltraVNC_1 ... _Setup.exe
https://uvnc.eu/download/133/UltraVNC_1 ... _Setup.exe
https://uvnc.eu/download/133/UltraVnc_133_dev10.zip

1.3.3 dev 10
*Maxviewers
*multimouse option
*zlib fix
*winpe fix
*Possible crash fix ( minidump analyse)
*Zstd 1.5.0
*cleanup old code
*rdpmode fix

[ddbivens]

Curious observation. I pushed UltraVNC 1.3.3 dev 10 to about 500+ PCs this past weekend. If the PC is 64bit, if the PC has C:\Windows\SysWOW64, then the 64bit version of UltraVNC was installed. When I was looking at my inventory program showing these updates, I saw that 4 PCs were listed as UltraVnc (64-bit) 1.3.3 dev 10 and all the other 500ish PCs the inventory shows UltraVnc 1.3.3 dev 10. The vast majority of these PCs are 64bit with only about 50ish being 32bit. I can't see any reason for these 4 showing 64-bit and all others not showing 64-bit, but I thought I would mention this.