Re: 1.3.9 dev 5

[SkyBeam]

I did actually do some tests with 1.3.9 dev 5. It did not go very well. There seem to be lots of logic and state issues:

• I did run UVNC as service, the system tray icon does appear (if enabled in options). OK.
• Right-click on the menu and selecting cloud connect opens the cloud connect dialog. OK.
• Enering cloud.uvnc.com and hitting "start" will turn the red light into yellow. OK. (still I believe the process is wrong and should first display the server name on top and then the button and status below - top-down user flow)
• Using viewer with same cloud server is turning both lights green. OK.
• Connecting from client now asking for password (authentication on UNVC server side enabled, no mslogon2, just plain built-in authentication used). OK.
• Client is connecting to remote screen. OK.
• When changing any viewer settings like encoding or mouse throttling it seems like I can still move the cursor but my screen is not updated any more. Perhaps this is due to some sort of re-connect as it magically seems to start transferring the screen again after some time (10-20 seconds). Partially OK.
• Disconnecting the client disconnects the screen properly. OK:
• Re-opening client will now only show "yellow" status indicator while cloud connect on Server side still showing "stop" button and green indicator. NOK.
• Connecting again is impossible. NOK.
• Hitting the "stop" button on server side turning status indicator "red". OK.
• Hitting the "stop" button on server side will still display "stop" button and does not allow to hit "start" again. NOK.
• Closing the cloud connect dialog on server side and re-opening does not change anything, still "stop" is shown and red indicator. NOK.
• Stopping UVNC service will make the tray icon disappear but it keeps one winvnc.exe process running. NOK.
• Starting UVNC service again will not show the tray icon but make my cursor "flicker" in regular intervals. UNVC has no function in this state. NOK.
• Stopping the service and manually killing winvnc.exe resolving the problem allowing me to start the service again and start over. NOK.
• If I enter wrong password during connect/authentication the server goes immediately into "red" status and stops itself. My client can't connect staying in "Password requested" state. Manual closing of the client and manual press of "start" on server is required to re-try. I would expect the server to stay enabled until it is stopped. NOK.
• Running "winvnc.exe -cloudserver cloud.uvnc.com" does not bring up the cloud connect dialog. No matter if the service is running or not. I have been unable to open the dialog via command-line and of course been unable to start cloud connect using command-line on server side. NOK.

[Rudi De Vos]

Thanks for testing and finding dev 45

The cloud connect still require some work, possible some extra server is needed to keep track of the status ( web api).
Using udp you only know when someone connect but never know when it disconnect. It all reset after a while but it's not responsive enough for a real working app.

I hope that normal connections are back working including the backward compatibility with 1.2.x.

[SkyBeam]

Thanks for your support and development.

I did not actually test backwards compatibility but I can do this later. Since the service was running as normal I would have expected it to work normally. I will also test the connection message via traditional repeater (which was broken in latest 1.3.8 release).

I agree with status of UDP as UDP is stateless. But still if I properly disconnect it should allow me to re-connect. At least I would have guessed that there is some proper disconnect message sent. Also there should always be a thread available to establish new cloud connections. So if there is one already it should still allow another one. After successful authentication the session might replace/close the existing ones. This would allow anyone to re-connect any time. If multiple connections are opened only the newest one will survive. I don't think cloud-connect does need to support multiple sessions at the same time. Even though this is supported by UVNC.
Alternatively cloud connect could allow any number of incoming connections and if I lose connection I can just start another one and I could terminate the others via UVNC tray icon or they can be auto-terminated after some timeout if no incoming traffic is detected for a certain amount of time - not sure if there would be any heartbeat messages expected on the RFB protocol or if it is possible to send some (in both directions) and terminate messages based on those (e.g. heartbeat packet every 30 seconds, disconnect if no heartbeat received for 90 seconds).

However at the moment the server does not allow any re-connect when it is already handling a connection. There should always be a thread opening a new session while a dedicated thread handling established sessions. Also when pressing the "stop" button it should terminate any open session and allow to start again to run a listener thread. So on server-side you could always stop cloud connect (and terminate all sessions) and then re-start cloud connect allowing new sessions. Currently "stop" seems to do nothing except setting server to limbo state (no cloud connection, impossible to start again).

Thanks again for all the effort. Looking forward to use cloud connect on my own cloud connect service too. I would also like to provide a shortcut for my users to open the cloud connect dialog, this is why I asked for the command line switch. Would be great if there is a command-line option to launch cloud connect and start connection immediately. So I can have my server connecting to the repeater using pre-configured ID but if repeater is unavailable I can ask users to run the cloud connect shortcut so they are presented an ID to hand over to me instead.
Currently I understood the ID is based on MAC address. So it should be fairly unique and should not change (at least on a specific machine) unless the NIC is exchanged or MAC is changing. Though there is a small risk of duplicates as MAC only need to be unique on the same routing segment but UVNC might be used across multiple segments.

[Rudi De Vos]

Download
https://www.uvnc.eu/download/1390/UltraVNC_139_dev5.zip

[SkyBeam]

Just note my feedback above was about dev5 already, not dev4.

[Skyfighter]

@SkyBeam
I believe Rudi updated the dev5 binaries because the timestamps and hashes/checksums changed. (My download from the end of october contains files dated on 26th october, now a download contains files dated on 06th november.) Not sure if this was intended... Sadly I had no time to test, so I don't know if some kind of functionality changed.

[Rudi De Vos]

new certificate, update exe to be sure it's working ( before both were active, and didn't got an error when one was forgotten to replace)
Indeed the date changed, but no new code was added.

I"m current doing some tests with windows 11
-seems headless displays only have one resolution anc can be changes ( OS issue)
-clipboard was not working, need to do some tests again


Another nice one that was reported
-Server isn"t responsive, but is still listening
-reboot does not solve it
-reinstalling the same release solves it ( a reinstall just replace the dll end exe and keep the settings)
It's strange that replacing the exe with the same exe solves it

[VNCHELP890]

...
-Server isn"t responsive, but is still listening
-reboot does not solve it
-reinstalling the same release solves it ( a reinstall just replace the dll end exe and keep the settings)
It's strange that replacing the exe with the same exe solves it

Again, I would look at Windows Firewall first. That has given us problems in the past. A reinstall would tell it to allow the program. All of this is a wild guess on my part. Good luck, and let us know if you find anything. The best way is to go to 1.3.9.5.1 or something else to denote a new test version.

[Rudi De Vos]

Thread closed.

Please use the latest UltraVNC or UltraVNC SC releases:
- viewforum.php?f=56