help me understand keepalive..

Steve Sether steve at
Wed May 18 16:23:38 GMT 2005

I don't think it's the blocksize.  I'm still not terribly familiar with
the inner workings of rsync, but from what I see maybe_send_keepalive() is
never sending a keepalive on the sender side.  It looks like the test
in maybe_send_keepalive() is never passed.  Right now that test is:
if (time(NULL) - last_io >= allowed_lull).  But it looks to me like last_io
is reset on the sender side every time it receives a packet (as well as when it
sends a packet).  Furthermore and inserted printf reveals that time(NULL) and 
last_io are always the same on the sender side.  Since the receiver side is 
timing out, I'm assuming that the sender actually hasn't sent anything.

When I remove the test on the sender side, everything transfers like it should.
I understand why the test is their, but shouldn't last_io only be reset when
a packet has been sent, not received?  

Obiously this is a bit of hackery on my part, but shouldn't the test for
sending a keepalive packet be when data was last sent, not either sent or

> It may be that the blocksize on the file you're transferring makes the
> hard-coded lull_mod multiplier too large.  Given a timeout value of 59,
> rsync will check to see if a keep-alive is needed every 150 blocks (and
> it only sends the keep-alive if at least 59/2 seconds have elapsed).
> With large blocks, that may not be often enough.  If you run an strace
> of the sender, you should see every call to time() that rsync makes and
> the value that gets returned -- that will let you calculate how
> frequently the keep-alive checks are happening.  I'm assuming that rsync
> just barely misses sending off a keep-alive packet before the receiver
> times out when you tried the 59-second timeout, and the 58-second
> timeout run got a bit lucky.
> So, it would seem that a better algorithm for calculating the lull_mod
> is needed.  BTW, the latest version of this sender-side keep-alive patch
> is now in the "patches" dir of CVS:
> ..wayne..

More information about the rsync mailing list