rsync over Iridium modem, 240 bytes per second

[Michael Ashley]

Thanks for you advice Matt.

> From reading the code, it looks like rsync will truncate to the last
> "token", where a token is either a match with a block of the old
> destination file or a chunk of literal data of length up to the sending
> rsync's CHUNK_SIZE constant, by default 32KB.  You could recompile the
> sending rsync with a lower CHUNK_SIZE.

32KB is a couple of minutes at 2400 baud, so this isn't so bad to
lose. I was worried that the chunk might be more like the increment
that rsync seems to write when updating the partial files to disk
during a transfer, which is much larger (256K? 128K?, I forget).

> On such a slow, unreliable link, I doubt you will be able to make rsync
> work very well by just trimming the buffering and making it time out and
> restart.  I would suggest putting some kind of layer on top of the link
> that would allow a set of rsync processes to block when the link goes
> down and simply resume work when it comes back up.

Ok, I'll have a think about that. I had imagined that when the ppp
link went down, that all TCP connections would be severed, and rsync
wouldn't automatically reconnect. It is hard to see this working
with rsync over ssh. But I could imagine a program at either end of
the link providing a socket to rsync, and then handling the
reconnection in the middle. I wonder if 'socat' could do this?

If there are any networking gurus listening, I would appreciate some
pointers!

Michael