Ip-rsync requires more detailed experiments in order to quantify tradeoffs between compression and parallelism and to identify further opportunities for optimization. Rsync itself is highly optimized for parallel execution within a single file and between multiple files [19]. Rsync is widely used because it works so well. We intend to follow this example. Although we have identified unfinished work items (in windowing and error recovery), the most important future work will feed experimental results back into the design of ip-rsync.
Even though we designed ip-rsync for mobile and wireless devices, our experiments reveal that ip-rsync works well in higher-bandwidth networks as well. They show that for bandwidths greater than 20,000 KB/sec, ip-rsync actually outperforms rsync. This result implies that ip-rsync would perform well for synchronizing block devices. In-place reconstruction is necessary because block devices are large (much larger than memory) and there is not spare capacity to write a temporary copy of a whole block device. Experiments need to be conducted to validate these claims.
Reduced concurrency within a single file degrades performance in ip-rsync. In our current experiments, much of this loss is regained through the semi-parallel transfer of multiple files; sending the data of a file while scanning for matching data in another file. However, rsync is commonly used to synchronize single files. More detailed experiments that examine performance when transferring single files will isolate performance losses from reduced parallelism. and indicate ip-rsync's suitability for single file transfer. Such experiments are essential to understand the benefit of reduced I/O in ip-rsync. When combined with semi-parallel execution, the gains of reducing I/O can make ip-rsync outperform rsync. Experiments on single files would allow us to measure the relative value of reduced I/O when compared with semi-parallel transfer.