Filetransfer stuck and freeze

[Prisma]

Hello Rudi,

how you're doing? RonnieM wrote something about file transfer, so I was remembered to report a problem we have since months:

Since a few months we have very fast upload bandwidth, 10 mbit. File transfer to vnc server should be very fast, but it isn't. Of course we know that the bandwidth is also limited by the download speed of vnc server.
We see the transfer progress bar stuck several times, freezing / in-reactive transfer dialogue and a turning crazy donut. Sometimes the viewer crashes completely. Between the breaks transfer is very fast.

It sounds for me, that it could be related to buffers / buffer management / stream compression.
Theoretically it could also be related to a clients AV scanner (Possibly we could find a modus operandi for writing files a way that AV scanners "more like"...)

Did you ever notice something similar? Would you please cross-check the behaviour with fast connections?

[Prisma]

Any Updates? Anybody else with this observation?

[Rudi De Vos]

filetransfer
viewer->server higher speed

test viewers

http://www.uvnc.eu/download/1215/vncviewer_1215.zip

[Prisma]

Hello Rudi,

thx for you answer.
With new viewer we recognized a lightly better throughput on connections having no hangs anyway. Speed from viewer->client 5000kb/s instead of 4500 kb/s.

But on connections having hangs the new viewer shows no difference.
Tested with connection speed of viewer cable 150mbit down/10mbit up and server side adsl 50mbit down/10mbit up.
Transfer mostly hangs. This results in an average speed of 350 kb/s which is far away from physical possibility. http based speed tests on both sides show full speed.

We are wondering. Normally packet sizes, TCP buffers sizes etc. are managed by th OS and you shouldn't have to do with this anything.
Or did you tweak some parameters for some reasons?

[Rudi De Vos]

Because of the messages limitation we can only send 1000 packets /seconds
1000 x 8 kbs -> this give tha max of 8000kbs

The change was to send bursts of 8k packets ( 1000 x (8k +8k + 8k) tests in loopback give now a max of 200 000k

Your physical limitation 10mbit -> 1.2mb -> 1200kbs.
If it's WiFi it's even lower.

The packet sizes of vnc have nothing to do with tcp packets.
We don't touch the network packages, this is optimized by the OS.

[sfhub]

But on connections having hangs the new viewer shows no difference.
Tested with connection speed of viewer cable 150mbit down/10mbit up and server side adsl 50mbit down/10mbit up.
Transfer mostly hangs. This results in an average speed of 350 kb/s which is far away from physical possibility. http based speed tests on both sides show full speed.

I am wondering if your problem and my problem are the same. In my case, the uvnc server seems to be not getting enough time slices to process things at speed, but only when it is running as a service. I can tell this is the problem because when I bring up the server properties page using the taskbar icon, the transfers immediately become unstuck and very fast. I am testing with server on GigaBit LAN and Client on 100Mbps LAN.

viewtopic.php?f=71&t=32810

[Rudi De Vos]

This are 2 different things, but as file transfer is client/server also related.

Your test show some interesting results the difference between service/app and option popup is worth to investigate.

[sfhub]

This are 2 different things, but as file transfer is client/server also related.

I understand the fix you put in the client to increase the amount of KB processed while adhering to 1000 packets/second limitation is a separate issue.

It seems even with that change Prisma/OP is still seeing stalled transfers that start/stop/start/stop.

This is the portion of his problem for which I am asking if it is the same problem. I wanted to see if Prisma/OP could bring up the Properties page on his uvnc server using the icon in the taskbar and see whether this would improve his situation.

I am suspecting Prisma/OP is also seeing two separate issues, the one you addressed, and also the one he is still seeing with the stalled transfers, which is similar to what I am seeing.

...
But on connections having hangs the new viewer shows no difference.
...

[Rudi De Vos]

Reverted back to 1.2.1.2 and added the modifications back except the latest ipv6 stuff.

**Server was indeed using the menu to send packages.
As test, changed the method, FT is faster but screen updates are to slow to be useful during transfer.
The transfer is direct without the menu, this should overcome the service issue's where the menu and winvnc run in seperate sessions.

**reconnect High cpu fix
A loop was running without any sleep, checking 1000/sec while it should only check 1/s.
Possible blocking other threads...

http://www.uvnc.eu/download/1215/winvnc1216Test.zip

[sfhub]

**Server was indeed using the menu to send packages.
As test, changed the method, FT is faster but screen updates are to slow to be useful during transfer.
The transfer is direct without the menu, this should overcome the service issue's where the menu and winvnc run in seperate sessions.

I confirmed this does fix the slow transfers when uvnc server is running as service issue.

As to the comments about screen updates too slow to be useful, I am not sure if that was a temporary situation while you experimented or was supposed to apply to 1216 that I downloaded.

When I minimized the transfer window, the transfers slowed down (or stopped, I forget) and the screen updates were usable.

Just to document, with server on GigaBit LAN and client on 100Mbps LAN, I can send to server at 8041 KB/sec (KiloBytes/sec)
I can retrieve file from server at 11,481 KB/sec (KiloBytes/sec)

So retrieving files over 100Mbps connection from server is operating close to theoretical. Sending files to server is about 2/3 of theoretical. It is perfectly acceptable to me, but I am not sure why there is asymmetry. Perhaps the scheduling is different for send vs receives to optimize for some performance/responsiveness?

[Prisma]

Hi,

sorry, I was on vacation. Back now. The test link is somewhere broken...

[Rudi De Vos]

You can dowload the bin or setup from
http://www.uvnc.com/downloads/ultravnc/ ... -1215.html

exe were released as 1215

[Prisma]

hmm, let me ask one more question. Is it a server or a viewer side improvement? From what I've understood it is a server side improvement. Just to be sure...

[Rudi De Vos]

new viewer: faster transfer from viewer to server
new server: faster transfer from server to viewer

Improvement could only be done on send site.

[sfhub]

hmm, let me ask one more question. Is it a server or a viewer side improvement? From what I've understood it is a server side improvement. Just to be sure...

As I understand there were 2 issues resolved.

1) client-side/server-side - packet processing limitation was restricting how much data could be processed on fast networks
2) server-side - transfer freezes/very slow transfers

[Rudi De Vos]

Indeed,


1) client-side/server-side - packet processing limitation was restricting how much data could be processed on fast networks
This is a viewer change..more packets/s can be send with less messages

2) server-side - transfer freezes/very slow transfers
This is a server change we send without the menu. More packets/s , messages are not longer used.

*sending a lot of messages make the GUI unresponsive...slow, freeze the app.

[Prisma]

Hello Rudi,

I had now time to investigate further with 1215 binaries. Unfortunately none of the above improvements solved our problems.
The transfer begins with rapid speed, but then freezes rather early, continues, freezes, continues etc. where the freeze periods get longer and longer. Finally the viewer crashes and that's it.

We use reverse connections with new repeater and secure vnc plugin. All 32-bit with XP winvnc binaries.
Would you please try to inspect the code if you see something what could cause the above described behaviour?

[Rudi De Vos]

As test i added a sleep 10ms after each FT block ( server site)... max speed is then 700k

result:
Viewer start ok, but after a few seconds the FT window get's slow.. just dragging the window on the screen until it lock.
After ctr-alt-del taskmggr... it's works back for a few seconds... just to press the close

It looks like when the viewer process a data block slower then data blocks are provided window messages get queued and
the complete Gui lock.

Changed to avoid that messages are used to send file data...and after 5 minutes of slow transfer i still could minize
to update screen and maximize the FT to get full speed ( just 700k in this case)

Are you able to do some test ?
Will post bins tomorrow

[Prisma]

Sure, I'll test it ASAP. I should have time this week.
But to clarify: It's when transferring data from viewer to server. Your're answer did sound like assuming the opposite.

Cheers

[Rudi De Vos]

indeed, viewer to server
test
server: simulate slow network by adding timout after datachunk
viewer: send full speed, to overload his message queue

[Rudi De Vos]

http://www.uvnc.eu/download/1215/vncviewerFT001.zip

[ddbivens]

First test, fast feedback... Sending and receiving files does not hang up!!!
If the remote PC is locked at the desktop waiting for C-A-D, I can close the File Transfer window with "X" or ALT-F4!!!
Sending a file to the remote PC is fast. I can click on the Stop button and the transfer stops.
Receiving a file from the remote PC is fast. I can click on the Stop button and the Stop button goes away but the transfer does not stop. I can't close the File Transfer window with the "X" or Alt-F4. If I right click on the icon on the task bar, I can End Task and the File Transfer window will close. If I reopen the File Transfer window the right side of the window for the remote PC will not display anything. If I close and open the VNCViewer window [and reconnect to the remote PC], the File Transfer window will work properly again.

[Prisma]

Crashes are gone, transmission is more continuously. Good work! Other bugs reported from ddbivens not tested.

THX a lot rudi!

PS: But transmission to test server is still unexplainable slow as hell (which was the origin of all crashes). Still investigating what's the difference between a http upload (which is very fast) and a winvnc servers upload. Possibly a QoS/Traffic-shaping problem... But hard to believe...

[Prisma]

AARG, no, still crashing. But not every time and not so early.

What's really better and very helpful: The viewer is much more responsive during transmission. At least one huge improvement

[ddbivens]

At work, I am getting excellent screen refresh over a slower network connection (but much faster than my DSL connection at home) to a satellite location. I had a need so I tested the File Transfer to a few PCs over fast and slower network connections. Transferring small files and folders works great from Windows 7 to Windows 7 (and Windows 10) PCs. Tranferring files from a Windows 7 PC to a Windows XP PC works great. Transferring folders from a Windows 7 to a Windows XP PC does not work. When I tried to send a folder named "_Digital Utilities" from a Windows 7/64bit PC to the user's desktop on a Windows XP PC it fails. This happens over a fast or slow network. I picked a fairly large folder so it would take a few seconds to transfer the file. That way I had a little time to see what was happening. I clicked on the "Send" button... I waited a few seconds while the folder was compressed then the transfer started. During the transfer a file named !UVNCDIR-_Digital Utils.zip was created on the desktop on the remote PC, but as soon as the transfer completed, the file was deleted, but no folder was created. I tried different folders. It appears I can't transfer folders from Win7 to XP, but I can transfer files individually and multiple files selected at the same time. I have not tested transferring files from XP to Windows 7.
[Edit] After several other tests, I had one file transfer failure and one non-start (it zipped the file, but never started transferring.) All other transfers went through without a hitch.

[Prisma]

!! remarkable !! never saw such a behaviour. I'd suspect user right problems or AV in such cases.

[Prisma]

The only similar case I'm able to remember is: A transmission to a windows desktop was not possible because of parallels virtualization on a mac. The desktops filesystem was shared between mac and windows. And Windows was tweaked to be able to access the desktop, but winvnc.exe was of cause not tweaked etc...

Hmm... did you try another winvnc.exe? Is it really related to Rudis changes??

[Rudi De Vos]

folder FT
local zip, transfer zip, remote unzip
Usual the temp is used to copy the zip "!UVNCDIR-_Digital Utils.zip"
Looks like permission issue.

The FT doesn't depend on any viewer OS setting, you just need to be ablt to read the folder.
Remote you extract as "remote desktop user" or admin if impersonating is of... in that case you have full access to local folders.
( server option)

Try to copy afolder to the desktop and see if it extract !! You can aslo modify the FT impersonation, byt be carefull this allow to overwrite system files.

[ddbivens]

(moving this item to a new thread.)

[ddbivens]

(moving this item to a new thread.)