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.30 by root, Tue Aug 4 23:35:51 2009 UTC vs.
Revision 1.142 by root, Fri Mar 23 13:44:01 2012 UTC

1=head1 NAME 1=head1 NAME
2 2
3AnyEvent::MP - multi-processing/message-passing framework 3AnyEvent::MP - erlang-style multi-processing/message-passing framework
4 4
5=head1 SYNOPSIS 5=head1 SYNOPSIS
6 6
7 use AnyEvent::MP; 7 use AnyEvent::MP;
8 8
9 $NODE # contains this node's noderef 9 $NODE # contains this node's node ID
10 NODE # returns this node's noderef 10 NODE # returns this node's node ID
11 NODE $port # returns the noderef of the port
12 11
12 $SELF # receiving/own port id in rcv callbacks
13
14 # initialise the node so it can send/receive messages
15 configure;
16
17 # ports are message destinations
18
19 # sending messages
13 snd $port, type => data...; 20 snd $port, type => data...;
21 snd $port, @msg;
22 snd @msg_with_first_element_being_a_port;
14 23
15 $SELF # receiving/own port id in rcv callbacks 24 # creating/using ports, the simple way
25 my $simple_port = port { my @msg = @_ };
16 26
17 rcv $port, smartmatch => $cb->($port, @msg); 27 # creating/using ports, tagged message matching
18 28 my $port = port;
19 # examples:
20 rcv $port2, ping => sub { snd $_[0], "pong"; 0 }; 29 rcv $port, ping => sub { snd $_[0], "pong" };
21 rcv $port1, pong => sub { warn "pong received\n" }; 30 rcv $port, pong => sub { warn "pong received\n" };
22 snd $port2, ping => $port1;
23 31
24 # more, smarter, matches (_any_ is exported by this module) 32 # create a port on another node
25 rcv $port, [child_died => $pid] => sub { ... 33 my $port = spawn $node, $initfunc, @initdata;
26 rcv $port, [_any_, _any_, 3] => sub { .. $_[2] is 3 34
35 # destroy a port again
36 kil $port; # "normal" kill
37 kil $port, my_error => "everything is broken"; # error kill
38
39 # monitoring
40 mon $port, $cb->(@msg) # callback is invoked on death
41 mon $port, $localport # kill localport on abnormal death
42 mon $port, $localport, @msg # send message on death
43
44 # temporarily execute code in port context
45 peval $port, sub { die "kill the port!" };
46
47 # execute callbacks in $SELF port context
48 my $timer = AE::timer 1, 0, psub {
49 die "kill the port, delayed";
50 };
27 51
28=head1 DESCRIPTION 52=head1 DESCRIPTION
29 53
30This module (-family) implements a simple message passing framework. 54This module (-family) implements a simple message passing framework.
31 55
32Despite its simplicity, you can securely message other processes running 56Despite its simplicity, you can securely message other processes running
33on the same or other hosts. 57on the same or other hosts, and you can supervise entities remotely.
34 58
35For an introduction to this module family, see the L<AnyEvent::MP::Intro> 59For an introduction to this module family, see the L<AnyEvent::MP::Intro>
36manual page. 60manual page and the examples under F<eg/>.
37
38At the moment, this module family is severly broken and underdocumented,
39so do not use. This was uploaded mainly to reserve the CPAN namespace -
40stay tuned! The basic API should be finished, however.
41 61
42=head1 CONCEPTS 62=head1 CONCEPTS
43 63
44=over 4 64=over 4
45 65
46=item port 66=item port
47 67
48A port is something you can send messages to (with the C<snd> function). 68Not to be confused with a TCP port, a "port" is something you can send
69messages to (with the C<snd> function).
49 70
50Some ports allow you to register C<rcv> handlers that can match specific 71Ports allow you to register C<rcv> handlers that can match all or just
51messages. All C<rcv> handlers will receive messages they match, messages 72some messages. Messages send to ports will not be queued, regardless of
52will not be queued. 73anything was listening for them or not.
53 74
75Ports are represented by (printable) strings called "port IDs".
76
54=item port id - C<noderef#portname> 77=item port ID - C<nodeid#portname>
55 78
56A port id is normaly the concatenation of a noderef, a hash-mark (C<#>) as 79A port ID is the concatenation of a node ID, a hash-mark (C<#>)
57separator, and a port name (a printable string of unspecified format). An 80as separator, and a port name (a printable string of unspecified
58exception is the the node port, whose ID is identical to its node 81format created by AnyEvent::MP).
59reference.
60 82
61=item node 83=item node
62 84
63A node is a single process containing at least one port - the node 85A node is a single process containing at least one port - the node port,
64port. You can send messages to node ports to find existing ports or to 86which enables nodes to manage each other remotely, and to create new
65create new ports, among other things. 87ports.
66 88
67Nodes are either private (single-process only), slaves (connected to a 89Nodes are either public (have one or more listening ports) or private
68master node only) or public nodes (connectable from unrelated nodes). 90(no listening ports). Private nodes cannot talk to other private nodes
91currently, but all nodes can talk to public nodes.
69 92
70=item noderef - C<host:port,host:port...>, C<id@noderef>, C<id> 93Nodes is represented by (printable) strings called "node IDs".
71 94
72A node reference is a string that either simply identifies the node (for 95=item node ID - C<[A-Za-z0-9_\-.:]*>
73private and slave nodes), or contains a recipe on how to reach a given
74node (for public nodes).
75 96
76This recipe is simply a comma-separated list of C<address:port> pairs (for 97A node ID is a string that uniquely identifies the node within a
77TCP/IP, other protocols might look different). 98network. Depending on the configuration used, node IDs can look like a
99hostname, a hostname and a port, or a random string. AnyEvent::MP itself
100doesn't interpret node IDs in any way except to uniquely identify a node.
78 101
79Node references come in two flavours: resolved (containing only numerical 102=item binds - C<ip:port>
80addresses) or unresolved (where hostnames are used instead of addresses).
81 103
82Before using an unresolved node reference in a message you first have to 104Nodes can only talk to each other by creating some kind of connection to
83resolve it. 105each other. To do this, nodes should listen on one or more local transport
106endpoints - binds.
107
108Currently, only standard C<ip:port> specifications can be used, which
109specify TCP ports to listen on. So a bind is basically just a tcp socket
110in listening mode thta accepts conenctions form other nodes.
111
112=item seed nodes
113
114When a node starts, it knows nothing about the network it is in - it
115needs to connect to at least one other node that is already in the
116network. These other nodes are called "seed nodes".
117
118Seed nodes themselves are not special - they are seed nodes only because
119some other node I<uses> them as such, but any node can be used as seed
120node for other nodes, and eahc node cna use a different set of seed nodes.
121
122In addition to discovering the network, seed nodes are also used to
123maintain the network - all nodes using the same seed node form are part of
124the same network. If a network is split into multiple subnets because e.g.
125the network link between the parts goes down, then using the same seed
126nodes for all nodes ensures that eventually the subnets get merged again.
127
128Seed nodes are expected to be long-running, and at least one seed node
129should always be available. They should also be relatively responsive - a
130seed node that blocks for long periods will slow down everybody else.
131
132For small networks, it's best if every node uses the same set of seed
133nodes. For large networks, it can be useful to specify "regional" seed
134nodes for most nodes in an area, and use all seed nodes as seed nodes for
135each other. What's important is that all seed nodes connections form a
136complete graph, so that the network cannot split into separate subnets
137forever.
138
139Seed nodes are represented by seed IDs.
140
141=item seed IDs - C<host:port>
142
143Seed IDs are transport endpoint(s) (usually a hostname/IP address and a
144TCP port) of nodes that should be used as seed nodes.
145
146=item global nodes
147
148An AEMP network needs a discovery service - nodes need to know how to
149connect to other nodes they only know by name. In addition, AEMP offers a
150distributed "group database", which maps group names to a list of strings
151- for example, to register worker ports.
152
153A network needs at least one global node to work, and allows every node to
154be a global node.
155
156Any node that loads the L<AnyEvent::MP::Global> module becomes a global
157node and tries to keep connections to all other nodes. So while it can
158make sense to make every node "global" in small networks, it usually makes
159sense to only make seed nodes into global nodes in large networks (nodes
160keep connections to seed nodes and global nodes, so makign them the same
161reduces overhead).
84 162
85=back 163=back
86 164
87=head1 VARIABLES/FUNCTIONS 165=head1 VARIABLES/FUNCTIONS
88 166
90 168
91=cut 169=cut
92 170
93package AnyEvent::MP; 171package AnyEvent::MP;
94 172
173use AnyEvent::MP::Config ();
95use AnyEvent::MP::Base; 174use AnyEvent::MP::Kernel;
175use AnyEvent::MP::Kernel qw(%NODE %PORT %PORT_DATA $UNIQ $RUNIQ $ID);
96 176
97use common::sense; 177use common::sense;
98 178
99use Carp (); 179use Carp ();
100 180
101use AE (); 181use AnyEvent ();
182use Guard ();
102 183
103use base "Exporter"; 184use base "Exporter";
104 185
105our $VERSION = '0.1'; 186our $VERSION = $AnyEvent::MP::Config::VERSION;
187
106our @EXPORT = qw( 188our @EXPORT = qw(
107 NODE $NODE *SELF node_of _any_ 189 NODE $NODE *SELF node_of after
108 resolve_node 190 configure
109 become_slave become_public 191 snd rcv mon mon_guard kil psub peval spawn cal
110 snd rcv mon kil reg psub
111 port 192 port
193 db_set db_del db_reg
194 db_mon db_family db_keys db_values
112); 195);
113 196
114our $SELF; 197our $SELF;
115 198
116sub _self_die() { 199sub _self_die() {
119 kil $SELF, die => $msg; 202 kil $SELF, die => $msg;
120} 203}
121 204
122=item $thisnode = NODE / $NODE 205=item $thisnode = NODE / $NODE
123 206
124The C<NODE> function returns, and the C<$NODE> variable contains 207The C<NODE> function returns, and the C<$NODE> variable contains, the node
125the noderef of the local node. The value is initialised by a call 208ID of the node running in the current process. This value is initialised by
126to C<become_public> or C<become_slave>, after which all local port 209a call to C<configure>.
127identifiers become invalid.
128 210
129=item $noderef = node_of $portid 211=item $nodeid = node_of $port
130 212
131Extracts and returns the noderef from a portid or a noderef. 213Extracts and returns the node ID from a port ID or a node ID.
132 214
133=item $cv = resolve_node $noderef 215=item configure $profile, key => value...
134 216
135Takes an unresolved node reference that may contain hostnames and 217=item configure key => value...
136abbreviated IDs, resolves all of them and returns a resolved node
137reference.
138 218
139In addition to C<address:port> pairs allowed in resolved noderefs, the 219Before a node can talk to other nodes on the network (i.e. enter
140following forms are supported: 220"distributed mode") it has to configure itself - the minimum a node needs
221to know is its own name, and optionally it should know the addresses of
222some other nodes in the network to discover other nodes.
223
224This function configures a node - it must be called exactly once (or
225never) before calling other AnyEvent::MP functions.
226
227The key/value pairs are basically the same ones as documented for the
228F<aemp> command line utility (sans the set/del prefix), with these additions:
141 229
142=over 4 230=over 4
143 231
144=item the empty string 232=item norc => $boolean (default false)
145 233
146An empty-string component gets resolved as if the default port (4040) was 234If true, then the rc file (e.g. F<~/.perl-anyevent-mp>) will I<not>
147specified. 235be consulted - all configuraiton options must be specified in the
236C<configure> call.
148 237
149=item naked port numbers (e.g. C<1234>) 238=item force => $boolean (default false)
150 239
151These are resolved by prepending the local nodename and a colon, to be 240IF true, then the values specified in the C<configure> will take
152further resolved. 241precedence over any values configured via the rc file. The default is for
153 242the rc file to override any options specified in the program.
154=item hostnames (e.g. C<localhost:1234>, C<localhost>)
155
156These are resolved by using AnyEvent::DNS to resolve them, optionally
157looking up SRV records for the C<aemp=4040> port, if no port was
158specified.
159 243
160=back 244=back
245
246=over 4
247
248=item step 1, gathering configuration from profiles
249
250The function first looks up a profile in the aemp configuration (see the
251L<aemp> commandline utility). The profile name can be specified via the
252named C<profile> parameter or can simply be the first parameter). If it is
253missing, then the nodename (F<uname -n>) will be used as profile name.
254
255The profile data is then gathered as follows:
256
257First, all remaining key => value pairs (all of which are conveniently
258undocumented at the moment) will be interpreted as configuration
259data. Then they will be overwritten by any values specified in the global
260default configuration (see the F<aemp> utility), then the chain of
261profiles chosen by the profile name (and any C<parent> attributes).
262
263That means that the values specified in the profile have highest priority
264and the values specified directly via C<configure> have lowest priority,
265and can only be used to specify defaults.
266
267If the profile specifies a node ID, then this will become the node ID of
268this process. If not, then the profile name will be used as node ID, with
269a unique randoms tring (C</%u>) appended.
270
271The node ID can contain some C<%> sequences that are expanded: C<%n>
272is expanded to the local nodename, C<%u> is replaced by a random
273strign to make the node unique. For example, the F<aemp> commandline
274utility uses C<aemp/%n/%u> as nodename, which might expand to
275C<aemp/cerebro/ZQDGSIkRhEZQDGSIkRhE>.
276
277=item step 2, bind listener sockets
278
279The next step is to look up the binds in the profile, followed by binding
280aemp protocol listeners on all binds specified (it is possible and valid
281to have no binds, meaning that the node cannot be contacted form the
282outside. This means the node cannot talk to other nodes that also have no
283binds, but it can still talk to all "normal" nodes).
284
285If the profile does not specify a binds list, then a default of C<*> is
286used, meaning the node will bind on a dynamically-assigned port on every
287local IP address it finds.
288
289=item step 3, connect to seed nodes
290
291As the last step, the seed ID list from the profile is passed to the
292L<AnyEvent::MP::Global> module, which will then use it to keep
293connectivity with at least one node at any point in time.
294
295=back
296
297Example: become a distributed node using the local node name as profile.
298This should be the most common form of invocation for "daemon"-type nodes.
299
300 configure
301
302Example: become a semi-anonymous node. This form is often used for
303commandline clients.
304
305 configure nodeid => "myscript/%n/%u";
306
307Example: configure a node using a profile called seed, which is suitable
308for a seed node as it binds on all local addresses on a fixed port (4040,
309customary for aemp).
310
311 # use the aemp commandline utility
312 # aemp profile seed binds '*:4040'
313
314 # then use it
315 configure profile => "seed";
316
317 # or simply use aemp from the shell again:
318 # aemp run profile seed
319
320 # or provide a nicer-to-remember nodeid
321 # aemp run profile seed nodeid "$(hostname)"
161 322
162=item $SELF 323=item $SELF
163 324
164Contains the current port id while executing C<rcv> callbacks or C<psub> 325Contains the current port id while executing C<rcv> callbacks or C<psub>
165blocks. 326blocks.
166 327
167=item SELF, %SELF, @SELF... 328=item *SELF, SELF, %SELF, @SELF...
168 329
169Due to some quirks in how perl exports variables, it is impossible to 330Due to some quirks in how perl exports variables, it is impossible to
170just export C<$SELF>, all the symbols called C<SELF> are exported by this 331just export C<$SELF>, all the symbols named C<SELF> are exported by this
171module, but only C<$SELF> is currently used. 332module, but only C<$SELF> is currently used.
172 333
173=item snd $portid, type => @data 334=item snd $port, type => @data
174 335
175=item snd $portid, @msg 336=item snd $port, @msg
176 337
177Send the given message to the given port ID, which can identify either 338Send the given message to the given port, which can identify either a
178a local or a remote port, and can be either a string or soemthignt hat 339local or a remote port, and must be a port ID.
179stringifies a sa port ID (such as a port object :).
180 340
181While the message can be about anything, it is highly recommended to use a 341While the message can be almost anything, it is highly recommended to
182string as first element (a portid, or some word that indicates a request 342use a string as first element (a port ID, or some word that indicates a
183type etc.). 343request type etc.) and to consist if only simple perl values (scalars,
344arrays, hashes) - if you think you need to pass an object, think again.
184 345
185The message data effectively becomes read-only after a call to this 346The message data logically becomes read-only after a call to this
186function: modifying any argument is not allowed and can cause many 347function: modifying any argument (or values referenced by them) is
187problems. 348forbidden, as there can be considerable time between the call to C<snd>
349and the time the message is actually being serialised - in fact, it might
350never be copied as within the same process it is simply handed to the
351receiving port.
188 352
189The type of data you can transfer depends on the transport protocol: when 353The type of data you can transfer depends on the transport protocol: when
190JSON is used, then only strings, numbers and arrays and hashes consisting 354JSON is used, then only strings, numbers and arrays and hashes consisting
191of those are allowed (no objects). When Storable is used, then anything 355of those are allowed (no objects). When Storable is used, then anything
192that Storable can serialise and deserialise is allowed, and for the local 356that Storable can serialise and deserialise is allowed, and for the local
193node, anything can be passed. 357node, anything can be passed. Best rely only on the common denominator of
358these.
194 359
195=item kil $portid[, @reason] 360=item $local_port = port
196 361
197Kill the specified port with the given C<@reason>. 362Create a new local port object and returns its port ID. Initially it has
363no callbacks set and will throw an error when it receives messages.
198 364
199If no C<@reason> is specified, then the port is killed "normally" (linked 365=item $local_port = port { my @msg = @_ }
200ports will not be kileld, or even notified).
201 366
202Otherwise, linked ports get killed with the same reason (second form of 367Creates a new local port, and returns its ID. Semantically the same as
203C<mon>, see below). 368creating a port and calling C<rcv $port, $callback> on it.
204 369
205Runtime errors while evaluating C<rcv> callbacks or inside C<psub> blocks 370The block will be called for every message received on the port, with the
206will be reported as reason C<< die => $@ >>. 371global variable C<$SELF> set to the port ID. Runtime errors will cause the
372port to be C<kil>ed. The message will be passed as-is, no extra argument
373(i.e. no port ID) will be passed to the callback.
207 374
208Transport/communication errors are reported as C<< transport_error => 375If you want to stop/destroy the port, simply C<kil> it:
209$message >>.
210 376
211=item $guard = mon $portid, $cb->(@reason) 377 my $port = port {
378 my @msg = @_;
379 ...
380 kil $SELF;
381 };
212 382
213=item $guard = mon $portid, $otherport 383=cut
214 384
215=item $guard = mon $portid, $otherport, @msg 385sub rcv($@);
216 386
387my $KILME = sub {
388 (my $tag = substr $_[0], 0, 30) =~ s/([\x20-\x7e])/./g;
389 kil $SELF, unhandled_message => "no callback found for message '$tag'";
390};
391
392sub port(;&) {
393 my $id = $UNIQ . ++$ID;
394 my $port = "$NODE#$id";
395
396 rcv $port, shift || $KILME;
397
398 $port
399}
400
401=item rcv $local_port, $callback->(@msg)
402
403Replaces the default callback on the specified port. There is no way to
404remove the default callback: use C<sub { }> to disable it, or better
405C<kil> the port when it is no longer needed.
406
407The global C<$SELF> (exported by this module) contains C<$port> while
408executing the callback. Runtime errors during callback execution will
409result in the port being C<kil>ed.
410
411The default callback receives all messages not matched by a more specific
412C<tag> match.
413
414=item rcv $local_port, tag => $callback->(@msg_without_tag), ...
415
416Register (or replace) callbacks to be called on messages starting with the
417given tag on the given port (and return the port), or unregister it (when
418C<$callback> is C<$undef> or missing). There can only be one callback
419registered for each tag.
420
421The original message will be passed to the callback, after the first
422element (the tag) has been removed. The callback will use the same
423environment as the default callback (see above).
424
425Example: create a port and bind receivers on it in one go.
426
427 my $port = rcv port,
428 msg1 => sub { ... },
429 msg2 => sub { ... },
430 ;
431
432Example: create a port, bind receivers and send it in a message elsewhere
433in one go:
434
435 snd $otherport, reply =>
436 rcv port,
437 msg1 => sub { ... },
438 ...
439 ;
440
441Example: temporarily register a rcv callback for a tag matching some port
442(e.g. for an rpc reply) and unregister it after a message was received.
443
444 rcv $port, $otherport => sub {
445 my @reply = @_;
446
447 rcv $SELF, $otherport;
448 };
449
450=cut
451
452sub rcv($@) {
453 my $port = shift;
454 my ($nodeid, $portid) = split /#/, $port, 2;
455
456 $NODE{$nodeid} == $NODE{""}
457 or Carp::croak "$port: rcv can only be called on local ports, caught";
458
459 while (@_) {
460 if (ref $_[0]) {
461 if (my $self = $PORT_DATA{$portid}) {
462 "AnyEvent::MP::Port" eq ref $self
463 or Carp::croak "$port: rcv can only be called on message matching ports, caught";
464
465 $self->[0] = shift;
466 } else {
467 my $cb = shift;
468 $PORT{$portid} = sub {
469 local $SELF = $port;
470 eval { &$cb }; _self_die if $@;
471 };
472 }
473 } elsif (defined $_[0]) {
474 my $self = $PORT_DATA{$portid} ||= do {
475 my $self = bless [$PORT{$portid} || sub { }, { }, $port], "AnyEvent::MP::Port";
476
477 $PORT{$portid} = sub {
478 local $SELF = $port;
479
480 if (my $cb = $self->[1]{$_[0]}) {
481 shift;
482 eval { &$cb }; _self_die if $@;
483 } else {
484 &{ $self->[0] };
485 }
486 };
487
488 $self
489 };
490
491 "AnyEvent::MP::Port" eq ref $self
492 or Carp::croak "$port: rcv can only be called on message matching ports, caught";
493
494 my ($tag, $cb) = splice @_, 0, 2;
495
496 if (defined $cb) {
497 $self->[1]{$tag} = $cb;
498 } else {
499 delete $self->[1]{$tag};
500 }
501 }
502 }
503
504 $port
505}
506
507=item peval $port, $coderef[, @args]
508
509Evaluates the given C<$codref> within the contetx of C<$port>, that is,
510when the code throews an exception the C<$port> will be killed.
511
512Any remaining args will be passed to the callback. Any return values will
513be returned to the caller.
514
515This is useful when you temporarily want to execute code in the context of
516a port.
517
518Example: create a port and run some initialisation code in it's context.
519
520 my $port = port { ... };
521
522 peval $port, sub {
523 init
524 or die "unable to init";
525 };
526
527=cut
528
529sub peval($$) {
530 local $SELF = shift;
531 my $cb = shift;
532
533 if (wantarray) {
534 my @res = eval { &$cb };
535 _self_die if $@;
536 @res
537 } else {
538 my $res = eval { &$cb };
539 _self_die if $@;
540 $res
541 }
542}
543
544=item $closure = psub { BLOCK }
545
546Remembers C<$SELF> and creates a closure out of the BLOCK. When the
547closure is executed, sets up the environment in the same way as in C<rcv>
548callbacks, i.e. runtime errors will cause the port to get C<kil>ed.
549
550The effect is basically as if it returned C<< sub { peval $SELF, sub {
551BLOCK }, @_ } >>.
552
553This is useful when you register callbacks from C<rcv> callbacks:
554
555 rcv delayed_reply => sub {
556 my ($delay, @reply) = @_;
557 my $timer = AE::timer $delay, 0, psub {
558 snd @reply, $SELF;
559 };
560 };
561
562=cut
563
564sub psub(&) {
565 my $cb = shift;
566
567 my $port = $SELF
568 or Carp::croak "psub can only be called from within rcv or psub callbacks, not";
569
570 sub {
571 local $SELF = $port;
572
573 if (wantarray) {
574 my @res = eval { &$cb };
575 _self_die if $@;
576 @res
577 } else {
578 my $res = eval { &$cb };
579 _self_die if $@;
580 $res
581 }
582 }
583}
584
585=item $guard = mon $port, $rcvport # kill $rcvport when $port dies
586
587=item $guard = mon $port # kill $SELF when $port dies
588
589=item $guard = mon $port, $cb->(@reason) # call $cb when $port dies
590
591=item $guard = mon $port, $rcvport, @msg # send a message when $port dies
592
217Monitor the given port and do something when the port is killed. 593Monitor the given port and do something when the port is killed or
594messages to it were lost, and optionally return a guard that can be used
595to stop monitoring again.
218 596
219In the first form, the callback is simply called with any number 597The first two forms distinguish between "normal" and "abnormal" kil's:
598
599In the first form (another port given), if the C<$port> is C<kil>'ed with
600a non-empty reason, the other port (C<$rcvport>) will be kil'ed with the
601same reason. That is, on "normal" kil's nothing happens, while under all
602other conditions, the other port is killed with the same reason.
603
604The second form (kill self) is the same as the first form, except that
605C<$rvport> defaults to C<$SELF>.
606
607The remaining forms don't distinguish between "normal" and "abnormal" kil's
608- it's up to the callback or receiver to check whether the C<@reason> is
609empty and act accordingly.
610
611In the third form (callback), the callback is simply called with any
220of C<@reason> elements (no @reason means that the port was deleted 612number of C<@reason> elements (empty @reason means that the port was deleted
221"normally"). Note also that I<< the callback B<must> never die >>, so use 613"normally"). Note also that I<< the callback B<must> never die >>, so use
222C<eval> if unsure. 614C<eval> if unsure.
223 615
224In the second form, the other port will be C<kil>'ed with C<@reason>, iff 616In the last form (message), a message of the form C<$rcvport, @msg,
225a @reason was specified, i.e. on "normal" kils nothing happens, while 617@reason> will be C<snd>.
226under all other conditions, the other port is killed with the same reason.
227 618
228In the last form, a message of the form C<@msg, @reason> will be C<snd>. 619Monitoring-actions are one-shot: once messages are lost (and a monitoring
620alert was raised), they are removed and will not trigger again, even if it
621turns out that the port is still alive.
622
623As a rule of thumb, monitoring requests should always monitor a remote
624port locally (using a local C<$rcvport> or a callback). The reason is that
625kill messages might get lost, just like any other message. Another less
626obvious reason is that even monitoring requests can get lost (for example,
627when the connection to the other node goes down permanently). When
628monitoring a port locally these problems do not exist.
629
630C<mon> effectively guarantees that, in the absence of hardware failures,
631after starting the monitor, either all messages sent to the port will
632arrive, or the monitoring action will be invoked after possible message
633loss has been detected. No messages will be lost "in between" (after
634the first lost message no further messages will be received by the
635port). After the monitoring action was invoked, further messages might get
636delivered again.
637
638Inter-host-connection timeouts and monitoring depend on the transport
639used. The only transport currently implemented is TCP, and AnyEvent::MP
640relies on TCP to detect node-downs (this can take 10-15 minutes on a
641non-idle connection, and usually around two hours for idle connections).
642
643This means that monitoring is good for program errors and cleaning up
644stuff eventually, but they are no replacement for a timeout when you need
645to ensure some maximum latency.
229 646
230Example: call a given callback when C<$port> is killed. 647Example: call a given callback when C<$port> is killed.
231 648
232 mon $port, sub { warn "port died because of <@_>\n" }; 649 mon $port, sub { warn "port died because of <@_>\n" };
233 650
234Example: kill ourselves when C<$port> is killed abnormally. 651Example: kill ourselves when C<$port> is killed abnormally.
235 652
236 mon $port, $self; 653 mon $port;
237 654
238Example: send us a restart message another C<$port> is killed. 655Example: send us a restart message when another C<$port> is killed.
239 656
240 mon $port, $self => "restart"; 657 mon $port, $self => "restart";
241 658
242=cut 659=cut
243 660
244sub mon { 661sub mon {
245 my ($noderef, $port) = split /#/, shift, 2; 662 my ($nodeid, $port) = split /#/, shift, 2;
246 663
247 my $node = $NODE{$noderef} || add_node $noderef; 664 my $node = $NODE{$nodeid} || add_node $nodeid;
248 665
249 my $cb = shift; 666 my $cb = @_ ? shift : $SELF || Carp::croak 'mon: called with one argument only, but $SELF not set,';
250 667
251 unless (ref $cb) { 668 unless (ref $cb) {
252 if (@_) { 669 if (@_) {
253 # send a kill info message 670 # send a kill info message
254 my (@msg) = ($cb, @_); 671 my (@msg) = ($cb, @_);
261 } 678 }
262 679
263 $node->monitor ($port, $cb); 680 $node->monitor ($port, $cb);
264 681
265 defined wantarray 682 defined wantarray
266 and AnyEvent::Util::guard { $node->unmonitor ($port, $cb) } 683 and ($cb += 0, Guard::guard { $node->unmonitor ($port, $cb) })
267} 684}
268 685
269=item $guard = mon_guard $port, $ref, $ref... 686=item $guard = mon_guard $port, $ref, $ref...
270 687
271Monitors the given C<$port> and keeps the passed references. When the port 688Monitors the given C<$port> and keeps the passed references. When the port
272is killed, the references will be freed. 689is killed, the references will be freed.
273 690
274Optionally returns a guard that will stop the monitoring. 691Optionally returns a guard that will stop the monitoring.
275 692
276This function is useful when you create e.g. timers or other watchers and 693This function is useful when you create e.g. timers or other watchers and
277want to free them when the port gets killed: 694want to free them when the port gets killed (note the use of C<psub>):
278 695
279 $port->rcv (start => sub { 696 $port->rcv (start => sub {
280 my $timer; $timer = mon_guard $port, AE::timer 1, 1, sub { 697 my $timer; $timer = mon_guard $port, AE::timer 1, 1, psub {
281 undef $timer if 0.9 < rand; 698 undef $timer if 0.9 < rand;
282 }); 699 });
283 }); 700 });
284 701
285=cut 702=cut
286 703
287sub mon_guard { 704sub mon_guard {
288 my ($port, @refs) = @_; 705 my ($port, @refs) = @_;
289 706
707 #TODO: mon-less form?
708
290 mon $port, sub { 0 && @refs } 709 mon $port, sub { 0 && @refs }
291} 710}
292 711
293=item lnk $port1, $port2 712=item kil $port[, @reason]
294 713
295Link two ports. This is simply a shorthand for: 714Kill the specified port with the given C<@reason>.
296 715
297 mon $port1, $port2; 716If no C<@reason> is specified, then the port is killed "normally" -
298 mon $port2, $port1; 717monitor callback will be invoked, but the kil will not cause linked ports
718(C<mon $mport, $lport> form) to get killed.
299 719
300It means that if either one is killed abnormally, the other one gets 720If a C<@reason> is specified, then linked ports (C<mon $mport, $lport>
301killed as well. 721form) get killed with the same reason.
302 722
303=item $local_port = port 723Runtime errors while evaluating C<rcv> callbacks or inside C<psub> blocks
724will be reported as reason C<< die => $@ >>.
304 725
305Create a new local port object that supports message matching. 726Transport/communication errors are reported as C<< transport_error =>
727$message >>.
306 728
307=item $portid = port { my @msg = @_; $finished } 729Common idioms:
308 730
309Creates a "mini port", that is, a very lightweight port without any 731 # silently remove yourself, do not kill linked ports
310pattern matching behind it, and returns its ID. 732 kil $SELF;
311 733
312The block will be called for every message received on the port. When the 734 # report a failure in some detail
313callback returns a true value its job is considered "done" and the port 735 kil $SELF, failure_mode_1 => "it failed with too high temperature";
314will be destroyed. Otherwise it will stay alive.
315 736
316The message will be passed as-is, no extra argument (i.e. no port id) will 737 # do not waste much time with killing, just die when something goes wrong
317be passed to the callback. 738 open my $fh, "<file"
739 or die "file: $!";
318 740
319If you need the local port id in the callback, this works nicely: 741=item $port = spawn $node, $initfunc[, @initdata]
320 742
321 my $port; $port = miniport { 743Creates a port on the node C<$node> (which can also be a port ID, in which
322 snd $otherport, reply => $port; 744case it's the node where that port resides).
745
746The port ID of the newly created port is returned immediately, and it is
747possible to immediately start sending messages or to monitor the port.
748
749After the port has been created, the init function is called on the remote
750node, in the same context as a C<rcv> callback. This function must be a
751fully-qualified function name (e.g. C<MyApp::Chat::Server::init>). To
752specify a function in the main program, use C<::name>.
753
754If the function doesn't exist, then the node tries to C<require>
755the package, then the package above the package and so on (e.g.
756C<MyApp::Chat::Server>, C<MyApp::Chat>, C<MyApp>) until the function
757exists or it runs out of package names.
758
759The init function is then called with the newly-created port as context
760object (C<$SELF>) and the C<@initdata> values as arguments. It I<must>
761call one of the C<rcv> functions to set callbacks on C<$SELF>, otherwise
762the port might not get created.
763
764A common idiom is to pass a local port, immediately monitor the spawned
765port, and in the remote init function, immediately monitor the passed
766local port. This two-way monitoring ensures that both ports get cleaned up
767when there is a problem.
768
769C<spawn> guarantees that the C<$initfunc> has no visible effects on the
770caller before C<spawn> returns (by delaying invocation when spawn is
771called for the local node).
772
773Example: spawn a chat server port on C<$othernode>.
774
775 # this node, executed from within a port context:
776 my $server = spawn $othernode, "MyApp::Chat::Server::connect", $SELF;
777 mon $server;
778
779 # init function on C<$othernode>
780 sub connect {
781 my ($srcport) = @_;
782
783 mon $srcport;
784
785 rcv $SELF, sub {
786 ...
787 };
788 }
789
790=cut
791
792sub _spawn {
793 my $port = shift;
794 my $init = shift;
795
796 # rcv will create the actual port
797 local $SELF = "$NODE#$port";
798 eval {
799 &{ load_func $init }
323 }; 800 };
801 _self_die if $@;
802}
803
804sub spawn(@) {
805 my ($nodeid, undef) = split /#/, shift, 2;
806
807 my $id = $RUNIQ . ++$ID;
808
809 $_[0] =~ /::/
810 or Carp::croak "spawn init function must be a fully-qualified name, caught";
811
812 snd_to_func $nodeid, "AnyEvent::MP::_spawn" => $id, @_;
813
814 "$nodeid#$id"
815}
816
817
818=item after $timeout, @msg
819
820=item after $timeout, $callback
821
822Either sends the given message, or call the given callback, after the
823specified number of seconds.
824
825This is simply a utility function that comes in handy at times - the
826AnyEvent::MP author is not convinced of the wisdom of having it, though,
827so it may go away in the future.
324 828
325=cut 829=cut
326 830
327sub port(;&) { 831sub after($@) {
328 my $id = "$UNIQ." . $ID++; 832 my ($timeout, @action) = @_;
329 my $port = "$NODE#$id";
330 833
331 if (@_) { 834 my $t; $t = AE::timer $timeout, 0, sub {
332 my $cb = shift; 835 undef $t;
333 $PORT{$id} = sub { 836 ref $action[0]
334 local $SELF = $port; 837 ? $action[0]()
335 eval { 838 : snd @action;
336 &$cb 839 };
337 and kil $id; 840}
338 }; 841
339 _self_die if $@; 842#=item $cb2 = timeout $seconds, $cb[, @args]
843
844=item cal $port, @msg, $callback[, $timeout]
845
846A simple form of RPC - sends a message to the given C<$port> with the
847given contents (C<@msg>), but adds a reply port to the message.
848
849The reply port is created temporarily just for the purpose of receiving
850the reply, and will be C<kil>ed when no longer needed.
851
852A reply message sent to the port is passed to the C<$callback> as-is.
853
854If an optional time-out (in seconds) is given and it is not C<undef>,
855then the callback will be called without any arguments after the time-out
856elapsed and the port is C<kil>ed.
857
858If no time-out is given (or it is C<undef>), then the local port will
859monitor the remote port instead, so it eventually gets cleaned-up.
860
861Currently this function returns the temporary port, but this "feature"
862might go in future versions unless you can make a convincing case that
863this is indeed useful for something.
864
865=cut
866
867sub cal(@) {
868 my $timeout = ref $_[-1] ? undef : pop;
869 my $cb = pop;
870
871 my $port = port {
872 undef $timeout;
873 kil $SELF;
874 &$cb;
875 };
876
877 if (defined $timeout) {
878 $timeout = AE::timer $timeout, 0, sub {
879 undef $timeout;
880 kil $port;
881 $cb->();
340 }; 882 };
341 } else { 883 } else {
342 my $self = bless { 884 mon $_[0], sub {
343 id => "$NODE#$id", 885 kil $port;
344 }, "AnyEvent::MP::Port"; 886 $cb->();
345
346 $PORT_DATA{$id} = $self;
347 $PORT{$id} = sub {
348 local $SELF = $port;
349
350 eval {
351 for (@{ $self->{rc0}{$_[0]} }) {
352 $_ && &{$_->[0]}
353 && undef $_;
354 }
355
356 for (@{ $self->{rcv}{$_[0]} }) {
357 $_ && [@_[1 .. @{$_->[1]}]] ~~ $_->[1]
358 && &{$_->[0]}
359 && undef $_;
360 }
361
362 for (@{ $self->{any} }) {
363 $_ && [@_[0 .. $#{$_->[1]}]] ~~ $_->[1]
364 && &{$_->[0]}
365 && undef $_;
366 }
367 };
368 _self_die if $@;
369 }; 887 };
370 } 888 }
371 889
890 push @_, $port;
891 &snd;
892
372 $port 893 $port
373} 894}
374 895
375=item reg $portid, $name 896=back
376 897
377Registers the given port under the name C<$name>. If the name already 898=head1 DISTRIBUTED DATABASE
378exists it is replaced.
379 899
380A port can only be registered under one well known name. 900AnyEvent::MP comes with a simple distributed database. The database will
901be mirrored asynchronously on all global nodes. Other nodes bind to one
902of the global nodes for their needs. Every node has a "local database"
903which contains all the values that are set locally. All local databases
904are merged together to form the global database, which can be queried.
381 905
382A port automatically becomes unregistered when it is killed. 906The database structure is that of a two-level hash - the database hash
907contains hashes which contain values, similarly to a perl hash of hashes,
908i.e.:
909
910 $DATABASE{$family}{$subkey} = $value
911
912The top level hash key is called "family", and the second-level hash key
913is called "subkey" or simply "key".
914
915The family must be alphanumeric, i.e. start with a letter and consist
916of letters, digits, underscores and colons (C<[A-Za-z][A-Za-z0-9_:]*>,
917pretty much like Perl module names.
918
919As the family namespace is global, it is recommended to prefix family names
920with the name of the application or module using it.
921
922The subkeys must be non-empty strings, with no further restrictions.
923
924The values should preferably be strings, but other perl scalars should
925work as well (such as C<undef>, arrays and hashes).
926
927Every database entry is owned by one node - adding the same family/subkey
928combination on multiple nodes will not cause discomfort for AnyEvent::MP,
929but the result might be nondeterministic, i.e. the key might have
930different values on different nodes.
931
932Different subkeys in the same family can be owned by different nodes
933without problems, and in fact, this is the common method to create worker
934pools. For example, a worker port for image scaling might do this:
935
936 db_set my_image_scalers => $port;
937
938And clients looking for an image scaler will want to get the
939C<my_image_scalers> keys from time to time:
940
941 db_keys my_image_scalers => sub {
942 @ports = @{ $_[0] };
943 };
944
945Or better yet, they want to monitor the database family, so they always
946have a reasonable up-to-date copy:
947
948 db_mon my_image_scalers => sub {
949 @ports = keys %{ $_[0] };
950 };
951
952In general, you can set or delete single subkeys, but query and monitor
953whole families only.
954
955If you feel the need to monitor or query a single subkey, try giving it
956it's own family.
957
958=over
959
960=item $guard = db_set $family => $subkey [=> $value]
961
962Sets (or replaces) a key to the database - if C<$value> is omitted,
963C<undef> is used instead.
964
965When called in non-void context, C<db_set> returns a guard that
966automatically calls C<db_del> when it is destroyed.
967
968=item db_del $family => $subkey...
969
970Deletes one or more subkeys from the database family.
971
972=item $guard = db_reg $family => $port => $value
973
974=item $guard = db_reg $family => $port
975
976=item $guard = db_reg $family
977
978Registers a port in the given family and optionally returns a guard to
979remove it.
980
981This function basically does the same as:
982
983 db_set $family => $port => $value
984
985Except that the port is monitored and automatically removed from the
986database family when it is kil'ed.
987
988If C<$value> is missing, C<undef> is used. If C<$port> is missing, then
989C<$SELF> is used.
990
991This function is most useful to register a port in some port group (which
992is just another name for a database family), and have it removed when the
993port is gone. This works best when the port is a local port.
383 994
384=cut 995=cut
385 996
386sub reg(@) { 997sub db_reg($$;$) {
387 my ($portid, $name) = @_; 998 my $family = shift;
999 my $port = @_ ? shift : $SELF;
388 1000
389 $REG{$name} = $portid; 1001 my $clr = sub { db_del $family => $port };
1002 mon $port, $clr;
1003
1004 db_set $family => $port => $_[0];
1005
1006 defined wantarray
1007 and &Guard::guard ($clr)
390} 1008}
391 1009
392=item rcv $portid, tagstring => $callback->(@msg), ... 1010=item db_family $family => $cb->(\%familyhash)
393 1011
394=item rcv $portid, $smartmatch => $callback->(@msg), ... 1012Queries the named database C<$family> and call the callback with the
1013family represented as a hash. You can keep and freely modify the hash.
395 1014
396=item rcv $portid, [$smartmatch...] => $callback->(@msg), ... 1015=item db_keys $family => $cb->(\@keys)
397 1016
398Register callbacks to be called on matching messages on the given port. 1017Same as C<db_family>, except it only queries the family I<subkeys> and passes
1018them as array reference to the callback.
399 1019
400The callback has to return a true value when its work is done, after 1020=item db_values $family => $cb->(\@values)
401which is will be removed, or a false value in which case it will stay
402registered.
403 1021
404The global C<$SELF> (exported by this module) contains C<$portid> while 1022Same as C<db_family>, except it only queries the family I<values> and passes them
405executing the callback. 1023as array reference to the callback.
406 1024
407Runtime errors wdurign callback execution will result in the port being 1025=item $guard = db_mon $family => $cb->($familyhash, \@added, \@changed, \@deleted)
408C<kil>ed.
409 1026
410If the match is an array reference, then it will be matched against the 1027Creates a monitor on the given database family. Each time a key is set
411first elements of the message, otherwise only the first element is being 1028or or is deleted the callback is called with a hash containing the
412matched. 1029database family and three lists of added, changed and deleted subkeys,
1030respectively. If no keys have changed then the array reference might be
1031C<undef> or even missing.
413 1032
414Any element in the match that is specified as C<_any_> (a function 1033If not called in void context, a guard object is returned that, when
415exported by this module) matches any single element of the message. 1034destroyed, stops the monitor.
416 1035
417While not required, it is highly recommended that the first matching 1036The family hash reference and the key arrays belong to AnyEvent::MP and
418element is a string identifying the message. The one-string-only match is 1037B<must not be modified or stored> by the callback. When in doubt, make a
419also the most efficient match (by far). 1038copy.
1039
1040As soon as possible after the monitoring starts, the callback will be
1041called with the intiial contents of the family, even if it is empty,
1042i.e. there will always be a timely call to the callback with the current
1043contents.
1044
1045It is possible that the callback is called with a change event even though
1046the subkey is already present and the value has not changed.
1047
1048The monitoring stops when the guard object is destroyed.
1049
1050Example: on every change to the family "mygroup", print out all keys.
1051
1052 my $guard = db_mon mygroup => sub {
1053 my ($family, $a, $c, $d) = @_;
1054 print "mygroup members: ", (join " ", keys %$family), "\n";
1055 };
1056
1057Exmaple: wait until the family "My::Module::workers" is non-empty.
1058
1059 my $guard; $guard = db_mon My::Module::workers => sub {
1060 my ($family, $a, $c, $d) = @_;
1061 return unless %$family;
1062 undef $guard;
1063 print "My::Module::workers now nonempty\n";
1064 };
1065
1066Example: print all changes to the family "AnyRvent::Fantasy::Module".
1067
1068 my $guard = db_mon AnyRvent::Fantasy::Module => sub {
1069 my ($family, $a, $c, $d) = @_;
1070
1071 print "+$_=$family->{$_}\n" for @$a;
1072 print "*$_=$family->{$_}\n" for @$c;
1073 print "-$_=$family->{$_}\n" for @$d;
1074 };
420 1075
421=cut 1076=cut
422 1077
423sub rcv($@) {
424 my ($noderef, $port) = split /#/, shift, 2;
425
426 ($NODE{$noderef} || add_node $noderef) == $NODE{""}
427 or Carp::croak "$noderef#$port: rcv can only be called on local ports, caught";
428
429 my $self = $PORT_DATA{$port}
430 or Carp::croak "$noderef#$port: rcv can only be called on message matching ports, caught";
431
432 "AnyEvent::MP::Port" eq ref $self
433 or Carp::croak "$noderef#$port: rcv can only be called on message matching ports, caught";
434
435 while (@_) {
436 my ($match, $cb) = splice @_, 0, 2;
437
438 if (!ref $match) {
439 push @{ $self->{rc0}{$match} }, [$cb];
440 } elsif (("ARRAY" eq ref $match && !ref $match->[0])) {
441 my ($type, @match) = @$match;
442 @match
443 ? push @{ $self->{rcv}{$match->[0]} }, [$cb, \@match]
444 : push @{ $self->{rc0}{$match->[0]} }, [$cb];
445 } else {
446 push @{ $self->{any} }, [$cb, $match];
447 }
448 }
449}
450
451=item $closure = psub { BLOCK }
452
453Remembers C<$SELF> and creates a closure out of the BLOCK. When the
454closure is executed, sets up the environment in the same way as in C<rcv>
455callbacks, i.e. runtime errors will cause the port to get C<kil>ed.
456
457This is useful when you register callbacks from C<rcv> callbacks:
458
459 rcv delayed_reply => sub {
460 my ($delay, @reply) = @_;
461 my $timer = AE::timer $delay, 0, psub {
462 snd @reply, $SELF;
463 };
464 };
465
466=cut
467
468sub psub(&) {
469 my $cb = shift;
470
471 my $port = $SELF
472 or Carp::croak "psub can only be called from within rcv or psub callbacks, not";
473
474 sub {
475 local $SELF = $port;
476
477 if (wantarray) {
478 my @res = eval { &$cb };
479 _self_die if $@;
480 @res
481 } else {
482 my $res = eval { &$cb };
483 _self_die if $@;
484 $res
485 }
486 }
487}
488
489=back 1078=back
490 1079
491=head1 FUNCTIONS FOR NODES
492
493=over 4
494
495=item become_public $noderef
496
497Tells the node to become a public node, i.e. reachable from other nodes.
498
499The first argument is the (unresolved) node reference of the local node
500(if missing then the empty string is used).
501
502It is quite common to not specify anything, in which case the local node
503tries to listen on the default port, or to only specify a port number, in
504which case AnyEvent::MP tries to guess the local addresses.
505
506=cut
507
508=back
509
510=head1 NODE MESSAGES
511
512Nodes understand the following messages sent to them. Many of them take
513arguments called C<@reply>, which will simply be used to compose a reply
514message - C<$reply[0]> is the port to reply to, C<$reply[1]> the type and
515the remaining arguments are simply the message data.
516
517While other messages exist, they are not public and subject to change.
518
519=over 4
520
521=cut
522
523=item lookup => $name, @reply
524
525Replies with the port ID of the specified well-known port, or C<undef>.
526
527=item devnull => ...
528
529Generic data sink/CPU heat conversion.
530
531=item relay => $port, @msg
532
533Simply forwards the message to the given port.
534
535=item eval => $string[ @reply]
536
537Evaluates the given string. If C<@reply> is given, then a message of the
538form C<@reply, $@, @evalres> is sent.
539
540Example: crash another node.
541
542 snd $othernode, eval => "exit";
543
544=item time => @reply
545
546Replies the the current node time to C<@reply>.
547
548Example: tell the current node to send the current time to C<$myport> in a
549C<timereply> message.
550
551 snd $NODE, time => $myport, timereply => 1, 2;
552 # => snd $myport, timereply => 1, 2, <time>
553
554=back
555
556=head1 AnyEvent::MP vs. Distributed Erlang 1080=head1 AnyEvent::MP vs. Distributed Erlang
557 1081
558AnyEvent::MP got lots of its ideas from distributed erlang (erlang node 1082AnyEvent::MP got lots of its ideas from distributed Erlang (Erlang node
559== aemp node, erlang process == aemp port), so many of the documents and 1083== aemp node, Erlang process == aemp port), so many of the documents and
560programming techniques employed by erlang apply to AnyEvent::MP. Here is a 1084programming techniques employed by Erlang apply to AnyEvent::MP. Here is a
561sample: 1085sample:
562 1086
563 http://www.erlang.se/doc/programming_rules.shtml 1087 http://www.erlang.se/doc/programming_rules.shtml
564 http://erlang.org/doc/getting_started/part_frame.html # chapters 3 and 4 1088 http://erlang.org/doc/getting_started/part_frame.html # chapters 3 and 4
565 http://erlang.org/download/erlang-book-part1.pdf # chapters 5 and 6 1089 http://erlang.org/download/erlang-book-part1.pdf # chapters 5 and 6
567 1091
568Despite the similarities, there are also some important differences: 1092Despite the similarities, there are also some important differences:
569 1093
570=over 4 1094=over 4
571 1095
572=item * Node references contain the recipe on how to contact them. 1096=item * Node IDs are arbitrary strings in AEMP.
573 1097
574Erlang relies on special naming and DNS to work everywhere in the 1098Erlang relies on special naming and DNS to work everywhere in the same
575same way. AEMP relies on each node knowing it's own address(es), with 1099way. AEMP relies on each node somehow knowing its own address(es) (e.g. by
576convenience functionality. 1100configuration or DNS), and possibly the addresses of some seed nodes, but
1101will otherwise discover other nodes (and their IDs) itself.
577 1102
578This means that AEMP requires a less tightly controlled environment at the 1103=item * Erlang has a "remote ports are like local ports" philosophy, AEMP
579cost of longer node references and a slightly higher management overhead. 1104uses "local ports are like remote ports".
1105
1106The failure modes for local ports are quite different (runtime errors
1107only) then for remote ports - when a local port dies, you I<know> it dies,
1108when a connection to another node dies, you know nothing about the other
1109port.
1110
1111Erlang pretends remote ports are as reliable as local ports, even when
1112they are not.
1113
1114AEMP encourages a "treat remote ports differently" philosophy, with local
1115ports being the special case/exception, where transport errors cannot
1116occur.
580 1117
581=item * Erlang uses processes and a mailbox, AEMP does not queue. 1118=item * Erlang uses processes and a mailbox, AEMP does not queue.
582 1119
583Erlang uses processes that selctively receive messages, and therefore 1120Erlang uses processes that selectively receive messages out of order, and
584needs a queue. AEMP is event based, queuing messages would serve no useful 1121therefore needs a queue. AEMP is event based, queuing messages would serve
585purpose. 1122no useful purpose. For the same reason the pattern-matching abilities
1123of AnyEvent::MP are more limited, as there is little need to be able to
1124filter messages without dequeuing them.
586 1125
587(But see L<Coro::MP> for a more erlang-like process model on top of AEMP). 1126This is not a philosophical difference, but simply stems from AnyEvent::MP
1127being event-based, while Erlang is process-based.
1128
1129You cna have a look at L<Coro::MP> for a more Erlang-like process model on
1130top of AEMP and Coro threads.
588 1131
589=item * Erlang sends are synchronous, AEMP sends are asynchronous. 1132=item * Erlang sends are synchronous, AEMP sends are asynchronous.
590 1133
591Sending messages in erlang is synchronous and blocks the process. AEMP 1134Sending messages in Erlang is synchronous and blocks the process until
592sends are immediate, connection establishment is handled in the 1135a conenction has been established and the message sent (and so does not
593background. 1136need a queue that can overflow). AEMP sends return immediately, connection
1137establishment is handled in the background.
594 1138
595=item * Erlang can silently lose messages, AEMP cannot. 1139=item * Erlang suffers from silent message loss, AEMP does not.
596 1140
597Erlang makes few guarantees on messages delivery - messages can get lost 1141Erlang implements few guarantees on messages delivery - messages can get
598without any of the processes realising it (i.e. you send messages a, b, 1142lost without any of the processes realising it (i.e. you send messages a,
599and c, and the other side only receives messages a and c). 1143b, and c, and the other side only receives messages a and c).
600 1144
601AEMP guarantees correct ordering, and the guarantee that there are no 1145AEMP guarantees (modulo hardware errors) correct ordering, and the
1146guarantee that after one message is lost, all following ones sent to the
1147same port are lost as well, until monitoring raises an error, so there are
602holes in the message sequence. 1148no silent "holes" in the message sequence.
603 1149
604=item * In erlang, processes can be declared dead and later be found to be 1150If you want your software to be very reliable, you have to cope with
605alive. 1151corrupted and even out-of-order messages in both Erlang and AEMP. AEMP
606 1152simply tries to work better in common error cases, such as when a network
607In erlang it can happen that a monitored process is declared dead and 1153link goes down.
608linked processes get killed, but later it turns out that the process is
609still alive - and can receive messages.
610
611In AEMP, when port monitoring detects a port as dead, then that port will
612eventually be killed - it cannot happen that a node detects a port as dead
613and then later sends messages to it, finding it is still alive.
614 1154
615=item * Erlang can send messages to the wrong port, AEMP does not. 1155=item * Erlang can send messages to the wrong port, AEMP does not.
616 1156
617In erlang it is quite possible that a node that restarts reuses a process 1157In Erlang it is quite likely that a node that restarts reuses an Erlang
618ID known to other nodes for a completely different process, causing 1158process ID known to other nodes for a completely different process,
619messages destined for that process to end up in an unrelated process. 1159causing messages destined for that process to end up in an unrelated
1160process.
620 1161
621AEMP never reuses port IDs, so old messages or old port IDs floating 1162AEMP does not reuse port IDs, so old messages or old port IDs floating
622around in the network will not be sent to an unrelated port. 1163around in the network will not be sent to an unrelated port.
623 1164
624=item * Erlang uses unprotected connections, AEMP uses secure 1165=item * Erlang uses unprotected connections, AEMP uses secure
625authentication and can use TLS. 1166authentication and can use TLS.
626 1167
627AEMP can use a proven protocol - SSL/TLS - to protect connections and 1168AEMP can use a proven protocol - TLS - to protect connections and
628securely authenticate nodes. 1169securely authenticate nodes.
629 1170
630=item * The AEMP protocol is optimised for both text-based and binary 1171=item * The AEMP protocol is optimised for both text-based and binary
631communications. 1172communications.
632 1173
633The AEMP protocol, unlike the erlang protocol, supports both 1174The AEMP protocol, unlike the Erlang protocol, supports both programming
634language-independent text-only protocols (good for debugging) and binary, 1175language independent text-only protocols (good for debugging), and binary,
635language-specific serialisers (e.g. Storable). 1176language-specific serialisers (e.g. Storable). By default, unless TLS is
1177used, the protocol is actually completely text-based.
636 1178
637It has also been carefully designed to be implementable in other languages 1179It has also been carefully designed to be implementable in other languages
638with a minimum of work while gracefully degrading fucntionality to make the 1180with a minimum of work while gracefully degrading functionality to make the
639protocol simple. 1181protocol simple.
640 1182
1183=item * AEMP has more flexible monitoring options than Erlang.
1184
1185In Erlang, you can chose to receive I<all> exit signals as messages or
1186I<none>, there is no in-between, so monitoring single Erlang processes is
1187difficult to implement.
1188
1189Monitoring in AEMP is more flexible than in Erlang, as one can choose
1190between automatic kill, exit message or callback on a per-port basis.
1191
1192=item * Erlang tries to hide remote/local connections, AEMP does not.
1193
1194Monitoring in Erlang is not an indicator of process death/crashes, in the
1195same way as linking is (except linking is unreliable in Erlang).
1196
1197In AEMP, you don't "look up" registered port names or send to named ports
1198that might or might not be persistent. Instead, you normally spawn a port
1199on the remote node. The init function monitors you, and you monitor the
1200remote port. Since both monitors are local to the node, they are much more
1201reliable (no need for C<spawn_link>).
1202
1203This also saves round-trips and avoids sending messages to the wrong port
1204(hard to do in Erlang).
1205
641=back 1206=back
642 1207
1208=head1 RATIONALE
1209
1210=over 4
1211
1212=item Why strings for port and node IDs, why not objects?
1213
1214We considered "objects", but found that the actual number of methods
1215that can be called are quite low. Since port and node IDs travel over
1216the network frequently, the serialising/deserialising would add lots of
1217overhead, as well as having to keep a proxy object everywhere.
1218
1219Strings can easily be printed, easily serialised etc. and need no special
1220procedures to be "valid".
1221
1222And as a result, a port with just a default receiver consists of a single
1223code reference stored in a global hash - it can't become much cheaper.
1224
1225=item Why favour JSON, why not a real serialising format such as Storable?
1226
1227In fact, any AnyEvent::MP node will happily accept Storable as framing
1228format, but currently there is no way to make a node use Storable by
1229default (although all nodes will accept it).
1230
1231The default framing protocol is JSON because a) JSON::XS is many times
1232faster for small messages and b) most importantly, after years of
1233experience we found that object serialisation is causing more problems
1234than it solves: Just like function calls, objects simply do not travel
1235easily over the network, mostly because they will always be a copy, so you
1236always have to re-think your design.
1237
1238Keeping your messages simple, concentrating on data structures rather than
1239objects, will keep your messages clean, tidy and efficient.
1240
1241=back
1242
1243=head1 PORTING FROM AnyEvent::MP VERSION 1.X
1244
1245AEMP version 2 has a few major incompatible changes compared to version 1:
1246
1247=over 4
1248
1249=item AnyEvent::MP::Global no longer has group management functions.
1250
1251At least not officially - the grp_* functions are still exported and might
1252work, but they will be removed in some later release.
1253
1254AnyEvent::MP now comes with a distributed database that is more
1255powerful. Its database families map closely to port groups, but the API
1256has changed (the functions are also now exported by AnyEvent::MP). Here is
1257a rough porting guide:
1258
1259 grp_reg $group, $port # old
1260 db_reg $group, $port # new
1261
1262 $list = grp_get $group # old
1263 db_keys $group, sub { my $list = shift } # new
1264
1265 grp_mon $group, $cb->(\@ports, $add, $del) # old
1266 db_mon $group, $cb->(\%ports, $add, $change, $del) # new
1267
1268C<grp_reg> is a no-brainer (just replace by C<db_reg>), but C<grp_get> is
1269no longer instant, because the local node might not have a copy of the
1270group. You can either modify your code to allow for a callback, or use
1271C<db_mon> to keep an updated copy of the group:
1272
1273 my $local_group_copy;
1274 db_mon $group => sub { $local_group_copy = $_[0] };
1275
1276 # now "keys %$local_group_copy" always returns the most up-to-date
1277 # list of ports in the group.
1278
1279C<grp_mon> can be replaced by C<db_mon> with minor changes - C<db_mon>
1280passes a hash as first argument, and an extra C<$chg> argument that can be
1281ignored:
1282
1283 db_mon $group => sub {
1284 my ($ports, $add, $chg, $lde) = @_;
1285 $ports = [keys %$ports];
1286
1287 # now $ports, $add and $del are the same as
1288 # were originally passed by grp_mon.
1289 ...
1290 };
1291
1292=item Nodes not longer connect to all other nodes.
1293
1294In AEMP 1.x, every node automatically loads the L<AnyEvent::MP::Global>
1295module, which in turn would create connections to all other nodes in the
1296network (helped by the seed nodes).
1297
1298In version 2.x, global nodes still connect to all other global nodes, but
1299other nodes don't - now every node either is a global node itself, or
1300attaches itself to another global node.
1301
1302If a node isn't a global node itself, then it attaches itself to one
1303of its seed nodes. If that seed node isn't a global node yet, it will
1304automatically be upgraded to a global node.
1305
1306So in many cases, nothing needs to be changed - one just has to make sure
1307that all seed nodes are meshed together with the other seed nodes (as with
1308AEMP 1.x), and other nodes specify them as seed nodes. This is most easily
1309achieved by specifying the same set of seed nodes for all nodes in the
1310network.
1311
1312Not opening a connection to every other node is usually an advantage,
1313except when you need the lower latency of an already established
1314connection. To ensure a node establishes a connection to another node,
1315you can monitor the node port (C<mon $node, ...>), which will attempt to
1316create the connection (and notify you when the connection fails).
1317
1318=item Listener-less nodes (nodes without binds) are gone.
1319
1320And are not coming back, at least not in their old form. If no C<binds>
1321are specified for a node, AnyEvent::MP assumes a default of C<*:*>.
1322
1323There are vague plans to implement some form of routing domains, which
1324might or might not bring back listener-less nodes, but don't count on it.
1325
1326The fact that most connections are now optional somewhat mitigates this,
1327as a node can be effectively unreachable from the outside without any
1328problems, as long as it isn't a global node and only reaches out to other
1329nodes (as opposed to being contacted from other nodes).
1330
1331=item $AnyEvent::MP::Kernel::WARN has gone.
1332
1333AnyEvent has acquired a logging framework (L<AnyEvent::Log>), and AEMP now
1334uses this, and so should your programs.
1335
1336Every module now documents what kinds of messages it generates, with
1337AnyEvent::MP acting as a catch all.
1338
1339On the positive side, this means that instead of setting
1340C<PERL_ANYEVENT_MP_WARNLEVEL>, you can get away by setting C<AE_VERBOSE> -
1341much less to type.
1342
1343=back
1344
1345=head1 LOGGING
1346
1347AnyEvent::MP does not normally log anything by itself, but sinc eit is the
1348root of the contetx hierarchy for AnyEvent::MP modules, it will receive
1349all log messages by submodules.
1350
643=head1 SEE ALSO 1351=head1 SEE ALSO
1352
1353L<AnyEvent::MP::Intro> - a gentle introduction.
1354
1355L<AnyEvent::MP::Kernel> - more, lower-level, stuff.
1356
1357L<AnyEvent::MP::Global> - network maintenance and port groups, to find
1358your applications.
1359
1360L<AnyEvent::MP::DataConn> - establish data connections between nodes.
1361
1362L<AnyEvent::MP::LogCatcher> - simple service to display log messages from
1363all nodes.
644 1364
645L<AnyEvent>. 1365L<AnyEvent>.
646 1366
647=head1 AUTHOR 1367=head1 AUTHOR
648 1368

Diff Legend

Removed lines
+ Added lines
< Changed lines
> Changed lines