On Friday 08 February 2008 16:08, Robert Hailey wrote: > > 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
IMHO not possible because of output bandwidth liability limiting. > 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: The real problem is likely to be a bug in the transport layer. I suggest you revert my change. > > Logger.error(this, "per-packet congestion control delay: "+(end-now)); Do you see this often? > > 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 -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20080208/2e846c09/attachment.pgp>
