mentor question 1
Locked
mentor question 1
 
|
Hello,
Im doing the OOP book written by Ducassse and im now stuck at the network-simulator. Code so far can be found here : https://github.com/RoelofWobben/Network-simulator Im stuck at 2 places 1) What for datatype is loopback ? Is it a string or something else. The book is not telling that. 2) I have to make this method/function linksTowards: anAddress do: aBlock "Simple flood algorithm: route via all outgoing links. However, just loopback if the receiver node is the routing destination." (address destination == loopback) ifTrue: [self send: via: loopback ]; ifFalse: [self send: via: anAddress] but I do not have a clue what the aBlock is and if im on the right path. I know the solutions can be found online but then I do not learn anything. This is what is stated in the book : This method has to rely on some routing algorithm to identify which links will transmit the packet closer to its destination. Since some routing algorithms select more than one link, we will implement routing as an iteration method, which evaluates the given block for each selected link. KANetworkNode >> send: aPacket "Send aPacket, leaving the responsibility of routing to the node." self linksTowards: aPacket destinationAddress do: [ :link | self send: aPacket via: link ] One of the simplest routing algorithm is flooding: just send the packet via every outgoing link. Obviously, this is a waste of bandwidth, but it works without any knowledge of the network topology beyond the list of outgoing links. However, there is one case where we know how to route the packet: if the destination address matches the one of the current node, we can select the loopback link. The logic of linksTowards:do: is then: compare the packet’s destination address with the one of the node, if it is the same, we execute the block using the loopback link, else we simply iterate on the outgoing links of the receiver. KANetworkNode >> linksTowards: anAddress do: aBlock "Simple flood algorithm: route via all outgoing links. However, just loopback if the receiver node is the routing destination." ... Your code ... I hope someone can help me on the way or let me see which steps I had to take to solve this on my own. Roelof |
|
|
1. 'loopback' is a node, just like 'source' and 'destination'. A network is
a mesh of 'nodes' joined by 'links'. Your Pharo program represents one of those nodes: It is the 'loopback' node. 2. The block in the #linksTowards:do: method is the action to take on a packet, depending on whether its destination is "you" (loopback), or something else. The flood algorithm is the simplest algorithm: "If the destination is not me, send the packet to everyone else (except the one who sent it to me)." However, there is the possibility of loops in the network, so a slightly better algorithm is to check "have I seen this packet before?" and if the answer is "yes", then drop it; otherwise send it via my links. This will prevent endless packet sending loops in your network. -t -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html |
Re: mentor question 1
|
|
Op 25-4-2020 om 20:04 schreef tbrunz:
> 1. 'loopback' is a node, just like 'source' and 'destination'. A network is > a mesh of 'nodes' joined by 'links'. Your Pharo program represents one of > those nodes: It is the 'loopback' node. oke, so I can do : loopback := KNetworkNode new. > 2. The block in the #linksTowards:do: method is the action to take on a > packet, depending on whether its destination is "you" (loopback), or > something else. > > The flood algorithm is the simplest algorithm: "If the destination is not > me, send the packet to everyone else (except the one who sent it to me)." and that part I still do not see. I "fail" to see what the block exactly is. > However, there is the possibility of loops in the network, so a slightly > better algorithm is to check "have I seen this packet before?" and if the > answer is "yes", then drop it; otherwise send it via my links. This will > prevent endless packet sending loops in your network. > > -t > > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > |
Re: mentor question 1
|
|
In reply to this post by tbrunz
Op 25-4-2020 om 20:17 schreef Roelof Wobben:
> Op 25-4-2020 om 20:04 schreef tbrunz: >> 1. 'loopback' is a node, just like 'source' and 'destination'. A >> network is >> a mesh of 'nodes' joined by 'links'. Your Pharo program represents >> one of >> those nodes: It is the 'loopback' node. > > oke, so I can do : loopback := KNetworkNode new. > >> 2. The block in the #linksTowards:do: method is the action to take on a >> packet, depending on whether its destination is "you" (loopback), or >> something else. >> >> The flood algorithm is the simplest algorithm: "If the destination is >> not >> me, send the packet to everyone else (except the one who sent it to >> me)." > > > and that part I still do not see. I "fail" to see what the block > exactly is. > >> However, there is the possibility of loops in the network, so a slightly >> better algorithm is to check "have I seen this packet before?" and if >> the >> answer is "yes", then drop it; otherwise send it via my links. This will >> prevent endless packet sending loops in your network. >> >> -t >> >> >> >> >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >> > Oke, Did some thinking and see how things are working if the loopback is not used : linksTowards: anAddress do: aBlock "Simple flood algorithm: route via all outgoing links. However, just loopback if the receiver node is the routing destination." address = anAddress ifTrue: [ ] ifFalse: [ outgoingLinks do: aBlock ] but still I "fail" to see what need to be done when the loopback is used with the block. Roelof |
Administrator
|
On Sat, Apr 25, 2020, 11:46 Roelof Wobben via Pharo-users <[hidden email]> wrote: Op 25-4-2020 om 20:17 schreef Roelof Wobben: It's not clear to me if a link is an actual object in your model. I'll respond as if it is. aBlock is the work you want done on the destination node. So, the question is how you get it there. You iterate through the outgoingLinks and ask the link to deliver the block to the destination node. In "blasting", each node sends it on through its own outgoingLinks, until it eventually reaches the destination node. The destination node evaluates aBlock, probably supplying itself as an argument to the block. In the case of a loopback, the node itself seems to be the one intended to evaluate aBlock. (I don't know the problem description, so that may not be entirely correct.)
|
|
|
Hi Richard,
I looked the repo; he's defined 3 classes: one for packets, one for nodes, and one for links. So yes, he instantiates links. Likely each node has a collection of links (each of which leads to another node in the network). The application is to simulate a network by modeling it in ST, so that means generating packets, each with a destination node (where nodes have addresses), and simulating how the packets flow through the network to get from their source nodes to their destination nodes. I hadn't though about sending the blocks to the nodes via the packets, but that *is* a cool concept... And entirely do-able in Pharo. However, if the exercise is to make a simple network model that runs to simulate network operation, I doubt that's what they're looking for, though (since it's not what you typically do in a packet network). I think they just want you to model the packet-handling behavior, and that's what the block is for. (I may be wrong.) -Ted -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html |
|
Administrator
|
On Sat, Apr 25, 2020, 15:50 tbrunz <[hidden email]> wrote: Hi Richard, Thanks, Ted. That makes sense. I agree the problem is almost certainly not about sending blocks. Silly of me, really. I didn't see anything in this thread that explained the block. I could imagine that a link object knows how to deliver a packet to the node and the node object knows how to receive the packet. (Or something like that)
|
|
|
In reply to this post by Pharo Smalltalk Users mailing list
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 |
|
|
In reply to this post by Richard Sargent
Richard,
I don't think it was silly. I'm sitting here thinking to myself, "Wow, that's creative... Pharo being Pharo, you can write applications that can send *blocks* between nodes, not just *data*..." The concept of sending behaviors as well as data opens up some interesting and powerful possibilities for applications! (Yet another way ST is superior to other languages.) -Ted -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html |
|
Administrator
|
On Sat, Apr 25, 2020, 16:17 tbrunz <[hidden email]> wrote: Richard, I understand. I meant that in the world this exercise models (separate compute nodes connected by a network), the single god-like Pharo application doesn't exist and sending blocks is harder. (Although, GemStone/S does make it simple, at least if all the nodes are connected to the GemStone/S database.)
Absolutely! It took a long time to *really* internalize the idea of everything is an object. Once I grokked that, it became easy to think that way all the time.
|
|
|
In reply to this post by Pharo Smalltalk Users mailing list
>
but I do not have a clue what the aBlock is
You say the method definition is... > linksTowards: anAddress do: aBlock
and then later indicate its called like this... > linksTowards: aPacket destinationAddress do: [ :link | self send: aPacket via: link ] so in this case aBlock would be "[ :link | self send: aPacket via: link ]" Or was that not your question? Remember that "blocks are objects too". In the same way that curly brackets create an instance of Array... { 1 . 2 . 3 } inspect the square brackets create an instance of BlockClosure, or "block" for short. In Playground, compare evaluating the above inspect with evaluating the following... (i.e. type "inspect" and evaluate the whole thing) [ :x | x + 1 ] inspect then in bottom pane of that inspector,
DoItAndGo
evaluate the following... self value: 5 and you will see the result is 6 because #value: was sent to the block object that you inspected. HTH cheers -ben On Sun, 26 Apr 2020 at 00:48, Roelof Wobben via Pharo-users <[hidden email]> wrote:
|
«
Return to Pharo Smalltalk Users
|
1 view|%1 views
| Free forum by Nabble | Edit this page |