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

Diff Legend

Removed lines
+ Added lines
< Changed lines
> Changed lines