I am well aware of the fact that this is a sub-optimal way to simulate a large Freenet. But the thing is, I didn't really do anything, all I did was add support for a local protocol. You said yourself that you wanted it to use as much of the code as possible, and this does so. Basically I see this as more effective way to make sure that a change in the code works as expected then running test5.sh.
It is also a good way to test the performance of the node (I am positively surprised by what I have seen so far - just the fact that it runs with 1000 nodes is pretty impressive IMO). The sort of thing you are describing is what I was referring to as a full simulator, and I don't see a way to integrate that with the current classes. For something like that I see more hope in what Scott wants to do (though I have to admit I don't understand garmora at all). On Tue, 02 May 2000, Ian Clarke wrote: > This is cool, although it is not quite the approach I would have taken. > Just to stir up shit - I will explain what I had in mind. I am not > saying this is nescessarily better than what Oskar has done but it does > appeal more to me as I think it would be a more efficient simulation. > > I would have carved out any notion of passing data around for the sake > of the simulation - opening sockets and moving data around in memory > strikes me as being rather inefficient. I am also guessing that you use > a different thread for each node - again, not quite the approach I would > have adopted. > > In the original Freenet simulation each node was treated as a class > which had a receive() method (which took a message as a parameter), and > could call a send() method in a Network object which again, took a > parameter. > > The network object maintained a stack of messages, when a message was > sent it would be added to the top of this stack. The network object > would simply keep taking messages off the bottom of the stack and call > the receive() method of the destination node with the message. When the > stack was empty, the simulation could be considered complete. > > This could then be extended to simulate different sending times between > nodes by associating each message with a received time (calculated by > the network object when the message is sent) and they are then placed in > the stack of messages just behind whatever message has a received time > before it. This treats each message as being discrete and > instantaenous, however messages could also be split into two events > which are placed in this queue, message start and message complete. > > Ian. > > _______________________________________________ > 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
