Compression

[thunder]

I am missing one thing especially over slow internet connections:

Optional Basic file compression (e.g. gzip) before sending out any data

Why do we need that?

Well, create sample file under Windows OS, open CMD as admin and type:
 

cd "C:\your\BTSync\directory"fsutil file createnew 10mb 10000000

This commands creates an empty file with a length of 10000000 bytes equal to 10MB but the content are just zeros.

If zipping this file with just basic compression it goes down to just about 12 KB in total size.

BUT When BTSync transfers it the full 10 MB are send out.

If compression is implemented it will speed up on slow internet connections when transferring files dramatically, especially if they have a high compression ratio.

This should not be too difficult to implement and saves bandwidth which comes also very handy when we are thinking about mobile devices with limited data plans.

I think this feature should be allowed to be enabled or disable in the options depending on the requirements of users, because it might lead to slightly higher CPU load. An option with the ability to choose a compression level would be even better.

 

[rdebath]

Optional Basic file compression (e.g. gzip) before sending out any data

I agree, any encryption tool should compress it's input because it prevents other tools from doing it later.

However, it's likely that the files are already uncompressible for some reason so I would strongly recommend a "compression lite" eg lzo compression (lzop), that doesn't try too hard and can probably keep up with most (even high) line speeds.

[Automatic Coding]

I agree, any encryption tool should compress it's input because it prevents other tools from doing it later.

However, it's likely that the files are already uncompressible for some reason so I would strongly recommend a "compression lite" eg lzo compression (lzop), that doesn't try too hard and can probably keep up with most (even high) line speeds.

Or give the option for the users to pick on a share-based option.

For instance, if I share a coding project with someone, it's mainly going to be text (Excluding the one or two binary files from the bin folder, a few compiled libraries and MAYBE a few images), I'd prefer it to work hard and transfer less data than think "meh" and save me a bit of CPU power. However, if I was sharing my photo album with my mother, I'd much prefer no compression what-so-ever as I would presume that the files were already compressed well enough by the encoder.

[randomguy]

PLEASE add compression for the network traffic.

 

I have gigabytes of data that will compress down to the 10th of the size (or more), but I cannot compress them on-disk as they need to be left uncompressed so they can be used day-to-day.

 

Uploading a few hundred megs is ok.  Uploading gigabytes is a huge jump in size, kills my quota and the network here is slow.

 

Dropbox handles it with ease.  Bittorrent takes days.

 

[stalk]

Hi. I also subscribe to the compression of traffic. 

In our project, the data is compressed greatly. At the moment, very expensive to send traffic without compression.

I'll hope that this feature will be implemented.

[ChrisH]

I use BTSync only over tinc connections with compression already in place, but +1 from me anyway.

Since the transfer is already chunk-based it should be trivial to compress the chunk before sending it and decompress it before writing it to disk.

[piotrnik]

I would also like to get on the bandwagon here.  I would guess that compress-> encrypt-> send-> decrypt-> decompress-> reassemble would probably be the most efficient way, but I'm no engineer.  

[ChrisH]

Yeah. Encrypted data does not compress well (or at all).

[rstarkov]

Pretty please, a very fast scheme like LZO or LZ4 adds extremely little overhead, so little in fact that one can compress every chunk to be transferred, see if it grew, and if so send it out uncompressed.

[gawkla]

+1 from me, please add compressions

[daishi4u]

Great idea! +1

Sent from my SCH-S738C using Tapatalk

[trevellyan]

+1 for compression - probably wouldn't need to be optional with something like LZ4.

[yvitek]

+1 for compression on the fly for some files (choosing by extensions)

[kibrock]

Yes, it's a great idea! This function would be very helpful when you synchronize large files.

[ultrakyo]

+1

I am not seeing this feature available yet in 2.4.4, hope to see this implemented.