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, toad at freenetproject.org 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;
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20080208/ca8e074b/attachment.html>
