ViewVC Help
View File | Revision Log | Show Annotations | Download File
/cvs/AnyEvent-MP/MP.pm
(Generate patch)

Comparing AnyEvent-MP/MP.pm (file contents):
Revision 1.97 by root, Fri Oct 2 13:29:49 2009 UTC vs.
Revision 1.156 by root, Sat Oct 23 03:35:49 2021 UTC

30 rcv $port, pong => sub { warn "pong received\n" }; 30 rcv $port, pong => sub { warn "pong received\n" };
31 31
32 # create a port on another node 32 # create a port on another node
33 my $port = spawn $node, $initfunc, @initdata; 33 my $port = spawn $node, $initfunc, @initdata;
34 34
35 # destroy a port again
36 kil $port; # "normal" kill
37 kil $port, my_error => "everything is broken"; # error kill
38
35 # monitoring 39 # monitoring
36 mon $localport, $cb->(@msg) # callback is invoked on death 40 mon $port, $cb->(@msg) # callback is invoked on death
37 mon $localport, $otherport # kill otherport on abnormal death 41 mon $port, $localport # kill localport on abnormal death
38 mon $localport, $otherport, @msg # send message on death 42 mon $port, $localport, @msg # send message on death
39 43
40=head1 CURRENT STATUS 44 # temporarily execute code in port context
45 peval $port, sub { die "kill the port!" };
41 46
42 bin/aemp - stable. 47 # execute callbacks in $SELF port context
43 AnyEvent::MP - stable API, should work. 48 my $timer = AE::timer 1, 0, psub {
44 AnyEvent::MP::Intro - explains most concepts. 49 die "kill the port, delayed";
45 AnyEvent::MP::Kernel - mostly stable API. 50 };
46 AnyEvent::MP::Global - stable API. 51
52 # distributed database - modification
53 db_set $family => $subkey [=> $value] # add a subkey
54 db_del $family => $subkey... # delete one or more subkeys
55 db_reg $family => $port [=> $value] # register a port
56
57 # distributed database - queries
58 db_family $family => $cb->(\%familyhash)
59 db_keys $family => $cb->(\@keys)
60 db_values $family => $cb->(\@values)
61
62 # distributed database - monitoring a family
63 db_mon $family => $cb->(\%familyhash, \@added, \@changed, \@deleted)
47 64
48=head1 DESCRIPTION 65=head1 DESCRIPTION
49 66
50This module (-family) implements a simple message passing framework. 67This module (-family) implements a simple message passing framework.
51 68
59 76
60=over 4 77=over 4
61 78
62=item port 79=item port
63 80
64Not to be confused with a TCP port, a "port" is something you can send 81Not to be confused with TCP ports, a "port" is something you can send
65messages to (with the C<snd> function). 82messages to (with the C<snd> function).
66 83
67Ports allow you to register C<rcv> handlers that can match all or just 84Ports allow you to register C<rcv> handlers that can match all or just
68some messages. Messages send to ports will not be queued, regardless of 85some messages. Messages send to ports will not be queued, regardless of
69anything was listening for them or not. 86whether anything was listening for them or not.
87
88Ports are represented by (printable) strings called "port IDs".
70 89
71=item port ID - C<nodeid#portname> 90=item port ID - C<nodeid#portname>
72 91
73A port ID is the concatenation of a node ID, a hash-mark (C<#>) as 92A port ID is the concatenation of a node ID, a hash-mark (C<#>)
74separator, and a port name (a printable string of unspecified format). 93as separator, and a port name (a printable string of unspecified
94format created by AnyEvent::MP).
75 95
76=item node 96=item node
77 97
78A node is a single process containing at least one port - the node port, 98A node is a single process containing at least one port - the node port,
79which enables nodes to manage each other remotely, and to create new 99which enables nodes to manage each other remotely, and to create new
80ports. 100ports.
81 101
82Nodes are either public (have one or more listening ports) or private 102Nodes are either public (have one or more listening ports) or private
83(no listening ports). Private nodes cannot talk to other private nodes 103(no listening ports). Private nodes cannot talk to other private nodes
84currently. 104currently, but all nodes can talk to public nodes.
85 105
106Nodes is represented by (printable) strings called "node IDs".
107
86=item node ID - C<[A-Z_][a-zA-Z0-9_\-.:]*> 108=item node ID - C<[A-Za-z0-9_\-.:]*>
87 109
88A node ID is a string that uniquely identifies the node within a 110A node ID is a string that uniquely identifies the node within a
89network. Depending on the configuration used, node IDs can look like a 111network. Depending on the configuration used, node IDs can look like a
90hostname, a hostname and a port, or a random string. AnyEvent::MP itself 112hostname, a hostname and a port, or a random string. AnyEvent::MP itself
91doesn't interpret node IDs in any way. 113doesn't interpret node IDs in any way except to uniquely identify a node.
92 114
93=item binds - C<ip:port> 115=item binds - C<ip:port>
94 116
95Nodes can only talk to each other by creating some kind of connection to 117Nodes can only talk to each other by creating some kind of connection to
96each other. To do this, nodes should listen on one or more local transport 118each other. To do this, nodes should listen on one or more local transport
119endpoints - binds.
120
97endpoints - binds. Currently, only standard C<ip:port> specifications can 121Currently, only standard C<ip:port> specifications can be used, which
98be used, which specify TCP ports to listen on. 122specify TCP ports to listen on. So a bind is basically just a tcp socket
123in listening mode that accepts connections from other nodes.
99 124
100=item seed nodes 125=item seed nodes
101 126
102When a node starts, it knows nothing about the network. To teach the node 127When a node starts, it knows nothing about the network it is in - it
103about the network it first has to contact some other node within the 128needs to connect to at least one other node that is already in the
104network. This node is called a seed. 129network. These other nodes are called "seed nodes".
105 130
106Apart from the fact that other nodes know them as seed nodes and they have 131Seed nodes themselves are not special - they are seed nodes only because
107to have fixed listening addresses, seed nodes are perfectly normal nodes - 132some other node I<uses> them as such, but any node can be used as seed
108any node can function as a seed node for others. 133node for other nodes, and eahc node can use a different set of seed nodes.
109 134
110In addition to discovering the network, seed nodes are also used to 135In addition to discovering the network, seed nodes are also used to
111maintain the network and to connect nodes that otherwise would have 136maintain the network - all nodes using the same seed node are part of the
112trouble connecting. They form the backbone of an AnyEvent::MP network. 137same network. If a network is split into multiple subnets because e.g. the
138network link between the parts goes down, then using the same seed nodes
139for all nodes ensures that eventually the subnets get merged again.
113 140
114Seed nodes are expected to be long-running, and at least one seed node 141Seed nodes are expected to be long-running, and at least one seed node
115should always be available. They should also be relatively responsive - a 142should always be available. They should also be relatively responsive - a
116seed node that blocks for long periods will slow down everybody else. 143seed node that blocks for long periods will slow down everybody else.
117 144
145For small networks, it's best if every node uses the same set of seed
146nodes. For large networks, it can be useful to specify "regional" seed
147nodes for most nodes in an area, and use all seed nodes as seed nodes for
148each other. What's important is that all seed nodes connections form a
149complete graph, so that the network cannot split into separate subnets
150forever.
151
152Seed nodes are represented by seed IDs.
153
118=item seeds - C<host:port> 154=item seed IDs - C<host:port>
119 155
120Seeds are transport endpoint(s) (usually a hostname/IP address and a 156Seed IDs are transport endpoint(s) (usually a hostname/IP address and a
121TCP port) of nodes that should be used as seed nodes. 157TCP port) of nodes that should be used as seed nodes.
122 158
123The nodes listening on those endpoints are expected to be long-running, 159=item global nodes
124and at least one of those should always be available. When nodes run out 160
125of connections (e.g. due to a network error), they try to re-establish 161An AEMP network needs a discovery service - nodes need to know how to
126connections to some seednodes again to join the network. 162connect to other nodes they only know by name. In addition, AEMP offers a
163distributed "group database", which maps group names to a list of strings
164- for example, to register worker ports.
165
166A network needs at least one global node to work, and allows every node to
167be a global node.
168
169Any node that loads the L<AnyEvent::MP::Global> module becomes a global
170node and tries to keep connections to all other nodes. So while it can
171make sense to make every node "global" in small networks, it usually makes
172sense to only make seed nodes into global nodes in large networks (nodes
173keep connections to seed nodes and global nodes, so making them the same
174reduces overhead).
127 175
128=back 176=back
129 177
130=head1 VARIABLES/FUNCTIONS 178=head1 VARIABLES/FUNCTIONS
131 179
133 181
134=cut 182=cut
135 183
136package AnyEvent::MP; 184package AnyEvent::MP;
137 185
186use AnyEvent::MP::Config ();
138use AnyEvent::MP::Kernel; 187use AnyEvent::MP::Kernel;
188use AnyEvent::MP::Kernel qw(
189 %NODE %PORT %PORT_DATA $UNIQ $RUNIQ $ID
190 add_node load_func
191
192 NODE $NODE
193 configure
194 node_of port_is_local
195 snd kil
196 db_set db_del
197 db_mon db_family db_keys db_values
198);
139 199
140use common::sense; 200use common::sense;
141 201
142use Carp (); 202use Carp ();
143 203
144use AE (); 204use AnyEvent ();
205use Guard ();
145 206
146use base "Exporter"; 207use base "Exporter";
147 208
148our $VERSION = 1.2; 209our $VERSION = '2.02'; # also in MP/Config.pm
149 210
150our @EXPORT = qw( 211our @EXPORT = qw(
151 NODE $NODE *SELF node_of after
152 configure 212 configure
213
214 NODE $NODE
215 *SELF
216
217 node_of port_is_local
218
219 snd kil
153 snd rcv mon mon_guard kil psub spawn cal 220 port rcv mon mon_guard psub peval spawn cal
154 port 221 db_set db_del db_reg
222 db_mon db_family db_keys db_values
223
224 after
155); 225);
156 226
157our $SELF; 227our $SELF;
158 228
159sub _self_die() { 229sub _self_die() {
170 240
171=item $nodeid = node_of $port 241=item $nodeid = node_of $port
172 242
173Extracts and returns the node ID from a port ID or a node ID. 243Extracts and returns the node ID from a port ID or a node ID.
174 244
245=item $is_local = port_is_local $port
246
247Returns true iff the port is a local port.
248
175=item configure $profile, key => value... 249=item configure $profile, key => value...
176 250
177=item configure key => value... 251=item configure key => value...
178 252
179Before a node can talk to other nodes on the network (i.e. enter 253Before a node can talk to other nodes on the network (i.e. enter
181to know is its own name, and optionally it should know the addresses of 255to know is its own name, and optionally it should know the addresses of
182some other nodes in the network to discover other nodes. 256some other nodes in the network to discover other nodes.
183 257
184This function configures a node - it must be called exactly once (or 258This function configures a node - it must be called exactly once (or
185never) before calling other AnyEvent::MP functions. 259never) before calling other AnyEvent::MP functions.
260
261The key/value pairs are basically the same ones as documented for the
262F<aemp> command line utility (sans the set/del prefix), with these additions:
263
264=over 4
265
266=item norc => $boolean (default false)
267
268If true, then the rc file (e.g. F<~/.perl-anyevent-mp>) will I<not>
269be consulted - all configuration options must be specified in the
270C<configure> call.
271
272=item force => $boolean (default false)
273
274IF true, then the values specified in the C<configure> will take
275precedence over any values configured via the rc file. The default is for
276the rc file to override any options specified in the program.
277
278=back
186 279
187=over 4 280=over 4
188 281
189=item step 1, gathering configuration from profiles 282=item step 1, gathering configuration from profiles
190 283
204That means that the values specified in the profile have highest priority 297That means that the values specified in the profile have highest priority
205and the values specified directly via C<configure> have lowest priority, 298and the values specified directly via C<configure> have lowest priority,
206and can only be used to specify defaults. 299and can only be used to specify defaults.
207 300
208If the profile specifies a node ID, then this will become the node ID of 301If the profile specifies a node ID, then this will become the node ID of
209this process. If not, then the profile name will be used as node ID. The 302this process. If not, then the profile name will be used as node ID, with
210special node ID of C<anon/> will be replaced by a random node ID. 303a unique randoms tring (C</%u>) appended.
304
305The node ID can contain some C<%> sequences that are expanded: C<%n>
306is expanded to the local nodename, C<%u> is replaced by a random
307string to make the node unique. For example, the F<aemp> commandline
308utility uses C<aemp/%n/%u> as nodename, which might expand to
309C<aemp/cerebro/ZQDGSIkRhEZQDGSIkRhE>.
211 310
212=item step 2, bind listener sockets 311=item step 2, bind listener sockets
213 312
214The next step is to look up the binds in the profile, followed by binding 313The next step is to look up the binds in the profile, followed by binding
215aemp protocol listeners on all binds specified (it is possible and valid 314aemp protocol listeners on all binds specified (it is possible and valid
216to have no binds, meaning that the node cannot be contacted form the 315to have no binds, meaning that the node cannot be contacted from the
217outside. This means the node cannot talk to other nodes that also have no 316outside. This means the node cannot talk to other nodes that also have no
218binds, but it can still talk to all "normal" nodes). 317binds, but it can still talk to all "normal" nodes).
219 318
220If the profile does not specify a binds list, then a default of C<*> is 319If the profile does not specify a binds list, then a default of C<*> is
221used, meaning the node will bind on a dynamically-assigned port on every 320used, meaning the node will bind on a dynamically-assigned port on every
222local IP address it finds. 321local IP address it finds.
223 322
224=item step 3, connect to seed nodes 323=item step 3, connect to seed nodes
225 324
226As the last step, the seeds list from the profile is passed to the 325As the last step, the seed ID list from the profile is passed to the
227L<AnyEvent::MP::Global> module, which will then use it to keep 326L<AnyEvent::MP::Global> module, which will then use it to keep
228connectivity with at least one node at any point in time. 327connectivity with at least one node at any point in time.
229 328
230=back 329=back
231 330
232Example: become a distributed node using the local node name as profile. 331Example: become a distributed node using the local node name as profile.
233This should be the most common form of invocation for "daemon"-type nodes. 332This should be the most common form of invocation for "daemon"-type nodes.
234 333
235 configure 334 configure
236 335
237Example: become an anonymous node. This form is often used for commandline 336Example: become a semi-anonymous node. This form is often used for
238clients. 337commandline clients.
239 338
240 configure nodeid => "anon/"; 339 configure nodeid => "myscript/%n/%u";
241 340
242Example: configure a node using a profile called seed, which si suitable 341Example: configure a node using a profile called seed, which is suitable
243for a seed node as it binds on all local addresses on a fixed port (4040, 342for a seed node as it binds on all local addresses on a fixed port (4040,
244customary for aemp). 343customary for aemp).
245 344
246 # use the aemp commandline utility 345 # use the aemp commandline utility
247 # aemp profile seed nodeid anon/ binds '*:4040' 346 # aemp profile seed binds '*:4040'
248 347
249 # then use it 348 # then use it
250 configure profile => "seed"; 349 configure profile => "seed";
251 350
252 # or simply use aemp from the shell again: 351 # or simply use aemp from the shell again:
317 416
318=cut 417=cut
319 418
320sub rcv($@); 419sub rcv($@);
321 420
322sub _kilme { 421my $KILME = sub {
323 die "received message on port without callback"; 422 (my $tag = substr $_[0], 0, 30) =~ s/([^\x20-\x7e])/./g;
324} 423 kil $SELF, unhandled_message => "no callback found for message '$tag'";
424};
325 425
326sub port(;&) { 426sub port(;&) {
327 my $id = "$UNIQ." . $ID++; 427 my $id = $UNIQ . ++$ID;
328 my $port = "$NODE#$id"; 428 my $port = "$NODE#$id";
329 429
330 rcv $port, shift || \&_kilme; 430 rcv $port, shift || $KILME;
331 431
332 $port 432 $port
333} 433}
334 434
335=item rcv $local_port, $callback->(@msg) 435=item rcv $local_port, $callback->(@msg)
340 440
341The global C<$SELF> (exported by this module) contains C<$port> while 441The global C<$SELF> (exported by this module) contains C<$port> while
342executing the callback. Runtime errors during callback execution will 442executing the callback. Runtime errors during callback execution will
343result in the port being C<kil>ed. 443result in the port being C<kil>ed.
344 444
345The default callback received all messages not matched by a more specific 445The default callback receives all messages not matched by a more specific
346C<tag> match. 446C<tag> match.
347 447
348=item rcv $local_port, tag => $callback->(@msg_without_tag), ... 448=item rcv $local_port, tag => $callback->(@msg_without_tag), ...
349 449
350Register (or replace) callbacks to be called on messages starting with the 450Register (or replace) callbacks to be called on messages starting with the
371 msg1 => sub { ... }, 471 msg1 => sub { ... },
372 ... 472 ...
373 ; 473 ;
374 474
375Example: temporarily register a rcv callback for a tag matching some port 475Example: temporarily register a rcv callback for a tag matching some port
376(e.g. for a rpc reply) and unregister it after a message was received. 476(e.g. for an rpc reply) and unregister it after a message was received.
377 477
378 rcv $port, $otherport => sub { 478 rcv $port, $otherport => sub {
379 my @reply = @_; 479 my @reply = @_;
380 480
381 rcv $SELF, $otherport; 481 rcv $SELF, $otherport;
385 485
386sub rcv($@) { 486sub rcv($@) {
387 my $port = shift; 487 my $port = shift;
388 my ($nodeid, $portid) = split /#/, $port, 2; 488 my ($nodeid, $portid) = split /#/, $port, 2;
389 489
390 $NODE{$nodeid} == $NODE{""} 490 $nodeid eq $NODE
391 or Carp::croak "$port: rcv can only be called on local ports, caught"; 491 or Carp::croak "$port: rcv can only be called on local ports, caught";
392 492
393 while (@_) { 493 while (@_) {
394 if (ref $_[0]) { 494 if (ref $_[0]) {
395 if (my $self = $PORT_DATA{$portid}) { 495 if (my $self = $PORT_DATA{$portid}) {
396 "AnyEvent::MP::Port" eq ref $self 496 "AnyEvent::MP::Port" eq ref $self
397 or Carp::croak "$port: rcv can only be called on message matching ports, caught"; 497 or Carp::croak "$port: rcv can only be called on message matching ports, caught";
398 498
399 $self->[2] = shift; 499 $self->[0] = shift;
400 } else { 500 } else {
401 my $cb = shift; 501 my $cb = shift;
402 $PORT{$portid} = sub { 502 $PORT{$portid} = sub {
403 local $SELF = $port; 503 local $SELF = $port;
404 eval { &$cb }; _self_die if $@; 504 eval { &$cb }; _self_die if $@;
405 }; 505 };
406 } 506 }
407 } elsif (defined $_[0]) { 507 } elsif (defined $_[0]) {
408 my $self = $PORT_DATA{$portid} ||= do { 508 my $self = $PORT_DATA{$portid} ||= do {
409 my $self = bless [$PORT{$port} || sub { }, { }, $port], "AnyEvent::MP::Port"; 509 my $self = bless [$PORT{$portid} || sub { }, { }, $port], "AnyEvent::MP::Port";
410 510
411 $PORT{$portid} = sub { 511 $PORT{$portid} = sub {
412 local $SELF = $port; 512 local $SELF = $port;
413 513
414 if (my $cb = $self->[1]{$_[0]}) { 514 if (my $cb = $self->[1]{$_[0]}) {
436 } 536 }
437 537
438 $port 538 $port
439} 539}
440 540
541=item peval $port, $coderef[, @args]
542
543Evaluates the given C<$codref> within the context of C<$port>, that is,
544when the code throws an exception the C<$port> will be killed.
545
546Any remaining args will be passed to the callback. Any return values will
547be returned to the caller.
548
549This is useful when you temporarily want to execute code in the context of
550a port.
551
552Example: create a port and run some initialisation code in it's context.
553
554 my $port = port { ... };
555
556 peval $port, sub {
557 init
558 or die "unable to init";
559 };
560
561=cut
562
563sub peval($$) {
564 local $SELF = shift;
565 my $cb = shift;
566
567 if (wantarray) {
568 my @res = eval { &$cb };
569 _self_die if $@;
570 @res
571 } else {
572 my $res = eval { &$cb };
573 _self_die if $@;
574 $res
575 }
576}
577
441=item $closure = psub { BLOCK } 578=item $closure = psub { BLOCK }
442 579
443Remembers C<$SELF> and creates a closure out of the BLOCK. When the 580Remembers C<$SELF> and creates a closure out of the BLOCK. When the
444closure is executed, sets up the environment in the same way as in C<rcv> 581closure is executed, sets up the environment in the same way as in C<rcv>
445callbacks, i.e. runtime errors will cause the port to get C<kil>ed. 582callbacks, i.e. runtime errors will cause the port to get C<kil>ed.
583
584The effect is basically as if it returned C<< sub { peval $SELF, sub {
585BLOCK }, @_ } >>.
446 586
447This is useful when you register callbacks from C<rcv> callbacks: 587This is useful when you register callbacks from C<rcv> callbacks:
448 588
449 rcv delayed_reply => sub { 589 rcv delayed_reply => sub {
450 my ($delay, @reply) = @_; 590 my ($delay, @reply) = @_;
474 $res 614 $res
475 } 615 }
476 } 616 }
477} 617}
478 618
619=item $guard = mon $port, $rcvport # kill $rcvport when $port dies
620
621=item $guard = mon $port # kill $SELF when $port dies
622
479=item $guard = mon $port, $cb->(@reason) # call $cb when $port dies 623=item $guard = mon $port, $cb->(@reason) # call $cb when $port dies
480
481=item $guard = mon $port, $rcvport # kill $rcvport when $port dies
482
483=item $guard = mon $port # kill $SELF when $port dies
484 624
485=item $guard = mon $port, $rcvport, @msg # send a message when $port dies 625=item $guard = mon $port, $rcvport, @msg # send a message when $port dies
486 626
487Monitor the given port and do something when the port is killed or 627Monitor the given port and do something when the port is killed or
488messages to it were lost, and optionally return a guard that can be used 628messages to it were lost, and optionally return a guard that can be used
489to stop monitoring again. 629to stop monitoring again.
490 630
631The first two forms distinguish between "normal" and "abnormal" kil's:
632
633In the first form (another port given), if the C<$port> is C<kil>'ed with
634a non-empty reason, the other port (C<$rcvport>) will be kil'ed with the
635same reason. That is, on "normal" kil's nothing happens, while under all
636other conditions, the other port is killed with the same reason.
637
638The second form (kill self) is the same as the first form, except that
639C<$rvport> defaults to C<$SELF>.
640
641The remaining forms don't distinguish between "normal" and "abnormal" kil's
642- it's up to the callback or receiver to check whether the C<@reason> is
643empty and act accordingly.
644
491In the first form (callback), the callback is simply called with any 645In the third form (callback), the callback is simply called with any
492number of C<@reason> elements (no @reason means that the port was deleted 646number of C<@reason> elements (empty @reason means that the port was deleted
493"normally"). Note also that I<< the callback B<must> never die >>, so use 647"normally"). Note also that I<< the callback B<must> never die >>, so use
494C<eval> if unsure. 648C<eval> if unsure.
495 649
496In the second form (another port given), the other port (C<$rcvport>)
497will be C<kil>'ed with C<@reason>, if a @reason was specified, i.e. on
498"normal" kils nothing happens, while under all other conditions, the other
499port is killed with the same reason.
500
501The third form (kill self) is the same as the second form, except that
502C<$rvport> defaults to C<$SELF>.
503
504In the last form (message), a message of the form C<@msg, @reason> will be 650In the last form (message), a message of the form C<$rcvport, @msg,
505C<snd>. 651@reason> will be C<snd>.
506 652
507Monitoring-actions are one-shot: once messages are lost (and a monitoring 653Monitoring-actions are one-shot: once messages are lost (and a monitoring
508alert was raised), they are removed and will not trigger again. 654alert was raised), they are removed and will not trigger again, even if it
655turns out that the port is still alive (but monitoring actions added after
656that will again trigger).
509 657
510As a rule of thumb, monitoring requests should always monitor a port from 658As a rule of thumb, monitoring requests should always monitor a remote
511a local port (or callback). The reason is that kill messages might get 659port locally (using a local C<$rcvport> or a callback). The reason is that
512lost, just like any other message. Another less obvious reason is that 660kill messages might get lost, just like any other message. Another less
513even monitoring requests can get lost (for example, when the connection 661obvious reason is that even monitoring requests can get lost (for example,
514to the other node goes down permanently). When monitoring a port locally 662when the connection to the other node goes down permanently). When
515these problems do not exist. 663monitoring a port locally these problems do not exist.
516 664
517C<mon> effectively guarantees that, in the absence of hardware failures, 665C<mon> effectively guarantees that, in the absence of hardware failures,
518after starting the monitor, either all messages sent to the port will 666after starting the monitor, either all messages sent to the port will
519arrive, or the monitoring action will be invoked after possible message 667arrive, or the monitoring action will be invoked after possible message
520loss has been detected. No messages will be lost "in between" (after 668loss has been detected. No messages will be lost "in between" (after
565 } 713 }
566 714
567 $node->monitor ($port, $cb); 715 $node->monitor ($port, $cb);
568 716
569 defined wantarray 717 defined wantarray
570 and ($cb += 0, AnyEvent::Util::guard { $node->unmonitor ($port, $cb) }) 718 and ($cb += 0, Guard::guard { $node->unmonitor ($port, $cb) })
571} 719}
572 720
573=item $guard = mon_guard $port, $ref, $ref... 721=item $guard = mon_guard $port, $ref, $ref...
574 722
575Monitors the given C<$port> and keeps the passed references. When the port 723Monitors the given C<$port> and keeps the passed references. When the port
598 746
599=item kil $port[, @reason] 747=item kil $port[, @reason]
600 748
601Kill the specified port with the given C<@reason>. 749Kill the specified port with the given C<@reason>.
602 750
603If no C<@reason> is specified, then the port is killed "normally" (ports 751If no C<@reason> is specified, then the port is killed "normally" -
604monitoring other ports will not necessarily die because a port dies 752monitor callback will be invoked, but the kil will not cause linked ports
605"normally"). 753(C<mon $mport, $lport> form) to get killed.
606 754
607Otherwise, linked ports get killed with the same reason (second form of 755If a C<@reason> is specified, then linked ports (C<mon $mport, $lport>
608C<mon>, see above). 756form) get killed with the same reason.
609 757
610Runtime errors while evaluating C<rcv> callbacks or inside C<psub> blocks 758Runtime errors while evaluating C<rcv> callbacks or inside C<psub> blocks
611will be reported as reason C<< die => $@ >>. 759will be reported as reason C<< die => $@ >>.
612 760
613Transport/communication errors are reported as C<< transport_error => 761Transport/communication errors are reported as C<< transport_error =>
614$message >>. 762$message >>.
615 763
616=cut 764Common idioms:
765
766 # silently remove yourself, do not kill linked ports
767 kil $SELF;
768
769 # report a failure in some detail
770 kil $SELF, failure_mode_1 => "it failed with too high temperature";
771
772 # do not waste much time with killing, just die when something goes wrong
773 open my $fh, "<file"
774 or die "file: $!";
617 775
618=item $port = spawn $node, $initfunc[, @initdata] 776=item $port = spawn $node, $initfunc[, @initdata]
619 777
620Creates a port on the node C<$node> (which can also be a port ID, in which 778Creates a port on the node C<$node> (which can also be a port ID, in which
621case it's the node where that port resides). 779case it's the node where that port resides).
679} 837}
680 838
681sub spawn(@) { 839sub spawn(@) {
682 my ($nodeid, undef) = split /#/, shift, 2; 840 my ($nodeid, undef) = split /#/, shift, 2;
683 841
684 my $id = "$RUNIQ." . $ID++; 842 my $id = $RUNIQ . ++$ID;
685 843
686 $_[0] =~ /::/ 844 $_[0] =~ /::/
687 or Carp::croak "spawn init function must be a fully-qualified name, caught"; 845 or Carp::croak "spawn init function must be a fully-qualified name, caught";
688 846
689 snd_to_func $nodeid, "AnyEvent::MP::_spawn" => $id, @_; 847 snd_to_func $nodeid, "AnyEvent::MP::_spawn" => $id, @_;
690 848
691 "$nodeid#$id" 849 "$nodeid#$id"
692} 850}
851
693 852
694=item after $timeout, @msg 853=item after $timeout, @msg
695 854
696=item after $timeout, $callback 855=item after $timeout, $callback
697 856
713 ? $action[0]() 872 ? $action[0]()
714 : snd @action; 873 : snd @action;
715 }; 874 };
716} 875}
717 876
877#=item $cb2 = timeout $seconds, $cb[, @args]
878
718=item cal $port, @msg, $callback[, $timeout] 879=item cal $port, @msg, $callback[, $timeout]
719 880
720A simple form of RPC - sends a message to the given C<$port> with the 881A simple form of RPC - sends a message to the given C<$port> with the
721given contents (C<@msg>), but adds a reply port to the message. 882given contents (C<@msg>), but appends a reply port to the message.
722 883
723The reply port is created temporarily just for the purpose of receiving 884The reply port is created temporarily just for the purpose of receiving
724the reply, and will be C<kil>ed when no longer needed. 885the reply, and will be C<kil>ed when no longer needed.
725 886
726A reply message sent to the port is passed to the C<$callback> as-is. 887A reply message sent to the port is passed to the C<$callback> as-is.
727 888
728If an optional time-out (in seconds) is given and it is not C<undef>, 889If an optional time-out (in seconds) is given and it is not C<undef>,
729then the callback will be called without any arguments after the time-out 890then the callback will be called without any arguments after the time-out
730elapsed and the port is C<kil>ed. 891elapsed and the port is C<kil>ed.
731 892
732If no time-out is given, then the local port will monitor the remote port 893If no time-out is given (or it is C<undef>), then the local port will
733instead, so it eventually gets cleaned-up. 894monitor the remote port instead, so it eventually gets cleaned-up.
734 895
735Currently this function returns the temporary port, but this "feature" 896Currently this function returns the temporary port, but this "feature"
736might go in future versions unless you can make a convincing case that 897might go in future versions unless you can make a convincing case that
737this is indeed useful for something. 898this is indeed useful for something.
738 899
767 $port 928 $port
768} 929}
769 930
770=back 931=back
771 932
933=head1 DISTRIBUTED DATABASE
934
935AnyEvent::MP comes with a simple distributed database. The database will
936be mirrored asynchronously on all global nodes. Other nodes bind to one
937of the global nodes for their needs. Every node has a "local database"
938which contains all the values that are set locally. All local databases
939are merged together to form the global database, which can be queried.
940
941The database structure is that of a two-level hash - the database hash
942contains hashes which contain values, similarly to a perl hash of hashes,
943i.e.:
944
945 $DATABASE{$family}{$subkey} = $value
946
947The top level hash key is called "family", and the second-level hash key
948is called "subkey" or simply "key".
949
950The family must be alphanumeric, i.e. start with a letter and consist
951of letters, digits, underscores and colons (C<[A-Za-z][A-Za-z0-9_:]*>,
952pretty much like Perl module names.
953
954As the family namespace is global, it is recommended to prefix family names
955with the name of the application or module using it.
956
957The subkeys must be non-empty strings, with no further restrictions.
958
959The values should preferably be strings, but other perl scalars should
960work as well (such as C<undef>, arrays and hashes).
961
962Every database entry is owned by one node - adding the same family/subkey
963combination on multiple nodes will not cause discomfort for AnyEvent::MP,
964but the result might be nondeterministic, i.e. the key might have
965different values on different nodes.
966
967Different subkeys in the same family can be owned by different nodes
968without problems, and in fact, this is the common method to create worker
969pools. For example, a worker port for image scaling might do this:
970
971 db_set my_image_scalers => $port; # value not used
972
973And clients looking for an image scaler will want to get the
974C<my_image_scalers> keys from time to time:
975
976 db_keys my_image_scalers => sub {
977 @ports = @{ $_[0] };
978 };
979
980Or better yet, they want to monitor the database family, so they always
981have a reasonable up-to-date copy:
982
983 db_mon my_image_scalers => sub {
984 @ports = keys %{ $_[0] };
985 };
986
987In general, you can set or delete single subkeys, but query and monitor
988whole families only.
989
990If you feel the need to monitor or query a single subkey, try giving it
991it's own family.
992
993=over
994
995=item $guard = db_set $family => $subkey [=> $value]
996
997Sets (or replaces) a key to the database - if C<$value> is omitted,
998C<undef> is used instead.
999
1000When called in non-void context, C<db_set> returns a guard that
1001automatically calls C<db_del> when it is destroyed.
1002
1003=item db_del $family => $subkey...
1004
1005Deletes one or more subkeys from the database family.
1006
1007=item $guard = db_reg $family => $port => $value
1008
1009=item $guard = db_reg $family => $port
1010
1011=item $guard = db_reg $family
1012
1013Registers a port in the given family and optionally returns a guard to
1014remove it.
1015
1016This function basically does the same as:
1017
1018 db_set $family => $port => $value
1019
1020Except that the port is monitored and automatically removed from the
1021database family when it is kil'ed.
1022
1023If C<$value> is missing, C<undef> is used. If C<$port> is missing, then
1024C<$SELF> is used.
1025
1026This function is most useful to register a port in some port group (which
1027is just another name for a database family), and have it removed when the
1028port is gone. This works best when the port is a local port.
1029
1030=cut
1031
1032sub db_reg($$;$) {
1033 my $family = shift;
1034 my $port = @_ ? shift : $SELF;
1035
1036 my $clr = sub { db_del $family => $port };
1037 mon $port, $clr;
1038
1039 db_set $family => $port => $_[0];
1040
1041 defined wantarray
1042 and &Guard::guard ($clr)
1043}
1044
1045=item db_family $family => $cb->(\%familyhash)
1046
1047Queries the named database C<$family> and call the callback with the
1048family represented as a hash. You can keep and freely modify the hash.
1049
1050=item db_keys $family => $cb->(\@keys)
1051
1052Same as C<db_family>, except it only queries the family I<subkeys> and passes
1053them as array reference to the callback.
1054
1055=item db_values $family => $cb->(\@values)
1056
1057Same as C<db_family>, except it only queries the family I<values> and passes them
1058as array reference to the callback.
1059
1060=item $guard = db_mon $family => $cb->(\%familyhash, \@added, \@changed, \@deleted)
1061
1062Creates a monitor on the given database family. Each time a key is
1063set or is deleted the callback is called with a hash containing the
1064database family and three lists of added, changed and deleted subkeys,
1065respectively. If no keys have changed then the array reference might be
1066C<undef> or even missing.
1067
1068If not called in void context, a guard object is returned that, when
1069destroyed, stops the monitor.
1070
1071The family hash reference and the key arrays belong to AnyEvent::MP and
1072B<must not be modified or stored> by the callback. When in doubt, make a
1073copy.
1074
1075As soon as possible after the monitoring starts, the callback will be
1076called with the intiial contents of the family, even if it is empty,
1077i.e. there will always be a timely call to the callback with the current
1078contents.
1079
1080It is possible that the callback is called with a change event even though
1081the subkey is already present and the value has not changed.
1082
1083The monitoring stops when the guard object is destroyed.
1084
1085Example: on every change to the family "mygroup", print out all keys.
1086
1087 my $guard = db_mon mygroup => sub {
1088 my ($family, $a, $c, $d) = @_;
1089 print "mygroup members: ", (join " ", keys %$family), "\n";
1090 };
1091
1092Exmaple: wait until the family "My::Module::workers" is non-empty.
1093
1094 my $guard; $guard = db_mon My::Module::workers => sub {
1095 my ($family, $a, $c, $d) = @_;
1096 return unless %$family;
1097 undef $guard;
1098 print "My::Module::workers now nonempty\n";
1099 };
1100
1101Example: print all changes to the family "AnyEvent::Fantasy::Module".
1102
1103 my $guard = db_mon AnyEvent::Fantasy::Module => sub {
1104 my ($family, $a, $c, $d) = @_;
1105
1106 print "+$_=$family->{$_}\n" for @$a;
1107 print "*$_=$family->{$_}\n" for @$c;
1108 print "-$_=$family->{$_}\n" for @$d;
1109 };
1110
1111=cut
1112
1113=back
1114
772=head1 AnyEvent::MP vs. Distributed Erlang 1115=head1 AnyEvent::MP vs. Distributed Erlang
773 1116
774AnyEvent::MP got lots of its ideas from distributed Erlang (Erlang node 1117AnyEvent::MP got lots of its ideas from distributed Erlang (Erlang node
775== aemp node, Erlang process == aemp port), so many of the documents and 1118== aemp node, Erlang process == aemp port), so many of the documents and
776programming techniques employed by Erlang apply to AnyEvent::MP. Here is a 1119programming techniques employed by Erlang apply to AnyEvent::MP. Here is a
787 1130
788=item * Node IDs are arbitrary strings in AEMP. 1131=item * Node IDs are arbitrary strings in AEMP.
789 1132
790Erlang relies on special naming and DNS to work everywhere in the same 1133Erlang relies on special naming and DNS to work everywhere in the same
791way. AEMP relies on each node somehow knowing its own address(es) (e.g. by 1134way. AEMP relies on each node somehow knowing its own address(es) (e.g. by
792configuration or DNS), but will otherwise discover other odes itself. 1135configuration or DNS), and possibly the addresses of some seed nodes, but
1136will otherwise discover other nodes (and their IDs) itself.
793 1137
794=item * Erlang has a "remote ports are like local ports" philosophy, AEMP 1138=item * Erlang has a "remote ports are like local ports" philosophy, AEMP
795uses "local ports are like remote ports". 1139uses "local ports are like remote ports".
796 1140
797The failure modes for local ports are quite different (runtime errors 1141The failure modes for local ports are quite different (runtime errors
806ports being the special case/exception, where transport errors cannot 1150ports being the special case/exception, where transport errors cannot
807occur. 1151occur.
808 1152
809=item * Erlang uses processes and a mailbox, AEMP does not queue. 1153=item * Erlang uses processes and a mailbox, AEMP does not queue.
810 1154
811Erlang uses processes that selectively receive messages, and therefore 1155Erlang uses processes that selectively receive messages out of order, and
812needs a queue. AEMP is event based, queuing messages would serve no 1156therefore needs a queue. AEMP is event based, queuing messages would serve
813useful purpose. For the same reason the pattern-matching abilities of 1157no useful purpose. For the same reason the pattern-matching abilities
814AnyEvent::MP are more limited, as there is little need to be able to 1158of AnyEvent::MP are more limited, as there is little need to be able to
815filter messages without dequeuing them. 1159filter messages without dequeuing them.
816 1160
817(But see L<Coro::MP> for a more Erlang-like process model on top of AEMP). 1161This is not a philosophical difference, but simply stems from AnyEvent::MP
1162being event-based, while Erlang is process-based.
1163
1164You can have a look at L<Coro::MP> for a more Erlang-like process model on
1165top of AEMP and Coro threads.
818 1166
819=item * Erlang sends are synchronous, AEMP sends are asynchronous. 1167=item * Erlang sends are synchronous, AEMP sends are asynchronous.
820 1168
821Sending messages in Erlang is synchronous and blocks the process (and 1169Sending messages in Erlang is synchronous and blocks the process until
1170a connection has been established and the message sent (and so does not
822so does not need a queue that can overflow). AEMP sends are immediate, 1171need a queue that can overflow). AEMP sends return immediately, connection
823connection establishment is handled in the background. 1172establishment is handled in the background.
824 1173
825=item * Erlang suffers from silent message loss, AEMP does not. 1174=item * Erlang suffers from silent message loss, AEMP does not.
826 1175
827Erlang makes few guarantees on messages delivery - messages can get lost 1176Erlang implements few guarantees on messages delivery - messages can get
828without any of the processes realising it (i.e. you send messages a, b, 1177lost without any of the processes realising it (i.e. you send messages a,
829and c, and the other side only receives messages a and c). 1178b, and c, and the other side only receives messages a and c).
830 1179
831AEMP guarantees correct ordering, and the guarantee that after one message 1180AEMP guarantees (modulo hardware errors) correct ordering, and the
832is lost, all following ones sent to the same port are lost as well, until 1181guarantee that after one message is lost, all following ones sent to the
833monitoring raises an error, so there are no silent "holes" in the message 1182same port are lost as well, until monitoring raises an error, so there are
834sequence. 1183no silent "holes" in the message sequence.
1184
1185If you want your software to be very reliable, you have to cope with
1186corrupted and even out-of-order messages in both Erlang and AEMP. AEMP
1187simply tries to work better in common error cases, such as when a network
1188link goes down.
835 1189
836=item * Erlang can send messages to the wrong port, AEMP does not. 1190=item * Erlang can send messages to the wrong port, AEMP does not.
837 1191
838In Erlang it is quite likely that a node that restarts reuses a process ID 1192In Erlang it is quite likely that a node that restarts reuses an Erlang
839known to other nodes for a completely different process, causing messages 1193process ID known to other nodes for a completely different process,
840destined for that process to end up in an unrelated process. 1194causing messages destined for that process to end up in an unrelated
1195process.
841 1196
842AEMP never reuses port IDs, so old messages or old port IDs floating 1197AEMP does not reuse port IDs, so old messages or old port IDs floating
843around in the network will not be sent to an unrelated port. 1198around in the network will not be sent to an unrelated port.
844 1199
845=item * Erlang uses unprotected connections, AEMP uses secure 1200=item * Erlang uses unprotected connections, AEMP uses secure
846authentication and can use TLS. 1201authentication and can use TLS.
847 1202
850 1205
851=item * The AEMP protocol is optimised for both text-based and binary 1206=item * The AEMP protocol is optimised for both text-based and binary
852communications. 1207communications.
853 1208
854The AEMP protocol, unlike the Erlang protocol, supports both programming 1209The AEMP protocol, unlike the Erlang protocol, supports both programming
855language independent text-only protocols (good for debugging) and binary, 1210language independent text-only protocols (good for debugging), and binary,
856language-specific serialisers (e.g. Storable). By default, unless TLS is 1211language-specific serialisers (e.g. Storable). By default, unless TLS is
857used, the protocol is actually completely text-based. 1212used, the protocol is actually completely text-based.
858 1213
859It has also been carefully designed to be implementable in other languages 1214It has also been carefully designed to be implementable in other languages
860with a minimum of work while gracefully degrading functionality to make the 1215with a minimum of work while gracefully degrading functionality to make the
861protocol simple. 1216protocol simple.
862 1217
863=item * AEMP has more flexible monitoring options than Erlang. 1218=item * AEMP has more flexible monitoring options than Erlang.
864 1219
865In Erlang, you can chose to receive I<all> exit signals as messages 1220In Erlang, you can chose to receive I<all> exit signals as messages or
866or I<none>, there is no in-between, so monitoring single processes is 1221I<none>, there is no in-between, so monitoring single Erlang processes is
867difficult to implement. Monitoring in AEMP is more flexible than in 1222difficult to implement.
868Erlang, as one can choose between automatic kill, exit message or callback 1223
869on a per-process basis. 1224Monitoring in AEMP is more flexible than in Erlang, as one can choose
1225between automatic kill, exit message or callback on a per-port basis.
870 1226
871=item * Erlang tries to hide remote/local connections, AEMP does not. 1227=item * Erlang tries to hide remote/local connections, AEMP does not.
872 1228
873Monitoring in Erlang is not an indicator of process death/crashes, in the 1229Monitoring in Erlang is not an indicator of process death/crashes, in the
874same way as linking is (except linking is unreliable in Erlang). 1230same way as linking is (except linking is unreliable in Erlang).
896overhead, as well as having to keep a proxy object everywhere. 1252overhead, as well as having to keep a proxy object everywhere.
897 1253
898Strings can easily be printed, easily serialised etc. and need no special 1254Strings can easily be printed, easily serialised etc. and need no special
899procedures to be "valid". 1255procedures to be "valid".
900 1256
901And as a result, a miniport consists of a single closure stored in a 1257And as a result, a port with just a default receiver consists of a single
902global hash - it can't become much cheaper. 1258code reference stored in a global hash - it can't become much cheaper.
903 1259
904=item Why favour JSON, why not a real serialising format such as Storable? 1260=item Why favour JSON, why not a real serialising format such as Storable?
905 1261
906In fact, any AnyEvent::MP node will happily accept Storable as framing 1262In fact, any AnyEvent::MP node will happily accept Storable as framing
907format, but currently there is no way to make a node use Storable by 1263format, but currently there is no way to make a node use Storable by
917Keeping your messages simple, concentrating on data structures rather than 1273Keeping your messages simple, concentrating on data structures rather than
918objects, will keep your messages clean, tidy and efficient. 1274objects, will keep your messages clean, tidy and efficient.
919 1275
920=back 1276=back
921 1277
1278=head1 PORTING FROM AnyEvent::MP VERSION 1.X
1279
1280AEMP version 2 has a few major incompatible changes compared to version 1:
1281
1282=over 4
1283
1284=item AnyEvent::MP::Global no longer has group management functions.
1285
1286At least not officially - the grp_* functions are still exported and might
1287work, but they will be removed in some later release.
1288
1289AnyEvent::MP now comes with a distributed database that is more
1290powerful. Its database families map closely to port groups, but the API
1291has changed (the functions are also now exported by AnyEvent::MP). Here is
1292a rough porting guide:
1293
1294 grp_reg $group, $port # old
1295 db_reg $group, $port # new
1296
1297 $list = grp_get $group # old
1298 db_keys $group, sub { my $list = shift } # new
1299
1300 grp_mon $group, $cb->(\@ports, $add, $del) # old
1301 db_mon $group, $cb->(\%ports, $add, $change, $del) # new
1302
1303C<grp_reg> is a no-brainer (just replace by C<db_reg>), but C<grp_get> is
1304no longer instant, because the local node might not have a copy of the
1305group. You can either modify your code to allow for a callback, or use
1306C<db_mon> to keep an updated copy of the group:
1307
1308 my $local_group_copy;
1309 db_mon $group => sub { $local_group_copy = $_[0] };
1310
1311 # now "keys %$local_group_copy" always returns the most up-to-date
1312 # list of ports in the group.
1313
1314C<grp_mon> can be replaced by C<db_mon> with minor changes - C<db_mon>
1315passes a hash as first argument, and an extra C<$chg> argument that can be
1316ignored:
1317
1318 db_mon $group => sub {
1319 my ($ports, $add, $chg, $del) = @_;
1320 $ports = [keys %$ports];
1321
1322 # now $ports, $add and $del are the same as
1323 # were originally passed by grp_mon.
1324 ...
1325 };
1326
1327=item Nodes not longer connect to all other nodes.
1328
1329In AEMP 1.x, every node automatically loads the L<AnyEvent::MP::Global>
1330module, which in turn would create connections to all other nodes in the
1331network (helped by the seed nodes).
1332
1333In version 2.x, global nodes still connect to all other global nodes, but
1334other nodes don't - now every node either is a global node itself, or
1335attaches itself to another global node.
1336
1337If a node isn't a global node itself, then it attaches itself to one
1338of its seed nodes. If that seed node isn't a global node yet, it will
1339automatically be upgraded to a global node.
1340
1341So in many cases, nothing needs to be changed - one just has to make sure
1342that all seed nodes are meshed together with the other seed nodes (as with
1343AEMP 1.x), and other nodes specify them as seed nodes. This is most easily
1344achieved by specifying the same set of seed nodes for all nodes in the
1345network.
1346
1347Not opening a connection to every other node is usually an advantage,
1348except when you need the lower latency of an already established
1349connection. To ensure a node establishes a connection to another node,
1350you can monitor the node port (C<mon $node, ...>), which will attempt to
1351create the connection (and notify you when the connection fails).
1352
1353=item Listener-less nodes (nodes without binds) are gone.
1354
1355And are not coming back, at least not in their old form. If no C<binds>
1356are specified for a node, AnyEvent::MP assumes a default of C<*:*>.
1357
1358There are vague plans to implement some form of routing domains, which
1359might or might not bring back listener-less nodes, but don't count on it.
1360
1361The fact that most connections are now optional somewhat mitigates this,
1362as a node can be effectively unreachable from the outside without any
1363problems, as long as it isn't a global node and only reaches out to other
1364nodes (as opposed to being contacted from other nodes).
1365
1366=item $AnyEvent::MP::Kernel::WARN has gone.
1367
1368AnyEvent has acquired a logging framework (L<AnyEvent::Log>), and AEMP now
1369uses this, and so should your programs.
1370
1371Every module now documents what kinds of messages it generates, with
1372AnyEvent::MP acting as a catch all.
1373
1374On the positive side, this means that instead of setting
1375C<PERL_ANYEVENT_MP_WARNLEVEL>, you can get away by setting C<AE_VERBOSE> -
1376much less to type.
1377
1378=back
1379
1380=head1 LOGGING
1381
1382AnyEvent::MP does not normally log anything by itself, but since it is the
1383root of the context hierarchy for AnyEvent::MP modules, it will receive
1384all log messages by submodules.
1385
922=head1 SEE ALSO 1386=head1 SEE ALSO
923 1387
924L<AnyEvent::MP::Intro> - a gentle introduction. 1388L<AnyEvent::MP::Intro> - a gentle introduction.
925 1389
926L<AnyEvent::MP::Kernel> - more, lower-level, stuff. 1390L<AnyEvent::MP::Kernel> - more, lower-level, stuff.
927 1391
928L<AnyEvent::MP::Global> - network maintainance and port groups, to find 1392L<AnyEvent::MP::Global> - network maintenance and port groups, to find
929your applications. 1393your applications.
1394
1395L<AnyEvent::MP::DataConn> - establish data connections between nodes.
930 1396
931L<AnyEvent::MP::LogCatcher> - simple service to display log messages from 1397L<AnyEvent::MP::LogCatcher> - simple service to display log messages from
932all nodes. 1398all nodes.
933 1399
934L<AnyEvent>. 1400L<AnyEvent>.

Diff Legend

Removed lines
+ Added lines
< Changed lines
> Changed lines