I think that this (or more specifically r17687) is a little confused.
You see, the consecutive missing reports is reset to zero every time
that we receive a new packet; it is effectively the number of timeouts
we can incur before we give up (and the timeout is 30 seconds). So...
as long as the transmitter is transmitting, it is irrelevant; but
after r17687, the receiver will hang around for four minutes waiting
for packets.
I suggest that the bug you are chasing is more related to the
transmitter (and possibly crazy-slow nodes/high ping time); as the
problem is surely way too many concurrent transfers and not lack of
timeout grace. Possibly (1) high-pingtime/throttling problem, (2) ULPR
transfers somehow not being accounted for, etc. See the error
statement on BlockTransmitter(~#149), which could be tightened up
(right now at two minutes), or simply made to abort the transfer:
Logger.error(this, "per-packet congestion control delay: "+(end-now));
The change may be acceptably benign, but I don't think that it is
beneficial; it either keep threads hanging around or just let crazy-
slow transfers pile up.
--
Robert Hailey
On Feb 7, 2008, at 5:35 PM, [EMAIL PROTECTED] wrote:
Author: toad
Date: 2008-02-07 23:35:40 +0000 (Thu, 07 Feb 2008)
New Revision: 17688
Modified:
trunk/freenet/src/freenet/io/xfer/BlockReceiver.java
Log:
explain a bit in comments
Modified: trunk/freenet/src/freenet/io/xfer/BlockReceiver.java
===================================================================
--- trunk/freenet/src/freenet/io/xfer/BlockReceiver.java 2008-02-07
23:32:33 UTC (rev 17687)
+++ trunk/freenet/src/freenet/io/xfer/BlockReceiver.java 2008-02-07
23:35:40 UTC (rev 17688)
@@ -43,6 +43,13 @@
public static final int RECEIPT_TIMEOUT = 30000;
// TODO: This should be proportional to the calculated round-trip-
time, not a constant
public static final int MAX_ROUND_TRIP_TIME = RECEIPT_TIMEOUT;
+ /*
+ * FIXME: Is this a good idea?
+ * RECEIPT_TIMEOUT must be less than 60 seconds because
BlockTransmitter times out after not
+ * hearing from us in 60 seconds. I increased
MAX_CONSECUTIVE_PACKET_REPORTS to 8 to avoid
+ * some timeouts, and on the theory that even though the request
handler will have already
+ * timed out, we can still offer it after we've got the data
completely.
+ */
public static final int MAX_CONSECUTIVE_MISSING_PACKET_REPORTS = 8;
public static final int MAX_SEND_INTERVAL = 500;
public static final int CLEANUP_TIMEOUT = 5000;
_______________________________________________
Devl mailing list
[email protected]
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
