> 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
