Less uploading traffic with incremental uploading-technic
When backing up a file and this file has changed, don't upload the whole file again, but analyse the file on a bit-level before and then just upload the real differences. As for example this backup software is doing it: http://www.qrecall.com/video/QuantaR4.... This would be better for everyone (exept those who really have slow machines)
2
people like this idea
I like this idea!
Tell me when this idea gets some attention.
The more people who like this idea, the more it gets noticed.
The more people who like this idea, the more it gets noticed.
Create a customer community for your own organization
Plans starting at $19/month
-
Inappropriate?The base construct of Wuala impede an incremental upload technique. All uploads are encrypted on you local system before they are send to Wuala. Therfore, You ́ll have a complete other file after editing and re-encrypting than the encrypted files was before you have edit it.
I see no other way than send unencrypted files to Wuala when you want a incremental upload after an edit. And... I like Wuala most for exactly that point, that no one, even caleido itself, can see my files. Best security I can imagine. ;)
-
hmmm, I see the problem...what do you think about splitting the file that is going to be uploaded in n pieces. Analyze every of the created piece to get n controlsums, then encrypt every piece and upload it. Then if the file has been modified, again split the file in a way that it would be possible to recognize which of the n pieces are still the same. Then just encrypt the new or modified pieces again and upload only those? -
Inappropriate?could be an idea. ;) I see also, that the need to reupload a whole file is a penalty for Wuala. But it must be a well proofed modification. ;) We ́ll, lets see what future will bring to us. ;)
-
Implementing such a feature with high priority would bring a big improvement to the whole Wuala-system I think. With that also the Timeline-feature that I really like, would be (very much) less storage space consuming for the Wuala-system as a whole, because it doesn't anymore has to store every single file-version, but just modified parts of it. If then a user requests a earlier version of a file the Wuala-system just has to deliver the modifications back to the user. For example 3 of 10 parts are different to the 10 parts the user now has, so he just needs to download the 3 parts to be able to build the old file again.
So the improved Wuala-system would have to handle more files (that actually are just parts of files) with less size.
So I'm looking forward what you guys are doing in the near future. -
Inappropriate?I always wondered why Wuala wasn't designed this way from the start, because there are similar (research) systems that are using this approach.
Rabin-Fingerprints are used there to create chunks based on the file contents, not at static boundaries. That would have the advantage of, for example, not requiring a re-upload of a file after the insertion of a few bytes at the beginning.
Maybe it would increase the amount of overhead dramatically or there's some other non-obvious problem with the idea. Anyway, I doubt it's feasible to just graft finer-grained chunks onto the current implementation; large parts of Wuala would probably have to be rewritten from scratch.
But, hey, if that's ever done, I'd recommend the following paper to the developers: Optimizing File Replication over Limited-Bandwidth Networks using Remote Differential Compression
;-)
2 people think
this is one of the best points
Loading Profile...




EMPLOYEE