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

Diff Legend

Removed lines
+ Added lines
< Changed lines
> Changed lines