On Jan 25, 2008, at 5:35 AM, Matthew Toseland wrote: >> I've noticed these too. Since they appear to be the result of nodes >> originating requests w/o starting the transfer, and thus the receiver >> timing out and asking for all packets... I *think* that they are >> fixed >> by (r17216). So yes... if they don't cease feel free to mute them. > > I don't think so. I'm still getting them. Admittedly 1103 is only just > mandatory, some nodes may not have been disconnected yet. But after > the > errors, I eventually get a successful transfer (allReceived). > > Okay, there are *two* calls to createMissingPacketNotification: > > The first is if we get a packetTransmit and it indicates that > packets we > haven't received have actually been sent. So we need to ask it to > resend > them. > > The second is if we get a timeout, and there are still packets we > haven't > received. This is harmless, it may increase reliability marginally > if there > are problems with the transport layer, it wastes a few bytes if the > transport > layer is perfect (which it should be!).
Timeout or allSent, but yes. > Should I take it out? IMHO the logic should stay should stay. The timeout there is 30 seconds, and is not triggered while we are receiving any relevant packets from the transmitter. If you were getting these not received messages many-in-series, it was probably from a timeout. If it was *only* #31 (the last one) it was probably from the allSent message being reordered before the last packet. > I've silenced the logging anyway. r17258... looks fine to me. -- Robert Hailey -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20080125/7e769527/attachment.html>
