The problem is not that it couldn't be fixed, the reason it happened at all was because I introduced a dumb bug in the code, because dropped messages were not being dropped correctly, etc etc. So yeah, one can just point the finger at whoever introduced the bug that caused the loop, but the system will never be without bugs, and the implementations won't always be under our control.
By having a HTL on every message, you have a simple but powerful layer of protection against problems like this built into the protocol and spec itself, rather then relying on programmers always getting things right and considering all possibilities. On Thu, 13 Apr 2000, Brandon wrote: > > I think the problem is if C has a bug and passes the message to D rather > > than B. Then D may pass it back to C, C to D, D to C, and so on forever. > > > > We saw exactly this bug yesterday. Because we had HTL this did not go > > on forever but counted down to zero. If we hadn't had HTL for return > > messages it would never have stopped. > > I have simple fix for this that doesn't require Depth. Just detect > loopbacks of Replies. > > So, when a reply is received, then > > 1. It's UniqueID is unknown, so drop it. > 2. The UniqueID is known and this is the first time the Reply has been > received. Send it on. > 3. The UniqueID is known and the reply has already been received, so drop > it. > > We only allow one reply from a request out of the set of TimedOut and > RequestFailed, so it is easy to detect repetition, just put a boolean in > the message memory. > > However, we allow any number of QueryRestarteds before the final > reply. This can be dealt with by giving QueryRestarted a secondary > UniqueID to uniquely identify it from other QueryRestarted messages and > then testing for loopback the way we currently test for loopback. > > Or we could just change replies so they all have a new uniqueid and put > the uniqueid of the request in OriginalID or somesuch. Then we could use > normal loopback detection for requests on replies. The code change would > be minimal, and I think it would be a pretty elegant solution, and we > wouldn't need depth. > > > > _______________________________________________ > Freenet-dev mailing list > Freenet-dev at lists.sourceforge.net > http://lists.sourceforge.net/mailman/listinfo/freenet-dev -- Oskar Sandberg md98-osa at nada.kth.se #!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj $/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1 lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/) _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
