Update: UltraVNC 1.4.3.6 and UltraVNC SC 1.4.3.6: viewtopic.php?t=37885 Important: Please update to latest version before to create a reply, a topic or an issue: viewtopic.php?t=37864
I would love to see an option to shut off compression of files for transfer. (ususally when transfering directories) I've noticed that sometimes it takes longer to compress the files, transfer the files, then uncompress the files than it does to just transfer them (I'm sure it is not always the case). Adding an option to compress or not would be very nice!
In RC19 (next RC19.3), I've already reduced the compression param to 3 instead of 6 (default) in Zlib32 library.
It gives a boost to the directory compression and the resulting zip is still of reasonable size.
I could add an option that put this value to 0 (no compression), but it would have to be set on both side (viewer and server...).
Also going to try the 0 value by default: bigger directory zips to transfer, but the 0-Zipped transfered zip file will then be compressed "by packets" like regular tranfered files.
The drawback is that you need twice the disk space of the transfered directory content on both sides to do the transfer...
That's why I've started to work on recursive directory transfer to replace this directory-zipping trick. This way we can get rid of the zip32 dlls and the delta/resume transfer will also work for directory transfer (for each individual transferd file of the directory). Don't know when this recursive directory transfer will be done... it will added to RC19 only if it's stable and doesn't break the current FT protocole.
Thanks for the quick reply - sounds like you have it figured out. I like the recursive directory transfer solution. Hopefully it can be implemented smoothly. Getting rid of the zip dll files would be great. Only in software is having a "Small Package" a good thing.
Sam,
I suggest to leave it as an option. Compression is a big boost when transferring large files and I really see huge improvement over ftp (with text files ~7-10MB).
I understand this is not always the case, but leaving the option to compress is good
Don't get me wrong, I don't plan to get rid of the compression for file transfer.
Individual files are still compressed during the transfer (each packet is compressed individualy -> fast).
For directory transfer, I need to make a single file containing the whole directory and its files and subdirectories content. Enter the Zip-Directory trick...
But I've selected compression 6 while zipping this directory file before it's transfered. So it can take a long time for the zip to be generated...
What I do now is seleting compression zero for the directory-zipping: still one zip file to transfer but generated quickly.
Then while transfered, as it is not detected as already compressed, it is packet-compressed like any other transfered file.
BTW, I'm working on a Recursive Directory transfer so we can get rid of this time consuming directory-zipping step...
That sounds very promising !
But wouldn´t it still be nice to have a - separate - option for settings the compression rate used by zlib32 ?
As sometimes size doesn´t matter while CPU usage does or just the other way round (you´d be willing to spend lots of CPU time if you get a smaller size as a result...)
Yes, sounds like you have it under control. I like that trick you thought up. I dont think I would have done that, I would have gone to reading the dir and all files inside, making one list of dir's and one of files in each dir, creating the dirs on the other side, then with the lists of what file goes in each dir, one by one transfer them. //// maybe thats what your doing. haha
using latest code.... always... except when im not.
I just drop a vote to file transfer w/o comression, especially for directories, but even with only one file. We have Gb network, any compression is unnecessary this time. I belive, that lot of LAN users think the same.
I was happy to see that the VNC-Developers are taking up request fast and seriously ! It would be a great to help to have a switchbox for the compression on/off. That would make large directory transfers faster !
We'd like to inquire on the status of this feature request, and also put in our vote for the OPTION to disable file transfer compression completely. This request seems to have been active for years, and it seems unclear what's been going on with it. Thank you for any updates and info that you can share!
Meanwhile, we may have to look for another VNC type program with no-compression file-transfer that is viable for 32 & 64 bit clients and servers.
Thank you very much for such an otherwise useful program!
Ultravnc can only transfer a single file.
To be able to transfer folders we always zip the source. Zipping include folder structure, files and permissions.
On the remote site we use unzip to rebuild it.
It's not a simple options to re remove zip as it would also remove folder and multiple file transfer.
We could use a zero compressed zip, but this would be slower in 95% of the cases.
Creating the zip takes time. The slowest part is not the compression, but the file copy and data transfer.
Any chance of using 7-zip compression? The LZMA method would compress better and eliminate redundancy in the total package. LZMA2 would also improve compression speed for incompressible data
Seriously, its time to make the option to switch compression off or 0. There is no use trying to compress files that are already compressed. That's totally counter-productive. Trying to compress ISO, most all major media codecs, already compressed files, etc.. is just wasting time and delaying transfers.
I tried to transfer a 3.5Gb ISO today: waited 10m for it to try to compress just to find it it failed.