Roelof, The core concept (as I see it) is that each node in your simulated network will receive packets as the simulation progresses, and the nodes must do something with each packet they receive.
In OOP, it often helps to think about the objects in terms of "their responsibilities". And by that we mean: "when such-and-such event occurs, or whenever one-or-another situation is active, this object has the responsibility of doing this-or-that". So what about the node objects? The responsibility of a node object is to react appropriately to the event of receiving a packet. There are at least 3 behaviors that each node must employ to meet its responsibilities. Those three are: 1) Forward the packet to one or more other nodes in the network that it's connected to, 2) Accept the packet (if addressed to itself) and "process it", and 3) Drop the packet (because it's been received previously, which means it's already either been forwarded or accepted and processed, so this is a duplicate packet and should no longer be handled). In addition, each node must make the decision which behavior to follow when it receives a packet. It will do this based on information in the packet (its destination address) and the node's own address (so that it can recognize packets that are addressed to itself), and the address of the node that sent the packet (perhaps; for efficiency, you don't want to forward a packet back to the node that just sent it to you -- it already handled the packet and decided it should forward it). For behavior #1, there is more than one way to decide "how" to forward a packet. The "Flood" algorithm is one of many, and is the simplest one. But there are others. Each of these possible forwarding schemes is "a behavior". Blocks in Pharo are behaviors. So I think the "block" that confuses you is "a packet forwarding behavior". When your node decides that the proper way to handle a packet it has received is to forward it (option #1), it must supply two things: The packet to be forwarded, and the forwarding behavior, which will be a block. In this way, your code is more flexible: By changing the block that you provide to the forwarding method, you can change the algorithm that the node uses to decide which link(s) to forward the packet on. And once you have your application finished, and you have more than one forwarding scheme defined, you will be able to run you application, once for each different forwarding scheme, and see how the packets flow through the network -- which will show you (visually) which forwarding schemes are efficient (i.e., minimizing the number of node-to-node transfers) and which are inefficient (i.e., resulting in many node-to-node transfers, most of which are unproductive). You will find that (in general) the easiest forwarding schemes to write code for are also the least efficient schemes. -t -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
