| … | |
… | |
| 248 | N3--N4--- | |
248 | N3--N4--- | |
| 249 | \________/ |
249 | \________/ |
| 250 | |
250 | |
| 251 | Finished. C<N5> is now happily connected to the rest of the network. |
251 | Finished. C<N5> is now happily connected to the rest of the network. |
| 252 | |
252 | |
|
|
253 | =head3 Setting Up The Profiles |
|
|
254 | |
|
|
255 | Ok, so much to the profile. Now lets setup the C<eg_simple_receiver> I<profile> |
|
|
256 | for later. For the receiver we just give the receiver a I<bind>: |
|
|
257 | |
|
|
258 | aemp profile eg_simple_receiver setbinds localhost:12266 |
|
|
259 | |
|
|
260 | And while we are at it, just setup the I<profile> for the sender in the second |
|
|
261 | part of this example too. We will call the sender I<profile> |
|
|
262 | C<eg_simple_sender>. For the sender we will just setup a I<seed> to the |
|
|
263 | receiver: |
|
|
264 | |
|
|
265 | aemp profile eg_simple_sender setseeds localhost:12266 |
|
|
266 | |
|
|
267 | You might wonder why we don't setup a I<bind> here. Well, there can be |
|
|
268 | exceptions to the I<fully> in the I<fully connected mesh> in L<AnyEvent::MP>. |
|
|
269 | If you don't configure a I<bind> for a node's profile it won't bind itself |
|
|
270 | somewhere. These kinds of I<nodes> will not be able to send messages to other |
|
|
271 | I<nodes> that also didn't I<bind> them self to some TCP address. For this |
|
|
272 | example, as well as some cases in the real world, we can live with this |
|
|
273 | limitation. |
|
|
274 | |
|
|
275 | =head3 Registering The Receiver |
|
|
276 | |
|
|
277 | Ok, where were we. We now discussed the basic purpose of L<AnyEvent::MP::Global> |
|
|
278 | and initialise_node with it's relations to profiles. We also setup our profiles |
|
|
279 | for later use and now have to continue talking about the receiver example. |
|
|
280 | |
|
|
281 | Lets look at the next undiscussed line(s) of code: |
|
|
282 | |
|
|
283 | my $port = port; |
|
|
284 | AnyEvent::MP::Global::register $port, "eg_receivers"; |
|
|
285 | |
|
|
286 | The C<port> function already has been discussed. It just creates a new I<port> |
|
|
287 | and gives us the I<port id>. Now to the C<register> function of |
|
|
288 | L<AnyEvent::MP::Global>: The first argument is a I<port id> that we want to add |
|
|
289 | to a I<global group>, and it's second argument is the name of that I<global |
|
|
290 | group>. |
|
|
291 | |
|
|
292 | You can choose that name of such a I<global group> freely, and it's purpose is |
|
|
293 | to store a set of I<port ids>. That set is made available throughout the whole |
|
|
294 | L<AnyEvent::MP> network, so that each node can see which ports belong to that |
|
|
295 | group. |
|
|
296 | |
|
|
297 | The sender will later look for the ports in that I<global group> and send |
|
|
298 | messages to them. |
|
|
299 | |
|
|
300 | Last step in the example is to setup a receiver callback for those messages |
|
|
301 | like we have discussed in the first example. We again match for the I<tag> |
|
|
302 | C<test>. The difference is just that we don't end the application after |
|
|
303 | receiving the first message. We just infinitely continue to look out for new |
|
|
304 | messages. |
|
|
305 | |
| 253 | =head1 The Chat Client |
306 | =head1 The Chat Client |
| 254 | |
307 | |
| 255 | OK, lets start by implementing the "frontend" of the client. We will |
308 | OK, lets start by implementing the "frontend" of the client. We will |
| 256 | develop the client first and postpone the server for later, as the most |
309 | develop the client first and postpone the server for later, as the most |
| 257 | complex things actually happen in the client. |
310 | complex things actually happen in the client. |
