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
_______________________________________________
Devl mailing list
[email protected]
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
