[Bug 2654] timeout is always triggered with 2.6.4

[samba-bugs at samba.org]

https://bugzilla.samba.org/show_bug.cgi?id=2654





------- Additional Comments From f+samba at congenio.de  2005-04-27 09:26 -------
(In reply to comment #4)

About --fuzzy: I doubt that this was the case. There are only up to 50 files in
each directory (and from what I understood, the fuzzy matching takes place only
in the file's own directory). Also, there was ongoing socket activity a few
seconds before the actual timeout occured. I saw that last_io was modified every
second or so in read_timeout() while the received file got bigger. Then at some
point, the check_timeout failed with an older last_io time. That timestamp
matched that of the last modification in write_unbuffered().

> 
> As for who counts what, the generator only sends data down the socket, so it
> only notes that data in the last_io time.  The receiver only reads data from the
> socket, so it only notes that data in the last_io time.  The sender both reads
> and writes data from/to the socket, so it notes both.

Yes. The sender was an rsync daemon in my case, whereas the client was separated
into a generator and a receiver. Could that lead to a problem when only binary
data (i.e. no deltas) are being sent (or the opposite, where just copying on the
receiving side was neccessary)? Is there a possibility that the receiver is busy
(modifying its last_io all the time) but the generator sits and waits for the
next file to get processed or a select() timeout occurs and then the generator
runs into the timeout in check_timeout() because the last time that
write_unbuffered() modified its last_io was too long ago?

This would mean that effectively, --timeout ought to large enough to accommodate
not only pauses arising from directory scans, checksum calculations or fuzzy
matching, but even data transfer itself if no (or maybe only) deltas are
present. So, --timeout must in fact be longer than the expected transfer time of
the largest file over a given connection in the worst case.

I would expect --timeout to be a kind of "inactivity" counter to recognize
stalled IP connections. But it seems that by separating the generator and
receiver, there can be LONG pauses in one direction which trigger the timeout,
although the connection is alive and well in the other direction (but that fact
goes unnoticed).

I guess in order to enable such bahaviour, the condition "io_timeout && fd ==
sock_f_in" respectively "io_timeout && fd == sock_f_out" should read something
like "io_timeout && (fd == sock_f_in || fd == sock_f_out)" in order to catch
"ACK" packets? If the receiver and generator see only one direction of the same
socket, however, only a kind of shared-memory variable "last_io" could do that
trick.


-- 
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.