Webapp needs a simple speed control knob, especially to avoid saturating bandwidth on uploads.
We have basic throttling support in git-annex for rsync,
but none for any special remotes. A good first step would be to expose
this in the webapp, and ensure that
git-annex-shell also honors it when
We actually need two speed controls, one for upload and one for download.
It is probably not necessary to throttle git push/pull operations, as the data transfers tend to be small. Only throttling file transfers is essential.
git-annex transferkeys is a separate process, one easy option would
be to run it inside
trickle. If the user changes the bandwidth limits,
it could kill the transfer and restart it with different trickle options.
Problem: Not all special remotes support resuming transfers, so this is suboptimal. (So too are the pause/resume buttons, when using those remotes!)
trickle is available for OSX as well as Linux and BSDs.
It is probably not easily available for Android, as it uses
possibility: built in IO limiting
A cleaner method would be to do the limiting inside git-annex. We already have metered file IO. It should be possible to make the meter not only report on the transfer speed, but detect when it's going too fast, and delay. This will delay the file streaming through the special remote's transfer code, so should work for a variety of special remotes. (Not for rsync or bup or git-annex-shell though, so those need to be handled separately.)
Should work well for uploads at least. I don't know how well it would work for throttling downloads; the sender may just keep sending data and the data buffer before it gets to the IO meter. Maybe once the buffers fill the OS would have the TCP throttled down. Needs investigation; trickle claims to throttle downloads.
There would need to be a communication channel for the assistant to tell
git annex transferkeys when the rate limit has changed. It could for
example send it a SIGUSR1, and then leave it up to the process to reload
the git config. Inside the IO meter, we could have an MVar that contains
the current throttle value, so the IO meter could check it each time it's
called and adjust its throttling appropriately.
Ideally, the assistant could also communicate in the same way with
git-annex-shell to tell it when the limit has changed. Since
git-annex-shell uses rsync, it would need to abort the transfer, and rely
on the other side retrying to start it up with the new limit.