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.51 by root, Fri Aug 14 14:07:44 2009 UTC vs.
Revision 1.69 by root, Sun Aug 30 18:51:49 2009 UTC

11 NODE $port # returns the noderef of the port 11 NODE $port # returns the noderef of the port
12 12
13 $SELF # receiving/own port id in rcv callbacks 13 $SELF # receiving/own port id in rcv callbacks
14 14
15 # initialise the node so it can send/receive messages 15 # initialise the node so it can send/receive messages
16 initialise_node; # -OR- 16 initialise_node;
17 initialise_node "localhost:4040"; # -OR-
18 initialise_node "slave/", "localhost:4040"
19 17
20 # ports are message endpoints 18 # ports are message endpoints
21 19
22 # sending messages 20 # sending messages
23 snd $port, type => data...; 21 snd $port, type => data...;
24 snd $port, @msg; 22 snd $port, @msg;
25 snd @msg_with_first_element_being_a_port; 23 snd @msg_with_first_element_being_a_port;
26 24
27 # creating/using ports, the simple way 25 # creating/using ports, the simple way
28 my $somple_port = port { my @msg = @_; 0 }; 26 my $simple_port = port { my @msg = @_; 0 };
29 27
30 # creating/using ports, type matching 28 # creating/using ports, tagged message matching
31 my $port = port; 29 my $port = port;
32 rcv $port, ping => sub { snd $_[0], "pong"; 0 }; 30 rcv $port, ping => sub { snd $_[0], "pong"; 0 };
33 rcv $port, pong => sub { warn "pong received\n"; 0 }; 31 rcv $port, pong => sub { warn "pong received\n"; 0 };
34 32
35 # create a port on another node 33 # create a port on another node
42 40
43=head1 CURRENT STATUS 41=head1 CURRENT STATUS
44 42
45 AnyEvent::MP - stable API, should work 43 AnyEvent::MP - stable API, should work
46 AnyEvent::MP::Intro - outdated 44 AnyEvent::MP::Intro - outdated
47 AnyEvent::MP::Kernel - WIP
48 AnyEvent::MP::Transport - mostly stable 45 AnyEvent::MP::Kernel - mostly stable
46 AnyEvent::MP::Global - mostly stable
47 AnyEvent::MP::Node - mostly stable, but internal anyways
48 AnyEvent::MP::Transport - mostly stable, but internal anyways
49 49
50 stay tuned. 50 stay tuned.
51 51
52=head1 DESCRIPTION 52=head1 DESCRIPTION
53 53
54This module (-family) implements a simple message passing framework. 54This module (-family) implements a simple message passing framework.
55 55
56Despite its simplicity, you can securely message other processes running 56Despite its simplicity, you can securely message other processes running
57on the same or other hosts. 57on the same or other hosts, and you can supervise entities remotely.
58 58
59For an introduction to this module family, see the L<AnyEvent::MP::Intro> 59For an introduction to this module family, see the L<AnyEvent::MP::Intro>
60manual page. 60manual page and the examples under F<eg/>.
61 61
62At the moment, this module family is severly broken and underdocumented, 62At the moment, this module family is a bit underdocumented.
63so do not use. This was uploaded mainly to reserve the CPAN namespace -
64stay tuned!
65 63
66=head1 CONCEPTS 64=head1 CONCEPTS
67 65
68=over 4 66=over 4
69 67
70=item port 68=item port
71 69
72A port is something you can send messages to (with the C<snd> function). 70A port is something you can send messages to (with the C<snd> function).
73 71
74Some ports allow you to register C<rcv> handlers that can match specific 72Ports allow you to register C<rcv> handlers that can match all or just
75messages. All C<rcv> handlers will receive messages they match, messages 73some messages. Messages send to ports will not be queued, regardless of
76will not be queued. 74anything was listening for them or not.
77 75
78=item port id - C<noderef#portname> 76=item port ID - C<nodeid#portname>
79 77
80A port id is normaly the concatenation of a noderef, a hash-mark (C<#>) as 78A port ID is the concatenation of a node ID, a hash-mark (C<#>) as
81separator, and a port name (a printable string of unspecified format). An 79separator, and a port name (a printable string of unspecified format).
82exception is the the node port, whose ID is identical to its node
83reference.
84 80
85=item node 81=item node
86 82
87A node is a single process containing at least one port - the node 83A node is a single process containing at least one port - the node port,
88port. You can send messages to node ports to find existing ports or to 84which enables nodes to manage each other remotely, and to create new
89create new ports, among other things. 85ports.
90 86
91Nodes are either private (single-process only), slaves (connected to a 87Nodes are either public (have one or more listening ports) or private
92master node only) or public nodes (connectable from unrelated nodes). 88(no listening ports). Private nodes cannot talk to other private nodes
89currently.
93 90
94=item noderef - C<host:port,host:port...>, C<id@noderef>, C<id> 91=item node ID - C<[a-za-Z0-9_\-.:]+>
95 92
96A node reference is a string that either simply identifies the node (for 93A node ID is a string that uniquely identifies the node within a
97private and slave nodes), or contains a recipe on how to reach a given 94network. Depending on the configuration used, node IDs can look like a
98node (for public nodes). 95hostname, a hostname and a port, or a random string. AnyEvent::MP itself
96doesn't interpret node IDs in any way.
99 97
100This recipe is simply a comma-separated list of C<address:port> pairs (for 98=item binds - C<ip:port>
101TCP/IP, other protocols might look different).
102 99
103Node references come in two flavours: resolved (containing only numerical 100Nodes can only talk to each other by creating some kind of connection to
104addresses) or unresolved (where hostnames are used instead of addresses). 101each other. To do this, nodes should listen on one or more local transport
102endpoints - binds. Currently, only standard C<ip:port> specifications can
103be used, which specify TCP ports to listen on.
105 104
106Before using an unresolved node reference in a message you first have to 105=item seeds - C<host:port>
107resolve it. 106
107When a node starts, it knows nothing about the network. To teach the node
108about the network it first has to contact some other node within the
109network. This node is called a seed.
110
111Seeds are transport endpoint(s) of as many nodes as one wants. Those nodes
112are expected to be long-running, and at least one of those should always
113be available. When nodes run out of connections (e.g. due to a network
114error), they try to re-establish connections to some seednodes again to
115join the network.
116
117Apart from being sued for seeding, seednodes are not special in any way -
118every public node can be a seednode.
108 119
109=back 120=back
110 121
111=head1 VARIABLES/FUNCTIONS 122=head1 VARIABLES/FUNCTIONS
112 123
127use base "Exporter"; 138use base "Exporter";
128 139
129our $VERSION = $AnyEvent::MP::Kernel::VERSION; 140our $VERSION = $AnyEvent::MP::Kernel::VERSION;
130 141
131our @EXPORT = qw( 142our @EXPORT = qw(
132 NODE $NODE *SELF node_of _any_ 143 NODE $NODE *SELF node_of after
133 resolve_node initialise_node 144 initialise_node
134 snd rcv mon kil reg psub spawn 145 snd rcv mon mon_guard kil reg psub spawn
135 port 146 port
136); 147);
137 148
138our $SELF; 149our $SELF;
139 150
143 kil $SELF, die => $msg; 154 kil $SELF, die => $msg;
144} 155}
145 156
146=item $thisnode = NODE / $NODE 157=item $thisnode = NODE / $NODE
147 158
148The C<NODE> function returns, and the C<$NODE> variable contains 159The C<NODE> function returns, and the C<$NODE> variable contains, the node
149the noderef of the local node. The value is initialised by a call 160ID of the node running in the current process. This value is initialised by
150to C<become_public> or C<become_slave>, after which all local port 161a call to C<initialise_node>.
151identifiers become invalid.
152 162
153=item $noderef = node_of $port 163=item $nodeid = node_of $port
154 164
155Extracts and returns the noderef from a portid or a noderef. 165Extracts and returns the node ID from a port ID or a node ID.
156 166
157=item initialise_node $noderef, $seednode, $seednode... 167=item initialise_node $profile_name, key => value...
158 168
159=item initialise_node "slave/", $master, $master...
160
161Before a node can talk to other nodes on the network it has to initialise 169Before a node can talk to other nodes on the network (i.e. enter
162itself - the minimum a node needs to know is it's own name, and optionally 170"distributed mode") it has to initialise itself - the minimum a node needs
163it should know the noderefs of some other nodes in the network. 171to know is its own name, and optionally it should know the addresses of
172some other nodes in the network to discover other nodes.
164 173
165This function initialises a node - it must be called exactly once (or 174This function initialises a node - it must be called exactly once (or
166never) before calling other AnyEvent::MP functions. 175never) before calling other AnyEvent::MP functions.
167 176
168All arguments (optionally except for the first) are noderefs, which can be 177The first argument is a profile name. If it is C<undef> or missing, then
169either resolved or unresolved. 178the current nodename will be used instead (i.e. F<uname -n>).
170 179
171The first argument will be looked up in the configuration database first 180The function first looks up the profile in the aemp configuration (see the
172(if it is C<undef> then the current nodename will be used instead) to find 181L<aemp> commandline utility). the profile is calculated as follows:
173the relevant configuration profile (see L<aemp>). If none is found then
174the default configuration is used. The configuration supplies additional
175seed/master nodes and can override the actual noderef.
176 182
177There are two types of networked nodes, public nodes and slave nodes: 183First, all remaining key => value pairs will be used. Then they will be
184overwritten by any values specified in the global default configuration
185(see the F<aemp> utility), then the chain of profiles selected, if
186any. That means that the values specified in the profile have highest
187priority and the values specified via C<initialise_node> have lowest
188priority.
178 189
179=over 4 190If the profile specifies a node ID, then this will become the node ID of
191this process. If not, then the profile name will be used as node ID. The
192special node ID of C<anon/> will be replaced by a random node ID.
180 193
181=item public nodes 194The next step is to look up the binds in the profile, followed by binding
195aemp protocol listeners on all binds specified (it is possible and valid
196to have no binds, meaning that the node cannot be contacted form the
197outside. This means the node cannot talk to other nodes that also have no
198binds, but it can still talk to all "normal" nodes).
182 199
183For public nodes, C<$noderef> (supplied either directly to 200If the profile does not specify a binds list, then the node ID will be
184C<initialise_node> or indirectly via a profile or the nodename) must be a 201treated as if it were of the form C<host:port>, which will be resolved and
185noderef (possibly unresolved, in which case it will be resolved). 202used as binds list.
186 203
187After resolving, the node will bind itself on all endpoints and try to 204Lastly, the seeds list from the profile is passed to the
188connect to all additional C<$seednodes> that are specified. Seednodes are 205L<AnyEvent::MP::Global> module, which will then use it to keep
189optional and can be used to quickly bootstrap the node into an existing 206connectivity with at least on of those seed nodes at any point in time.
190network.
191 207
192=item slave nodes
193
194When the C<$noderef> (either as given or overriden by the config file)
195is the special string C<slave/>, then the node will become a slave
196node. Slave nodes cannot be contacted from outside and will route most of
197their traffic to the master node that they attach to.
198
199At least one additional noderef is required (either by specifying it
200directly or because it is part of the configuration profile): The node
201will try to connect to all of them and will become a slave attached to the
202first node it can successfully connect to.
203
204=back
205
206This function will block until all nodes have been resolved and, for slave
207nodes, until it has successfully established a connection to a master
208server.
209
210Example: become a public node listening on the guessed noderef, or the one 208Example: become a distributed node listening on the guessed noderef, or
211specified via C<aemp> for the current node. This should be the most common 209the one specified via C<aemp> for the current node. This should be the
212form of invocation for "daemon"-type nodes. 210most common form of invocation for "daemon"-type nodes.
213 211
214 initialise_node; 212 initialise_node;
215 213
216Example: become a slave node to any of the the seednodes specified via 214Example: become an anonymous node. This form is often used for commandline
217C<aemp>. This form is often used for commandline clients. 215clients.
218 216
219 initialise_node "slave/"; 217 initialise_node "anon/";
220 218
221Example: become a slave node to any of the specified master servers. This 219Example: become a distributed node. If there is no profile of the given
222form is also often used for commandline clients. 220name, or no binds list was specified, resolve C<localhost:4044> and bind
223 221on the resulting addresses.
224 initialise_node "slave/", "master1", "192.168.13.17", "mp.example.net";
225
226Example: become a public node, and try to contact some well-known master
227servers to become part of the network.
228
229 initialise_node undef, "master1", "master2";
230
231Example: become a public node listening on port C<4041>.
232
233 initialise_node 4041;
234
235Example: become a public node, only visible on localhost port 4044.
236 222
237 initialise_node "localhost:4044"; 223 initialise_node "localhost:4044";
238
239=item $cv = resolve_node $noderef
240
241Takes an unresolved node reference that may contain hostnames and
242abbreviated IDs, resolves all of them and returns a resolved node
243reference.
244
245In addition to C<address:port> pairs allowed in resolved noderefs, the
246following forms are supported:
247
248=over 4
249
250=item the empty string
251
252An empty-string component gets resolved as if the default port (4040) was
253specified.
254
255=item naked port numbers (e.g. C<1234>)
256
257These are resolved by prepending the local nodename and a colon, to be
258further resolved.
259
260=item hostnames (e.g. C<localhost:1234>, C<localhost>)
261
262These are resolved by using AnyEvent::DNS to resolve them, optionally
263looking up SRV records for the C<aemp=4040> port, if no port was
264specified.
265
266=back
267 224
268=item $SELF 225=item $SELF
269 226
270Contains the current port id while executing C<rcv> callbacks or C<psub> 227Contains the current port id while executing C<rcv> callbacks or C<psub>
271blocks. 228blocks.
272 229
273=item SELF, %SELF, @SELF... 230=item *SELF, SELF, %SELF, @SELF...
274 231
275Due to some quirks in how perl exports variables, it is impossible to 232Due to some quirks in how perl exports variables, it is impossible to
276just export C<$SELF>, all the symbols called C<SELF> are exported by this 233just export C<$SELF>, all the symbols named C<SELF> are exported by this
277module, but only C<$SELF> is currently used. 234module, but only C<$SELF> is currently used.
278 235
279=item snd $port, type => @data 236=item snd $port, type => @data
280 237
281=item snd $port, @msg 238=item snd $port, @msg
282 239
283Send the given message to the given port ID, which can identify either 240Send the given message to the given port, which can identify either a
284a local or a remote port, and can be either a string or soemthignt hat 241local or a remote port, and must be a port ID.
285stringifies a sa port ID (such as a port object :).
286 242
287While the message can be about anything, it is highly recommended to use a 243While the message can be almost anything, it is highly recommended to
288string as first element (a portid, or some word that indicates a request 244use a string as first element (a port ID, or some word that indicates a
289type etc.). 245request type etc.) and to consist if only simple perl values (scalars,
246arrays, hashes) - if you think you need to pass an object, think again.
290 247
291The message data effectively becomes read-only after a call to this 248The message data logically becomes read-only after a call to this
292function: modifying any argument is not allowed and can cause many 249function: modifying any argument (or values referenced by them) is
293problems. 250forbidden, as there can be considerable time between the call to C<snd>
251and the time the message is actually being serialised - in fact, it might
252never be copied as within the same process it is simply handed to the
253receiving port.
294 254
295The type of data you can transfer depends on the transport protocol: when 255The type of data you can transfer depends on the transport protocol: when
296JSON is used, then only strings, numbers and arrays and hashes consisting 256JSON is used, then only strings, numbers and arrays and hashes consisting
297of those are allowed (no objects). When Storable is used, then anything 257of those are allowed (no objects). When Storable is used, then anything
298that Storable can serialise and deserialise is allowed, and for the local 258that Storable can serialise and deserialise is allowed, and for the local
299node, anything can be passed. 259node, anything can be passed. Best rely only on the common denominator of
260these.
300 261
301=item $local_port = port 262=item $local_port = port
302 263
303Create a new local port object and returns its port ID. Initially it has 264Create a new local port object and returns its port ID. Initially it has
304no callbacks set and will throw an error when it receives messages. 265no callbacks set and will throw an error when it receives messages.
351The default callback received all messages not matched by a more specific 312The default callback received all messages not matched by a more specific
352C<tag> match. 313C<tag> match.
353 314
354=item rcv $local_port, tag => $callback->(@msg_without_tag), ... 315=item rcv $local_port, tag => $callback->(@msg_without_tag), ...
355 316
356Register callbacks to be called on messages starting with the given tag on 317Register (or replace) callbacks to be called on messages starting with the
357the given port (and return the port), or unregister it (when C<$callback> 318given tag on the given port (and return the port), or unregister it (when
358is C<$undef>). 319C<$callback> is C<$undef> or missing). There can only be one callback
320registered for each tag.
359 321
360The original message will be passed to the callback, after the first 322The original message will be passed to the callback, after the first
361element (the tag) has been removed. The callback will use the same 323element (the tag) has been removed. The callback will use the same
362environment as the default callback (see above). 324environment as the default callback (see above).
363 325
375 rcv port, 337 rcv port,
376 msg1 => sub { ... }, 338 msg1 => sub { ... },
377 ... 339 ...
378 ; 340 ;
379 341
342Example: temporarily register a rcv callback for a tag matching some port
343(e.g. for a rpc reply) and unregister it after a message was received.
344
345 rcv $port, $otherport => sub {
346 my @reply = @_;
347
348 rcv $SELF, $otherport;
349 };
350
380=cut 351=cut
381 352
382sub rcv($@) { 353sub rcv($@) {
383 my $port = shift; 354 my $port = shift;
384 my ($noderef, $portid) = split /#/, $port, 2; 355 my ($noderef, $portid) = split /#/, $port, 2;
385 356
386 ($NODE{$noderef} || add_node $noderef) == $NODE{""} 357 $NODE{$noderef} == $NODE{""}
387 or Carp::croak "$port: rcv can only be called on local ports, caught"; 358 or Carp::croak "$port: rcv can only be called on local ports, caught";
388 359
389 while (@_) { 360 while (@_) {
390 if (ref $_[0]) { 361 if (ref $_[0]) {
391 if (my $self = $PORT_DATA{$portid}) { 362 if (my $self = $PORT_DATA{$portid}) {
470 $res 441 $res
471 } 442 }
472 } 443 }
473} 444}
474 445
475=item $guard = mon $port, $cb->(@reason) 446=item $guard = mon $port, $cb->(@reason) # call $cb when $port dies
476 447
477=item $guard = mon $port, $rcvport 448=item $guard = mon $port, $rcvport # kill $rcvport when $port dies
478 449
479=item $guard = mon $port 450=item $guard = mon $port # kill $SELF when $port dies
480 451
481=item $guard = mon $port, $rcvport, @msg 452=item $guard = mon $port, $rcvport, @msg # send a message when $port dies
482 453
483Monitor the given port and do something when the port is killed or 454Monitor the given port and do something when the port is killed or
484messages to it were lost, and optionally return a guard that can be used 455messages to it were lost, and optionally return a guard that can be used
485to stop monitoring again. 456to stop monitoring again.
486 457
487C<mon> effectively guarantees that, in the absence of hardware failures, 458C<mon> effectively guarantees that, in the absence of hardware failures,
488that after starting the monitor, either all messages sent to the port 459after starting the monitor, either all messages sent to the port will
489will arrive, or the monitoring action will be invoked after possible 460arrive, or the monitoring action will be invoked after possible message
490message loss has been detected. No messages will be lost "in between" 461loss has been detected. No messages will be lost "in between" (after
491(after the first lost message no further messages will be received by the 462the first lost message no further messages will be received by the
492port). After the monitoring action was invoked, further messages might get 463port). After the monitoring action was invoked, further messages might get
493delivered again. 464delivered again.
465
466Note that monitoring-actions are one-shot: once messages are lost (and a
467monitoring alert was raised), they are removed and will not trigger again.
494 468
495In the first form (callback), the callback is simply called with any 469In the first form (callback), the callback is simply called with any
496number of C<@reason> elements (no @reason means that the port was deleted 470number of C<@reason> elements (no @reason means that the port was deleted
497"normally"). Note also that I<< the callback B<must> never die >>, so use 471"normally"). Note also that I<< the callback B<must> never die >>, so use
498C<eval> if unsure. 472C<eval> if unsure.
560is killed, the references will be freed. 534is killed, the references will be freed.
561 535
562Optionally returns a guard that will stop the monitoring. 536Optionally returns a guard that will stop the monitoring.
563 537
564This function is useful when you create e.g. timers or other watchers and 538This function is useful when you create e.g. timers or other watchers and
565want to free them when the port gets killed: 539want to free them when the port gets killed (note the use of C<psub>):
566 540
567 $port->rcv (start => sub { 541 $port->rcv (start => sub {
568 my $timer; $timer = mon_guard $port, AE::timer 1, 1, sub { 542 my $timer; $timer = mon_guard $port, AE::timer 1, 1, psub {
569 undef $timer if 0.9 < rand; 543 undef $timer if 0.9 < rand;
570 }); 544 });
571 }); 545 });
572 546
573=cut 547=cut
582 556
583=item kil $port[, @reason] 557=item kil $port[, @reason]
584 558
585Kill the specified port with the given C<@reason>. 559Kill the specified port with the given C<@reason>.
586 560
587If no C<@reason> is specified, then the port is killed "normally" (linked 561If no C<@reason> is specified, then the port is killed "normally" (ports
588ports will not be kileld, or even notified). 562monitoring other ports will not necessarily die because a port dies
563"normally").
589 564
590Otherwise, linked ports get killed with the same reason (second form of 565Otherwise, linked ports get killed with the same reason (second form of
591C<mon>, see below). 566C<mon>, see above).
592 567
593Runtime errors while evaluating C<rcv> callbacks or inside C<psub> blocks 568Runtime errors while evaluating C<rcv> callbacks or inside C<psub> blocks
594will be reported as reason C<< die => $@ >>. 569will be reported as reason C<< die => $@ >>.
595 570
596Transport/communication errors are reported as C<< transport_error => 571Transport/communication errors are reported as C<< transport_error =>
601=item $port = spawn $node, $initfunc[, @initdata] 576=item $port = spawn $node, $initfunc[, @initdata]
602 577
603Creates a port on the node C<$node> (which can also be a port ID, in which 578Creates a port on the node C<$node> (which can also be a port ID, in which
604case it's the node where that port resides). 579case it's the node where that port resides).
605 580
606The port ID of the newly created port is return immediately, and it is 581The port ID of the newly created port is returned immediately, and it is
607permissible to immediately start sending messages or monitor the port. 582possible to immediately start sending messages or to monitor the port.
608 583
609After the port has been created, the init function is 584After the port has been created, the init function is called on the remote
610called. This function must be a fully-qualified function name 585node, in the same context as a C<rcv> callback. This function must be a
611(e.g. C<MyApp::Chat::Server::init>). To specify a function in the main 586fully-qualified function name (e.g. C<MyApp::Chat::Server::init>). To
612program, use C<::name>. 587specify a function in the main program, use C<::name>.
613 588
614If the function doesn't exist, then the node tries to C<require> 589If the function doesn't exist, then the node tries to C<require>
615the package, then the package above the package and so on (e.g. 590the package, then the package above the package and so on (e.g.
616C<MyApp::Chat::Server>, C<MyApp::Chat>, C<MyApp>) until the function 591C<MyApp::Chat::Server>, C<MyApp::Chat>, C<MyApp>) until the function
617exists or it runs out of package names. 592exists or it runs out of package names.
618 593
619The init function is then called with the newly-created port as context 594The init function is then called with the newly-created port as context
620object (C<$SELF>) and the C<@initdata> values as arguments. 595object (C<$SELF>) and the C<@initdata> values as arguments.
621 596
622A common idiom is to pass your own port, monitor the spawned port, and 597A common idiom is to pass a local port, immediately monitor the spawned
623in the init function, monitor the original port. This two-way monitoring 598port, and in the remote init function, immediately monitor the passed
624ensures that both ports get cleaned up when there is a problem. 599local port. This two-way monitoring ensures that both ports get cleaned up
600when there is a problem.
625 601
626Example: spawn a chat server port on C<$othernode>. 602Example: spawn a chat server port on C<$othernode>.
627 603
628 # this node, executed from within a port context: 604 # this node, executed from within a port context:
629 my $server = spawn $othernode, "MyApp::Chat::Server::connect", $SELF; 605 my $server = spawn $othernode, "MyApp::Chat::Server::connect", $SELF;
659 my $id = "$RUNIQ." . $ID++; 635 my $id = "$RUNIQ." . $ID++;
660 636
661 $_[0] =~ /::/ 637 $_[0] =~ /::/
662 or Carp::croak "spawn init function must be a fully-qualified name, caught"; 638 or Carp::croak "spawn init function must be a fully-qualified name, caught";
663 639
664 ($NODE{$noderef} || add_node $noderef) 640 snd_to_func $noderef, "AnyEvent::MP::_spawn" => $id, @_;
665 ->send (["", "AnyEvent::MP::_spawn" => $id, @_]);
666 641
667 "$noderef#$id" 642 "$noderef#$id"
668} 643}
669 644
670=back 645=item after $timeout, @msg
671 646
672=head1 NODE MESSAGES 647=item after $timeout, $callback
673 648
674Nodes understand the following messages sent to them. Many of them take 649Either sends the given message, or call the given callback, after the
675arguments called C<@reply>, which will simply be used to compose a reply 650specified number of seconds.
676message - C<$reply[0]> is the port to reply to, C<$reply[1]> the type and
677the remaining arguments are simply the message data.
678 651
679While other messages exist, they are not public and subject to change. 652This is simply a utility function that comes in handy at times - the
653AnyEvent::MP author is not convinced of the wisdom of having it, though,
654so it may go away in the future.
680 655
681=over 4
682
683=cut 656=cut
684 657
685=item lookup => $name, @reply 658sub after($@) {
659 my ($timeout, @action) = @_;
686 660
687Replies with the port ID of the specified well-known port, or C<undef>. 661 my $t; $t = AE::timer $timeout, 0, sub {
688 662 undef $t;
689=item devnull => ... 663 ref $action[0]
690 664 ? $action[0]()
691Generic data sink/CPU heat conversion. 665 : snd @action;
692 666 };
693=item relay => $port, @msg 667}
694
695Simply forwards the message to the given port.
696
697=item eval => $string[ @reply]
698
699Evaluates the given string. If C<@reply> is given, then a message of the
700form C<@reply, $@, @evalres> is sent.
701
702Example: crash another node.
703
704 snd $othernode, eval => "exit";
705
706=item time => @reply
707
708Replies the the current node time to C<@reply>.
709
710Example: tell the current node to send the current time to C<$myport> in a
711C<timereply> message.
712
713 snd $NODE, time => $myport, timereply => 1, 2;
714 # => snd $myport, timereply => 1, 2, <time>
715 668
716=back 669=back
717 670
718=head1 AnyEvent::MP vs. Distributed Erlang 671=head1 AnyEvent::MP vs. Distributed Erlang
719 672
729 682
730Despite the similarities, there are also some important differences: 683Despite the similarities, there are also some important differences:
731 684
732=over 4 685=over 4
733 686
734=item * Node references contain the recipe on how to contact them. 687=item * Node IDs are arbitrary strings in AEMP.
735 688
736Erlang relies on special naming and DNS to work everywhere in the 689Erlang relies on special naming and DNS to work everywhere in the same
737same way. AEMP relies on each node knowing it's own address(es), with 690way. AEMP relies on each node somehow knowing its own address(es) (e.g. by
738convenience functionality. 691configuraiton or DNS), but will otherwise discover other odes itself.
739 692
740This means that AEMP requires a less tightly controlled environment at the
741cost of longer node references and a slightly higher management overhead.
742
743=item Erlang has a "remote ports are like local ports" philosophy, AEMP 693=item * Erlang has a "remote ports are like local ports" philosophy, AEMP
744uses "local ports are like remote ports". 694uses "local ports are like remote ports".
745 695
746The failure modes for local ports are quite different (runtime errors 696The failure modes for local ports are quite different (runtime errors
747only) then for remote ports - when a local port dies, you I<know> it dies, 697only) then for remote ports - when a local port dies, you I<know> it dies,
748when a connection to another node dies, you know nothing about the other 698when a connection to another node dies, you know nothing about the other
775 725
776Erlang makes few guarantees on messages delivery - messages can get lost 726Erlang makes few guarantees on messages delivery - messages can get lost
777without any of the processes realising it (i.e. you send messages a, b, 727without any of the processes realising it (i.e. you send messages a, b,
778and c, and the other side only receives messages a and c). 728and c, and the other side only receives messages a and c).
779 729
780AEMP guarantees correct ordering, and the guarantee that there are no 730AEMP guarantees correct ordering, and the guarantee that after one message
781holes in the message sequence. 731is lost, all following ones sent to the same port are lost as well, until
782 732monitoring raises an error, so there are no silent "holes" in the message
783=item * In Erlang, processes can be declared dead and later be found to be 733sequence.
784alive.
785
786In Erlang it can happen that a monitored process is declared dead and
787linked processes get killed, but later it turns out that the process is
788still alive - and can receive messages.
789
790In AEMP, when port monitoring detects a port as dead, then that port will
791eventually be killed - it cannot happen that a node detects a port as dead
792and then later sends messages to it, finding it is still alive.
793 734
794=item * Erlang can send messages to the wrong port, AEMP does not. 735=item * Erlang can send messages to the wrong port, AEMP does not.
795 736
796In Erlang it is quite likely that a node that restarts reuses a process ID 737In Erlang it is quite likely that a node that restarts reuses a process ID
797known to other nodes for a completely different process, causing messages 738known to other nodes for a completely different process, causing messages
801around in the network will not be sent to an unrelated port. 742around in the network will not be sent to an unrelated port.
802 743
803=item * Erlang uses unprotected connections, AEMP uses secure 744=item * Erlang uses unprotected connections, AEMP uses secure
804authentication and can use TLS. 745authentication and can use TLS.
805 746
806AEMP can use a proven protocol - SSL/TLS - to protect connections and 747AEMP can use a proven protocol - TLS - to protect connections and
807securely authenticate nodes. 748securely authenticate nodes.
808 749
809=item * The AEMP protocol is optimised for both text-based and binary 750=item * The AEMP protocol is optimised for both text-based and binary
810communications. 751communications.
811 752
812The AEMP protocol, unlike the Erlang protocol, supports both 753The AEMP protocol, unlike the Erlang protocol, supports both programming
813language-independent text-only protocols (good for debugging) and binary, 754language independent text-only protocols (good for debugging) and binary,
814language-specific serialisers (e.g. Storable). 755language-specific serialisers (e.g. Storable). By default, unless TLS is
756used, the protocol is actually completely text-based.
815 757
816It has also been carefully designed to be implementable in other languages 758It has also been carefully designed to be implementable in other languages
817with a minimum of work while gracefully degrading fucntionality to make the 759with a minimum of work while gracefully degrading functionality to make the
818protocol simple. 760protocol simple.
819 761
820=item * AEMP has more flexible monitoring options than Erlang. 762=item * AEMP has more flexible monitoring options than Erlang.
821 763
822In Erlang, you can chose to receive I<all> exit signals as messages 764In Erlang, you can chose to receive I<all> exit signals as messages
825Erlang, as one can choose between automatic kill, exit message or callback 767Erlang, as one can choose between automatic kill, exit message or callback
826on a per-process basis. 768on a per-process basis.
827 769
828=item * Erlang tries to hide remote/local connections, AEMP does not. 770=item * Erlang tries to hide remote/local connections, AEMP does not.
829 771
830Monitoring in Erlang is not an indicator of process death/crashes, 772Monitoring in Erlang is not an indicator of process death/crashes, in the
831as linking is (except linking is unreliable in Erlang). 773same way as linking is (except linking is unreliable in Erlang).
832 774
833In AEMP, you don't "look up" registered port names or send to named ports 775In AEMP, you don't "look up" registered port names or send to named ports
834that might or might not be persistent. Instead, you normally spawn a port 776that might or might not be persistent. Instead, you normally spawn a port
835on the remote node. The init function monitors the you, and you monitor 777on the remote node. The init function monitors you, and you monitor the
836the remote port. Since both monitors are local to the node, they are much 778remote port. Since both monitors are local to the node, they are much more
837more reliable. 779reliable (no need for C<spawn_link>).
838 780
839This also saves round-trips and avoids sending messages to the wrong port 781This also saves round-trips and avoids sending messages to the wrong port
840(hard to do in Erlang). 782(hard to do in Erlang).
841 783
842=back 784=back
843 785
844=head1 RATIONALE 786=head1 RATIONALE
845 787
846=over 4 788=over 4
847 789
848=item Why strings for ports and noderefs, why not objects? 790=item Why strings for port and node IDs, why not objects?
849 791
850We considered "objects", but found that the actual number of methods 792We considered "objects", but found that the actual number of methods
851thatc an be called are very low. Since port IDs and noderefs travel over 793that can be called are quite low. Since port and node IDs travel over
852the network frequently, the serialising/deserialising would add lots of 794the network frequently, the serialising/deserialising would add lots of
853overhead, as well as having to keep a proxy object. 795overhead, as well as having to keep a proxy object everywhere.
854 796
855Strings can easily be printed, easily serialised etc. and need no special 797Strings can easily be printed, easily serialised etc. and need no special
856procedures to be "valid". 798procedures to be "valid".
857 799
858And a a miniport consists of a single closure stored in a global hash - it 800And as a result, a miniport consists of a single closure stored in a
859can't become much cheaper. 801global hash - it can't become much cheaper.
860 802
861=item Why favour JSON, why not real serialising format such as Storable? 803=item Why favour JSON, why not a real serialising format such as Storable?
862 804
863In fact, any AnyEvent::MP node will happily accept Storable as framing 805In fact, any AnyEvent::MP node will happily accept Storable as framing
864format, but currently there is no way to make a node use Storable by 806format, but currently there is no way to make a node use Storable by
865default. 807default (although all nodes will accept it).
866 808
867The default framing protocol is JSON because a) JSON::XS is many times 809The default framing protocol is JSON because a) JSON::XS is many times
868faster for small messages and b) most importantly, after years of 810faster for small messages and b) most importantly, after years of
869experience we found that object serialisation is causing more problems 811experience we found that object serialisation is causing more problems
870than it gains: Just like function calls, objects simply do not travel 812than it solves: Just like function calls, objects simply do not travel
871easily over the network, mostly because they will always be a copy, so you 813easily over the network, mostly because they will always be a copy, so you
872always have to re-think your design. 814always have to re-think your design.
873 815
874Keeping your messages simple, concentrating on data structures rather than 816Keeping your messages simple, concentrating on data structures rather than
875objects, will keep your messages clean, tidy and efficient. 817objects, will keep your messages clean, tidy and efficient.
876 818
877=back 819=back
878 820
879=head1 SEE ALSO 821=head1 SEE ALSO
880 822
823L<AnyEvent::MP::Intro> - a gentle introduction.
824
825L<AnyEvent::MP::Kernel> - more, lower-level, stuff.
826
827L<AnyEvent::MP::Global> - network maintainance and port groups, to find
828your applications.
829
881L<AnyEvent>. 830L<AnyEvent>.
882 831
883=head1 AUTHOR 832=head1 AUTHOR
884 833
885 Marc Lehmann <schmorp@schmorp.de> 834 Marc Lehmann <schmorp@schmorp.de>

Diff Legend

Removed lines
+ Added lines
< Changed lines
> Changed lines