On Tue, 11 Apr 2000, hal at finney.org wrote: > I wrote: <snip log> > The problem here and in the other example I gave is that I sent two > InsertReplies for the same message. The first one causes the node I sent > it to to reverse the direction of forwarding, because it thinks the next > message it will receive will be the DataInsert message. Hence when I > send the second InsertReply it forwards it directly back to me, I echo > it back, and we get stuck in a loop.
This is right. > I think we need to change the state when we send an InsertReply back, > not to send any other messages back. Ideally we would also terminate any > efforts we are making to search. (We seem to accept an InsertReply from > a node we have given up on, so we may have gone on to search other nodes.) When I originally wrote the code to send back the InsertReply, I was careful enough to add the extra "dataRef" address to the MessageMemory, so that after sending back an InsertReply, the "origRec" address can be set to null, and no further messages would be sent down the stream (and then they would not be sent back). But when I wrote the code that used the open connection to send instead, I wasn't this careful (or, rather, I was getting more concerned about the sheer number of elements in the MM - but considering an extra pointer is is like 4 kB of memory for 100 elements, maybe that was having the wrong priority). I changed this now, so it uses a "dataCon" which is "replyCon" exactly what "dataRef" is "origRec" (which I guess should be called replyRef - but it predates me). Passing an InsertReply now sets origRec and replyCon to null, so no more messages will be passed back after that now. You might be right that we should increase the statefulness of the MessageMemory so that it knows what messages it is expecting the whole time instead. However, some people are against increased statefulness at all. > I don't understand the current structure well enough to see how to do > this. Which I guess is the unfortunate effect of this part of the code going through a number of iterations of Oskar, and no iterations of "other person who cleans up Oskar's idiosyncrasies" > Hal > > _______________________________________________ > 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
