Filetransfer stuck and freeze

[Rudi De Vos]

Thanks for the detailed info...
Installing some network simultaion software to be able to lock/crash in debug mode..

[Prisma]

@ddbivens:
Thank you for your help. I don't have much time for testing and I'm only able to check in short if my reported problems disappear or not. I'm not able to test everything in depth. So, I very very appreciate your help. A good software can only become better, when engaged user help to improve and test it.
But I'm not sure if the problems you've reported and the tests you did are related to my initial posting. Possibly it's better to report your results in an independent thread.
Please don't misunderstand me and excuse me if I'm wrong.

[Rudi De Vos]

Fast in the beginning... and after x% slow

Keep in mind that when you have a "!UVNCPFT-" file, next Filetransfer to the same spot resume the previous upload.
First part looks fast, it only check the content.

[Prisma]

To give you an idea what could be the problem I made a video. Sometimes you see something and you think, uh, yes of course, this is because...
https://youtu.be/ITA7FfGStAk

[Rudi De Vos]

If the vnc connection goes down, the viewer crash.
I'm adding code to prevent the crash, but this wil not prevent the disconnect.
The crash is a result, not the cause.
Does the ping to that server stay alive during FT ?

Your transfer is extreme slow 200kb.
What's the network connectionand type.

[Prisma]

I wouldn't call that slow.

This is the server side:


This is the viewer side:

[Rudi De Vos]

my test
VNC started as app in a RDP session

Server upload 460Mbps download 20MBps USA
Viewer upload 8Mbps download 40Mbs Belgium


theoretical max speed is around 1 mb/s
Actual speed 0.87Mbs using vnc FT

Doesn't look that bad in my case.
As test i upload file of 4GB mp4

compression ON, but doesn't compress a lot
No encryption
15ms to send a 8k block

[Prisma]

Did you try this with secure plugin, reverse connection and repeater behind NAT?
Maybe the connection handling of the repeater is the bottle neck?

[Rudi De Vos]

Not yet,
current just playing with source options to optimize plain sending.
before 20ms -> 8k now 15 ms -> 8k

It's a fast pc, so compression doesn't have any impact (still need to test without comrpression)

Then i have a good base to compare - with encryption, with repeater

[Prisma]

THX Rudi!

[Rudi De Vos]

with encryption, still 0.85mb
WIth encryption + repeater 0.89mb going up to 0.925Mb
Crazy...faster with repeater then without LOL

Can you try with our public repeater
support2.uvnc.com.. standard 5901 and 5500 ports

[Prisma]

Thanks for the idea to use your public repeater. I had the same idea of an external standing repeater and thought about setting up a azure VM. You saved me hours of senseless work, because:
Still crashing, at 2:45 while using your repeater
https://youtu.be/kaCsWcFq21k

To find the problem:
* We did cut the second WAN interface we normally use, to be sure that it's not an LoadBalancer issue,
* We used an external repeater
* We deactivated the AV on the remoted machine
* We tested the connections, seems all stable.

I can't get it. Without any debug info we'll not be able to find the problem. This server is owned by us, therefore I'm able to test so much. But we do have this problem with many customers.

Could you please try to fix the crash when disconnected first. Then we are able to test if the crash is really related to a real disconnect.

[Prisma]

hmm, when connection is interrupted -> filetransfer initiates reconnect (with timeout). Possible? Or a huge project?

[Rudi De Vos]

Viewer FT crash fix ( detect disconnect) + tuning some parameters.

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

[Prisma]

Nope, sorry. Still crashing at 5:20
https://youtu.be/KYjkh3KxE-0

As I said, I don't suspect the connection persistence. Data, freeze, data, longer freeze, data, longest freeze, crash -> sounds like overflow

But anyway, thank you for your engagement. We very appreciate it! Should I record something with wireshark, do we have some debug options?

Shall I post the viewer and server configuration?

[Rudi De Vos]

I could crash the viewer by pulling the server plug while the viewer FT was running.
Bugfix was for this unexpected disconnect...
Then the crash in your case is something else....dammm

[Rudi De Vos]

Crashrpt version
http://www.uvnc.eu/download/1215/vncviewerFT003.zip

On crash it generate a dump that i can analyse to trace the origin of the crashed function.
It use http://crashrpt.sourceforge.net/ internal.

[Rudi De Vos]

seems using the plugin it still crash...trying to fix that also.

[Prisma]

Ok, I'll wait until the plugin related crash is fixed. When the viewer then crashes anyway, I'll use crashrpt.

[Rudi De Vos]

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

This version should proper close is FT is interrupted.

[Rudi De Vos]

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

Found another one.
keepalive send messages to the uninitialized encryption after disconnect -> crash
This was the reason the reconnect didn't worked proper when the encryption was used.

[Prisma]

Ok, sounds good. I tested your last posted version and I got reported an disconnect. So, if you've fixed this error, the viewer should reconnect after disconnect.

But I'm wondering, why should 2 very fast connections break? Break after observed slowing down and stuck? While other internet connection problems are not observed?
So maybe we'll find a server side bug if we continue digging?!?

If I can do more than cross check the fixed bugs, please let me know.

[Rudi De Vos]

That the catch, i need to be able to break the connection in a repeatable way without pulling the cable.

Reconnect with FT.... to complex for now
Local/remote path, selected folders files...all need to be cached so the viewer can reuse it.

First we need to know if the connection stay alive or the fast packets kill something on the route

Can you run something like this so we can see if the pings change on break
test.bat > test.txt
---test.bat--
:start
echo %TIME%
ping ipserver
timeout /t 10 /nobreak
goto start
This info with the server log should give some clue

[AnotherUVNCuser]

I also experience this with 1.2.0.6 when:

- The remote computer has a bad/slow connection
- When i try to abort/close an active (running) filetransfer

(this has been tested under Windows 10 x64)


When clicking "Stop" in the filetransfer window, the active filetransfer continues as if no button was clicked in the first place.
This is bad when needing to abort/stop (big) file transfers. The only thing that goes away when clicking "Stop" is the Stop button itself...

Besides the above problem i'm also experiencing other type of problems related to the filetransfer function:

- When adding a removable drive with the filetransfer window already opened, the new drive doesn't appear
(it could be useful to enumerate/refresh the available/connected drives\network shares when clicking a Home/Root directory or \ button)

- You can't change (or copy+paste another) path by typing it in the text input bar (value is read-only)
(navigating a remote computer would be much better if you could could change the path by hand)

- A non (or badly) responding remote computer (due to bad/slow connection or wrong screen poll settings) makes the filetransfer function unresponsive too (keeps showing "> Browsing The Local Directory. Please Wait...")

In the last case i also can't close the remote window of the connected(?) computer.

update: I've noticed another problem which is pretty serious. When connected and opening the filetransfer window, the remote screen isn't updated anymore.. but, when keeping the filetransfer window open, the program becomes unresponsive and eventually you'll lose the connection.

Perhaps the screen updating and filetransfer happen in the same thread? (just a thought).

I really hope this will be fixed, because besides this and the above problems/limitations i've also noticed that UVNC seems to be less responsive than TightVNC, and that's a real shame/disappointment...

[Rudi De Vos]

FT window open -> only FT network active. Screen updates are locked
FT window minized-> FT and screen updates simultanious

[AnotherUVNCuser]

ok, good to know

But what about the other problems that i've mentioned?


Look at the filetransfer problem for instance:

When sending/receiving files is taking really long, i'm not able to stop/abort it by clicking the Stop button.
The filetransfer still continues...

[nzsolt]

There is maybe another bug: if the screen updating (youtube) or FileTransfer (get or put in minimized window) is active on remote screen and you do vnc chat on remote screen, it seems the data is not correctly mixed and the datastream decryption (zrle encription) is broken on viewer side. The chat text data injection (at winvnc.exe side) cause the problem.

[Rudi De Vos]

No fast fix.
I didn't wrote the FT myself, need to study and debug it to understand and fix.
Gonna take a few months.

[nzsolt]

The problem exists if you watch a video (for screen update) on remote computer and answer in chat.
Maybe the screen update and the chat messages are mixed.

[Rudi De Vos]

I was extracting all network code parts in a lib as part of a viewer rewrite.
Perhpas i find the bug while on that.