Hi
Tell me please, the moving of KRFB and KRDC to the standalone libvnc in 14.1.0, this is for complete breakage of KRFB and KRDC or I misunderstand something? :)
KRFB is just dead cycling in some QObject destructor at any connection before the password transmission even.
KRDC shows the remote screen, but it is hanging mostly, when there impossible to close the program, only kill.
Whether I must downgrade the KRFB and KRDC code back to 14.0.13?
On 2023/05/05 03:38 AM, Roman Savochenko via tde-users wrote:
Hi
Tell me please, the moving of KRFB and KRDC to the standalone libvnc in 14.1.0, this is for complete breakage of KRFB and KRDC or I misunderstand something? :)
KRFB is just dead cycling in some QObject destructor at any connection before the password transmission even.
KRDC shows the remote screen, but it is hanging mostly, when there impossible to close the program, only kill.
Whether I must downgrade the KRFB and KRDC code back to 14.0.13?
Hi Roman, I don't use krdc and krfb regularly, but I did some tests. I can krdc(using vnc) into a krfb session on another machine (linux to linux) and it seems to work fine. krdc (using rdp) into a Windows machine does not work. I talked with Slavek and he uses krdc (using vnc) daily to connect to several machines and he does not have any issue.
Waht kind of connection is your specific case? rpd or vnc? to windows or linux machines?
Cheers Michele
Hi, Michele
05.05.23 13:58, Michele Calgaro via tde-users wrote:
On 2023/05/05 03:38 AM, Roman Savochenko via tde-users wrote:
Tell me please, the moving of KRFB and KRDC to the standalone libvnc in 14.1.0, this is for complete breakage of KRFB and KRDC or I misunderstand something? :) KRFB is just dead cycling in some QObject destructor at any connection before the password transmission even. KRDC shows the remote screen, but it is hanging mostly, when there impossible to close the program, only kill. Whether I must downgrade the KRFB and KRDC code back to 14.0.13?
I don't use krdc and krfb regularly, but I did some tests. I can krdc(using vnc) into a krfb session on another machine (linux to linux) and it seems to work fine. krdc (using rdp) into a Windows machine does not work. I talked with Slavek and he uses krdc (using vnc) daily to connect to several machines and he does not have any issue.
Waht kind of connection is your specific case? rpd or vnc? to windows or linux machines?
All are native ones — only VNC on fast hardware in local network and Debian 11:
1. KRDC(14.0.13) > KRFB(14.1.0) = dead-cycling KRFB without a possibility even connect more 2. KRDC(14.1.0) > KRFB(14.0.13) = very slow KRDC screen with no possibility of closing
And all this works only with 14.0.13.
If you talk that works, I'll see what is happening with krfb in my case.
And right now I have got it working, seems after the true password sending from the KRDC cache, which I entered before for 14.0.13 (Debian 10) on the same PC.
So the dead-cycling caused by a wrong password.
And KRFB is traditionally crashed after the session disconnecting, what was fixed long ago by my patch, also in TGW.
All are native ones — only VNC on fast hardware in local network and Debian 11:
- KRDC(14.0.13) > KRFB(14.1.0) = dead-cycling KRFB without a possibility even connect more
- KRDC(14.1.0) > KRFB(14.0.13) = very slow KRDC screen with no possibility of closing
And all this works only with 14.0.13.
If you talk that works, I'll see what is happening with krfb in my case.
I didn't do a mixed test (R14.1.0 and R14.0.13), just R14.1.0 to R14.1.0. KRDC (vnc) to KRFB did show some slowness in updating, like 500ms or so and it seemed weird to me since this was over a local wifi network. I don't know if R14.0.13 was quicker, you have definitely more experience on this than I have.
It is definitely good to look into those issues you highlighted and I think it would also be good to make sure mixed configuration connection (R14.0.13 to R14.1.0 or viceversa) still work. The switch to standalone libtdevnc was done many years ago in master. I am not sure of the details but in any case if it does not behave as well as R14.0.x we have to look into this, since regressions are not good.
Cheers Michele
Michele Calgaro via tde-users wrote:
I didn't do a mixed test (R14.1.0 and R14.0.13), just R14.1.0 to R14.1.0. KRDC (vnc) to KRFB did show some slowness in updating, like 500ms or so and it seemed weird to me since this was over a local wifi network. I don't know if R14.0.13 was quicker, you have definitely more experience on this than I have.
It is definitely good to look into those issues you highlighted and I think it would also be good to make sure mixed configuration connection (R14.0.13 to R14.1.0 or viceversa) still work. The switch to standalone libtdevnc was done many years ago in master. I am not sure of the details but in any case if it does not behave as well as R14.0.x we have to look into this, since regressions are not good
If I may add some notes from my experience I'm not using KRFB, but frequently KRDC. KRDC works fine to the tightvnc linux machine, but can not cope with modern windows RDP. I was looking into the code, because xfreerdp is working just fine with new windows but had to give up as it was too complicated to adjust and it was also too time consuming :( So now for windows 10 I have scripts that run xfreerdp
Dne so 6. května 2023 11:29:55 deloptes via tde-users napsal(a):
Michele Calgaro via tde-users wrote:
I didn't do a mixed test (R14.1.0 and R14.0.13), just R14.1.0 to R14.1.0. KRDC (vnc) to KRFB did show some slowness in updating, like 500ms or so and it seemed weird to me since this was over a local wifi network. I don't know if R14.0.13 was quicker, you have definitely more experience on this than I have.
It is definitely good to look into those issues you highlighted and I think it would also be good to make sure mixed configuration connection (R14.0.13 to R14.1.0 or viceversa) still work. The switch to standalone libtdevnc was done many years ago in master. I am not sure of the details but in any case if it does not behave as well as R14.0.x we have to look into this, since regressions are not good
If I may add some notes from my experience I'm not using KRFB, but frequently KRDC. KRDC works fine to the tightvnc linux machine, but can not cope with modern windows RDP. I was looking into the code, because xfreerdp is working just fine with new windows but had to give up as it was too complicated to adjust and it was also too time consuming :( So now for windows 10 I have scripts that run xfreerdp
Hi Emanoil,
krdc uses rdesktop as a backend for RDP protocol. And rdesktop has not been updated for a long time - looking for a new maintainer. We should probably consider using XFreeRDP as a new backend for RDP protocol in krdc.
Cheers
Slávek Banko via tde-users wrote:
Hi Emanoil,
krdc uses rdesktop as a backend for RDP protocol. And rdesktop has not been updated for a long time - looking for a new maintainer. We should probably consider using XFreeRDP as a new backend for RDP protocol in krdc.
Yes, exactly, I also think this is the way to go. From my experience XFreeRDP is working fine, while rdesktop seems to be outdated in the context of windows. I do not remember exactly why it was not easy to replace rdesktop as backend or it was just lack of time and priorities.
But it would be great if we could have XFreeRDP as backend in KRDC
BR
On Sun, 7 May 2023 15:14:53 +0200 Slávek Banko via tde-users users@trinitydesktop.org wrote:
Dne so 6. května 2023 11:29:55 deloptes via tde-users napsal(a):
If I may add some notes from my experience I'm not using KRFB, but frequently KRDC. KRDC works fine to the tightvnc linux machine, but can not cope with modern windows RDP. I was looking into the code, because xfreerdp is working just fine with new windows but had to give up as it was too complicated to adjust and it was also too time consuming :( So now for windows 10 I have scripts that run xfreerdp
Hi Emanoil,
krdc uses rdesktop as a backend for RDP protocol. And rdesktop has not been updated for a long time - looking for a new maintainer. We should probably consider using XFreeRDP as a new backend for RDP protocol in krdc.
I use rdesktop (currently 1.9.0) directly to connect to a Win10 machine, and it does still work if it manages to login to the remote machine without disconnecting randomly, which it does at least half the time. Once the login completes successfully, the connection is stable.
Switching krdc's backend to an actively-developed package is probably the best move for future-proofing, though.
E. Liddell
Hi, Michele
05.05.23 15:55, Michele Calgaro via tde-users wrote:
All are native ones — only VNC on fast hardware in local network and Debian 11:
1. KRDC(14.0.13) > KRFB(14.1.0) = dead-cycling KRFB without a possibility even connect more 2. KRDC(14.1.0) > KRFB(14.0.13) = very slow KRDC screen with no possibility of closing
And all this works only with 14.0.13.
If you talk that works, I'll see what is happening with krfb in my case.
I didn't do a mixed test (R14.1.0 and R14.0.13), just R14.1.0 to R14.1.0. KRDC (vnc) to KRFB did show some slowness in updating, like 500ms or so and it seemed weird to me since this was over a local wifi network. I don't know if R14.0.13 was quicker, you have definitely more experience on this than I have.
It is definitely good to look into those issues you highlighted and I think it would also be good to make sure mixed configuration connection (R14.0.13 to R14.1.0 or viceversa) still work. The switch to standalone libtdevnc was done many years ago in master. I am not sure of the details but in any case if it does not behave as well as R14.0.x we have to look into this, since regressions are not good.
So, the KRFB hungs at wrong passwords and crashes at the session closing are from one source and that is the thread force closing and that I have fixed long ago by the patch *krfb-crash_at_disconnect.patch* — http://bugs.pearsoncomputing.net/show_bug.cgi?id=2972.
And the performance decreasing is a real regression of the VNC libraries due to switching to some hungrier compression algorithms what causes: • removing support of the "Low quality" in the server library, when the client one still works and fast; • high CPU load on server, especially for the "High quality"; • high CPU load on client at enabling the scale.
Once I am going to compare performance of the new libraries in 14.1 and old ones in 14.0 and maybe return the old one at very high difference taking in account of missing any advantage in the new ones.
The second patch *krfb-new_symbols_appending.patch* is for many special symbols support, which are also all symbols different from ASCII-Latin, especially the Cyrillic ones which I can enter only about 10 and next I get only ASCII. This code is missing in the VNC server library, hosted in vncserver and I have adapted it long ago for KRDC with notifying in Bugzilla — http://bugs.pearsoncomputing.net/show_bug.cgi?id=3014
Regards, Roman
Hi, Michele
17.05.23 22:33, Roman Savochenko via tde-users wrote:
05.05.23 15:55, Michele Calgaro via tde-users wrote:
All are native ones — only VNC on fast hardware in local network and Debian 11:
1. KRDC(14.0.13) > KRFB(14.1.0) = dead-cycling KRFB without a possibility even connect more 2. KRDC(14.1.0) > KRFB(14.0.13) = very slow KRDC screen with no possibility of closing
And all this works only with 14.0.13.
If you talk that works, I'll see what is happening with krfb in my case.
I didn't do a mixed test (R14.1.0 and R14.0.13), just R14.1.0 to R14.1.0. KRDC (vnc) to KRFB did show some slowness in updating, like 500ms or so and it seemed weird to me since this was over a local wifi network. I don't know if R14.0.13 was quicker, you have definitely more experience on this than I have.
It is definitely good to look into those issues you highlighted and I think it would also be good to make sure mixed configuration connection (R14.0.13 to R14.1.0 or viceversa) still work. The switch to standalone libtdevnc was done many years ago in master. I am not sure of the details but in any case if it does not behave as well as R14.0.x we have to look into this, since regressions are not good.
So, the KRFB hungs at wrong passwords and crashes at the session closing are from one source and that is the thread force closing and that I have fixed long ago by the patch *krfb-crash_at_disconnect.patch* — http://bugs.pearsoncomputing.net/show_bug.cgi?id=2972.
And the performance decreasing is a real regression of the VNC libraries due to switching to some hungrier compression algorithms what causes: • removing support of the "Low quality" in the server library, when the client one still works and fast; • high CPU load on server, especially for the "High quality"; • high CPU load on client at enabling the scale.
Once I am going to compare performance of the new libraries in 14.1 and old ones in 14.0 and maybe return the old one at very high difference taking in account of missing any advantage in the new ones.
The second patch *krfb-new_symbols_appending.patch* is for many special symbols support, which are also all symbols different from ASCII-Latin, especially the Cyrillic ones which I can enter only about 10 and next I get only ASCII. This code is missing in the VNC server library, hosted in vncserver and I have adapted it long ago for KRDC with notifying in Bugzilla — http://bugs.pearsoncomputing.net/show_bug.cgi?id=3014
And now about the measurements:
*KRDC*: AMD A8-6500 APU 3.5 GHz, Debian 11, connecting to RPi3 with TDE 14.0.13 and 1824x924, for CPU loading (%) / traffic (kbyte/s) • 14.1.0 (Low+scale, Middle+scale, High+scale): 8.5%+*100%*(*HANGING*) / 40K, 8.0% / 60K, 8.0% / 200K • 14.0.13 (Low+scale, Middle+scale, High+scale):2%+2.7% / 19K, 2.7%+3.3% / 34K, 3.3%+4.0% / 150K
*KRFB*: AMD A8-6500 APU 3.5 GHz, Debian 11, connecting from TDE 14.1.0, for CPU loading (%) / traffic (kbyte/s) • 14.1.0 (Low, Middle, High): *106%* / 50K, *284%*(*HANGING*), *106%* • 14.0.13 (Low, Middle, High): 56% / 30K, 56% / 38K, 56% / 150K
So, I have returned back KRDC and KRFB from 14.0.13 and that is fine working again and TDE is usable already for me!
P.S. The reverting patch included.
Regards, Roman
-
deloptes -
E. Liddell -
Michele Calgaro -
Roman Savochenko -
Slávek Banko