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

Diff Legend

Removed lines
+ Added lines
< Changed lines
> Changed lines