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.111 by root, Sat Mar 20 20:12:18 2010 UTC vs.
Revision 1.121 by root, Tue Feb 28 18:37:24 2012 UTC

30 rcv $port, pong => sub { warn "pong received\n" }; 30 rcv $port, pong => sub { warn "pong received\n" };
31 31
32 # create a port on another node 32 # create a port on another node
33 my $port = spawn $node, $initfunc, @initdata; 33 my $port = spawn $node, $initfunc, @initdata;
34 34
35 # destroy a prot again 35 # destroy a port again
36 kil $port; # "normal" kill 36 kil $port; # "normal" kill
37 kil $port, my_error => "everything is broken"; # error kill 37 kil $port, my_error => "everything is broken"; # error kill
38 38
39 # monitoring 39 # monitoring
40 mon $localport, $cb->(@msg) # callback is invoked on death 40 mon $localport, $cb->(@msg) # callback is invoked on death
78 78
79Ports allow you to register C<rcv> handlers that can match all or just 79Ports allow you to register C<rcv> handlers that can match all or just
80some messages. Messages send to ports will not be queued, regardless of 80some messages. Messages send to ports will not be queued, regardless of
81anything was listening for them or not. 81anything was listening for them or not.
82 82
83Ports are represented by (printable) strings called "port IDs".
84
83=item port ID - C<nodeid#portname> 85=item port ID - C<nodeid#portname>
84 86
85A port ID is the concatenation of a node ID, a hash-mark (C<#>) as 87A port ID is the concatenation of a node ID, a hash-mark (C<#>) as
86separator, and a port name (a printable string of unspecified format). 88separator, and a port name (a printable string of unspecified format).
87 89
91which enables nodes to manage each other remotely, and to create new 93which enables nodes to manage each other remotely, and to create new
92ports. 94ports.
93 95
94Nodes are either public (have one or more listening ports) or private 96Nodes are either public (have one or more listening ports) or private
95(no listening ports). Private nodes cannot talk to other private nodes 97(no listening ports). Private nodes cannot talk to other private nodes
96currently. 98currently, but all nodes can talk to public nodes.
97 99
100Nodes is represented by (printable) strings called "node IDs".
101
98=item node ID - C<[A-Z_][a-zA-Z0-9_\-.:]*> 102=item node ID - C<[A-Za-z0-9_\-.:]*>
99 103
100A node ID is a string that uniquely identifies the node within a 104A node ID is a string that uniquely identifies the node within a
101network. Depending on the configuration used, node IDs can look like a 105network. Depending on the configuration used, node IDs can look like a
102hostname, a hostname and a port, or a random string. AnyEvent::MP itself 106hostname, a hostname and a port, or a random string. AnyEvent::MP itself
103doesn't interpret node IDs in any way. 107doesn't interpret node IDs in any way except to uniquely identify a node.
104 108
105=item binds - C<ip:port> 109=item binds - C<ip:port>
106 110
107Nodes can only talk to each other by creating some kind of connection to 111Nodes can only talk to each other by creating some kind of connection to
108each other. To do this, nodes should listen on one or more local transport 112each other. To do this, nodes should listen on one or more local transport
113endpoints - binds.
114
109endpoints - binds. Currently, only standard C<ip:port> specifications can 115Currently, only standard C<ip:port> specifications can be used, which
110be used, which specify TCP ports to listen on. 116specify TCP ports to listen on. So a bind is basically just a tcp socket
117in listening mode thta accepts conenctions form other nodes.
111 118
112=item seed nodes 119=item seed nodes
113 120
114When a node starts, it knows nothing about the network. To teach the node 121When a node starts, it knows nothing about the network it is in - it
115about the network it first has to contact some other node within the 122needs to connect to at least one other node that is already in the
116network. This node is called a seed. 123network. These other nodes are called "seed nodes".
117 124
118Apart from the fact that other nodes know them as seed nodes and they have 125Seed nodes themselves are not special - they are seed nodes only because
119to have fixed listening addresses, seed nodes are perfectly normal nodes - 126some other node I<uses> them as such, but any node can be used as seed
120any node can function as a seed node for others. 127node for other nodes, and eahc node cna use a different set of seed nodes.
121 128
122In addition to discovering the network, seed nodes are also used to 129In addition to discovering the network, seed nodes are also used to
123maintain the network and to connect nodes that otherwise would have 130maintain the network - all nodes using the same seed node form are part of
124trouble connecting. They form the backbone of an AnyEvent::MP network. 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.
125 134
126Seed nodes are expected to be long-running, and at least one seed node 135Seed nodes are expected to be long-running, and at least one seed node
127should always be available. They should also be relatively responsive - a 136should always be available. They should also be relatively responsive - a
128seed node that blocks for long periods will slow down everybody else. 137seed node that blocks for long periods will slow down everybody else.
129 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
130=item seeds - C<host:port> 148=item seed IDs - C<host:port>
131 149
132Seeds are transport endpoint(s) (usually a hostname/IP address and a 150Seed IDs are transport endpoint(s) (usually a hostname/IP address and a
133TCP port) of nodes that should be used as seed nodes. 151TCP port) of nodes that should be used as seed nodes.
134 152
135The nodes listening on those endpoints are expected to be long-running, 153=item global nodes
136and at least one of those should always be available. When nodes run out 154
137of connections (e.g. due to a network error), they try to re-establish 155An AEMP network needs a discovery service - nodes need to know how to
138connections to some seednodes again to join the network. 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).
139 169
140=back 170=back
141 171
142=head1 VARIABLES/FUNCTIONS 172=head1 VARIABLES/FUNCTIONS
143 173
145 175
146=cut 176=cut
147 177
148package AnyEvent::MP; 178package AnyEvent::MP;
149 179
180use AnyEvent::MP::Config ();
150use AnyEvent::MP::Kernel; 181use AnyEvent::MP::Kernel;
182use AnyEvent::MP::Kernel qw(%NODE %PORT %PORT_DATA $UNIQ $RUNIQ $ID);
151 183
152use common::sense; 184use common::sense;
153 185
154use Carp (); 186use Carp ();
155 187
156use AE (); 188use AE ();
157 189
158use base "Exporter"; 190use base "Exporter";
159 191
160our $VERSION = 1.27; 192our $VERSION = $AnyEvent::MP::Config::VERSION;
161 193
162our @EXPORT = qw( 194our @EXPORT = qw(
163 NODE $NODE *SELF node_of after 195 NODE $NODE *SELF node_of after
164 configure 196 configure
165 snd rcv mon mon_guard kil psub peval spawn cal 197 snd rcv mon mon_guard kil psub peval spawn cal
191Before a node can talk to other nodes on the network (i.e. enter 223Before a node can talk to other nodes on the network (i.e. enter
192"distributed mode") it has to configure itself - the minimum a node needs 224"distributed mode") it has to configure itself - the minimum a node needs
193to know is its own name, and optionally it should know the addresses of 225to know is its own name, and optionally it should know the addresses of
194some other nodes in the network to discover other nodes. 226some other nodes in the network to discover other nodes.
195 227
196The key/value pairs are basically the same ones as documented for the
197F<aemp> command line utility (sans the set/del prefix).
198
199This function configures a node - it must be called exactly once (or 228This function configures a node - it must be called exactly once (or
200never) before calling other AnyEvent::MP functions. 229never) before calling other AnyEvent::MP functions.
230
231The key/value pairs are basically the same ones as documented for the
232F<aemp> command line utility (sans the set/del prefix), with two additions:
233
234=over 4
235
236=item norc => $boolean (default false)
237
238If true, then the rc file (e.g. F<~/.perl-anyevent-mp>) will I<not>
239be consulted - all configuraiton options must be specified in the
240C<configure> call.
241
242=item force => $boolean (default false)
243
244IF true, then the values specified in the C<configure> will take
245precedence over any values configured via the rc file. The default is for
246the rc file to override any options specified in the program.
247
248=back
201 249
202=over 4 250=over 4
203 251
204=item step 1, gathering configuration from profiles 252=item step 1, gathering configuration from profiles
205 253
236used, meaning the node will bind on a dynamically-assigned port on every 284used, meaning the node will bind on a dynamically-assigned port on every
237local IP address it finds. 285local IP address it finds.
238 286
239=item step 3, connect to seed nodes 287=item step 3, connect to seed nodes
240 288
241As the last step, the seeds list from the profile is passed to the 289As the last step, the seed ID list from the profile is passed to the
242L<AnyEvent::MP::Global> module, which will then use it to keep 290L<AnyEvent::MP::Global> module, which will then use it to keep
243connectivity with at least one node at any point in time. 291connectivity with at least one node at any point in time.
244 292
245=back 293=back
246 294
252Example: become an anonymous node. This form is often used for commandline 300Example: become an anonymous node. This form is often used for commandline
253clients. 301clients.
254 302
255 configure nodeid => "anon/"; 303 configure nodeid => "anon/";
256 304
257Example: configure a node using a profile called seed, which si suitable 305Example: configure a node using a profile called seed, which is suitable
258for a seed node as it binds on all local addresses on a fixed port (4040, 306for a seed node as it binds on all local addresses on a fixed port (4040,
259customary for aemp). 307customary for aemp).
260 308
261 # use the aemp commandline utility 309 # use the aemp commandline utility
262 # aemp profile seed nodeid anon/ binds '*:4040' 310 # aemp profile seed nodeid anon/ binds '*:4040'
337sub _kilme { 385sub _kilme {
338 die "received message on port without callback"; 386 die "received message on port without callback";
339} 387}
340 388
341sub port(;&) { 389sub port(;&) {
342 my $id = "$UNIQ." . $ID++; 390 my $id = "$UNIQ." . ++$ID;
343 my $port = "$NODE#$id"; 391 my $port = "$NODE#$id";
344 392
345 rcv $port, shift || \&_kilme; 393 rcv $port, shift || \&_kilme;
346 394
347 $port 395 $port
495Remembers C<$SELF> and creates a closure out of the BLOCK. When the 543Remembers C<$SELF> and creates a closure out of the BLOCK. When the
496closure is executed, sets up the environment in the same way as in C<rcv> 544closure is executed, sets up the environment in the same way as in C<rcv>
497callbacks, i.e. runtime errors will cause the port to get C<kil>ed. 545callbacks, i.e. runtime errors will cause the port to get C<kil>ed.
498 546
499The effect is basically as if it returned C<< sub { peval $SELF, sub { 547The effect is basically as if it returned C<< sub { peval $SELF, sub {
500BLOCK } } >>. 548BLOCK }, @_ } >>.
501 549
502This is useful when you register callbacks from C<rcv> callbacks: 550This is useful when you register callbacks from C<rcv> callbacks:
503 551
504 rcv delayed_reply => sub { 552 rcv delayed_reply => sub {
505 my ($delay, @reply) = @_; 553 my ($delay, @reply) = @_;
734} 782}
735 783
736sub spawn(@) { 784sub spawn(@) {
737 my ($nodeid, undef) = split /#/, shift, 2; 785 my ($nodeid, undef) = split /#/, shift, 2;
738 786
739 my $id = "$RUNIQ." . $ID++; 787 my $id = "$RUNIQ." . ++$ID;
740 788
741 $_[0] =~ /::/ 789 $_[0] =~ /::/
742 or Carp::croak "spawn init function must be a fully-qualified name, caught"; 790 or Carp::croak "spawn init function must be a fully-qualified name, caught";
743 791
744 snd_to_func $nodeid, "AnyEvent::MP::_spawn" => $id, @_; 792 snd_to_func $nodeid, "AnyEvent::MP::_spawn" => $id, @_;
745 793
746 "$nodeid#$id" 794 "$nodeid#$id"
747} 795}
796
748 797
749=item after $timeout, @msg 798=item after $timeout, @msg
750 799
751=item after $timeout, $callback 800=item after $timeout, $callback
752 801
862ports being the special case/exception, where transport errors cannot 911ports being the special case/exception, where transport errors cannot
863occur. 912occur.
864 913
865=item * Erlang uses processes and a mailbox, AEMP does not queue. 914=item * Erlang uses processes and a mailbox, AEMP does not queue.
866 915
867Erlang uses processes that selectively receive messages, and therefore 916Erlang uses processes that selectively receive messages out of order, and
868needs a queue. AEMP is event based, queuing messages would serve no 917therefore needs a queue. AEMP is event based, queuing messages would serve
869useful purpose. For the same reason the pattern-matching abilities of 918no useful purpose. For the same reason the pattern-matching abilities
870AnyEvent::MP are more limited, as there is little need to be able to 919of AnyEvent::MP are more limited, as there is little need to be able to
871filter messages without dequeuing them. 920filter messages without dequeuing them.
872 921
873(But see L<Coro::MP> for a more Erlang-like process model on top of AEMP). 922This is not a philosophical difference, but simply stems from AnyEvent::MP
923being event-based, while Erlang is process-based.
924
925You cna have a look at L<Coro::MP> for a more Erlang-like process model on
926top of AEMP and Coro threads.
874 927
875=item * Erlang sends are synchronous, AEMP sends are asynchronous. 928=item * Erlang sends are synchronous, AEMP sends are asynchronous.
876 929
877Sending messages in Erlang is synchronous and blocks the process (and 930Sending messages in Erlang is synchronous and blocks the process until
931a conenction has been established and the message sent (and so does not
878so does not need a queue that can overflow). AEMP sends are immediate, 932need a queue that can overflow). AEMP sends return immediately, connection
879connection establishment is handled in the background. 933establishment is handled in the background.
880 934
881=item * Erlang suffers from silent message loss, AEMP does not. 935=item * Erlang suffers from silent message loss, AEMP does not.
882 936
883Erlang implements few guarantees on messages delivery - messages can get 937Erlang implements few guarantees on messages delivery - messages can get
884lost without any of the processes realising it (i.e. you send messages a, 938lost without any of the processes realising it (i.e. you send messages a,
885b, and c, and the other side only receives messages a and c). 939b, and c, and the other side only receives messages a and c).
886 940
887AEMP guarantees correct ordering, and the guarantee that after one message 941AEMP guarantees (modulo hardware errors) correct ordering, and the
888is lost, all following ones sent to the same port are lost as well, until 942guarantee that after one message is lost, all following ones sent to the
889monitoring raises an error, so there are no silent "holes" in the message 943same port are lost as well, until monitoring raises an error, so there are
890sequence. 944no silent "holes" in the message sequence.
945
946If you want your software to be very reliable, you have to cope with
947corrupted and even out-of-order messages in both Erlang and AEMP. AEMP
948simply tries to work better in common error cases, such as when a network
949link goes down.
891 950
892=item * Erlang can send messages to the wrong port, AEMP does not. 951=item * Erlang can send messages to the wrong port, AEMP does not.
893 952
894In Erlang it is quite likely that a node that restarts reuses a process ID 953In Erlang it is quite likely that a node that restarts reuses an Erlang
895known to other nodes for a completely different process, causing messages 954process ID known to other nodes for a completely different process,
896destined for that process to end up in an unrelated process. 955causing messages destined for that process to end up in an unrelated
956process.
897 957
898AEMP never reuses port IDs, so old messages or old port IDs floating 958AEMP does not reuse port IDs, so old messages or old port IDs floating
899around in the network will not be sent to an unrelated port. 959around in the network will not be sent to an unrelated port.
900 960
901=item * Erlang uses unprotected connections, AEMP uses secure 961=item * Erlang uses unprotected connections, AEMP uses secure
902authentication and can use TLS. 962authentication and can use TLS.
903 963
906 966
907=item * The AEMP protocol is optimised for both text-based and binary 967=item * The AEMP protocol is optimised for both text-based and binary
908communications. 968communications.
909 969
910The AEMP protocol, unlike the Erlang protocol, supports both programming 970The AEMP protocol, unlike the Erlang protocol, supports both programming
911language independent text-only protocols (good for debugging) and binary, 971language independent text-only protocols (good for debugging), and binary,
912language-specific serialisers (e.g. Storable). By default, unless TLS is 972language-specific serialisers (e.g. Storable). By default, unless TLS is
913used, the protocol is actually completely text-based. 973used, the protocol is actually completely text-based.
914 974
915It has also been carefully designed to be implementable in other languages 975It has also been carefully designed to be implementable in other languages
916with a minimum of work while gracefully degrading functionality to make the 976with a minimum of work while gracefully degrading functionality to make the
917protocol simple. 977protocol simple.
918 978
919=item * AEMP has more flexible monitoring options than Erlang. 979=item * AEMP has more flexible monitoring options than Erlang.
920 980
921In Erlang, you can chose to receive I<all> exit signals as messages 981In Erlang, you can chose to receive I<all> exit signals as messages or
922or I<none>, there is no in-between, so monitoring single processes is 982I<none>, there is no in-between, so monitoring single Erlang processes is
923difficult to implement. Monitoring in AEMP is more flexible than in 983difficult to implement.
924Erlang, as one can choose between automatic kill, exit message or callback 984
925on a per-process basis. 985Monitoring in AEMP is more flexible than in Erlang, as one can choose
986between automatic kill, exit message or callback on a per-port basis.
926 987
927=item * Erlang tries to hide remote/local connections, AEMP does not. 988=item * Erlang tries to hide remote/local connections, AEMP does not.
928 989
929Monitoring in Erlang is not an indicator of process death/crashes, in the 990Monitoring in Erlang is not an indicator of process death/crashes, in the
930same way as linking is (except linking is unreliable in Erlang). 991same way as linking is (except linking is unreliable in Erlang).
953 1014
954Strings can easily be printed, easily serialised etc. and need no special 1015Strings can easily be printed, easily serialised etc. and need no special
955procedures to be "valid". 1016procedures to be "valid".
956 1017
957And as a result, a port with just a default receiver consists of a single 1018And as a result, a port with just a default receiver consists of a single
958closure stored in a global hash - it can't become much cheaper. 1019code reference stored in a global hash - it can't become much cheaper.
959 1020
960=item Why favour JSON, why not a real serialising format such as Storable? 1021=item Why favour JSON, why not a real serialising format such as Storable?
961 1022
962In fact, any AnyEvent::MP node will happily accept Storable as framing 1023In fact, any AnyEvent::MP node will happily accept Storable as framing
963format, but currently there is no way to make a node use Storable by 1024format, but currently there is no way to make a node use Storable by
979 1040
980L<AnyEvent::MP::Intro> - a gentle introduction. 1041L<AnyEvent::MP::Intro> - a gentle introduction.
981 1042
982L<AnyEvent::MP::Kernel> - more, lower-level, stuff. 1043L<AnyEvent::MP::Kernel> - more, lower-level, stuff.
983 1044
984L<AnyEvent::MP::Global> - network maintainance and port groups, to find 1045L<AnyEvent::MP::Global> - network maintenance and port groups, to find
985your applications. 1046your applications.
986 1047
987L<AnyEvent::MP::DataConn> - establish data connections between nodes. 1048L<AnyEvent::MP::DataConn> - establish data connections between nodes.
988 1049
989L<AnyEvent::MP::LogCatcher> - simple service to display log messages from 1050L<AnyEvent::MP::LogCatcher> - simple service to display log messages from

Diff Legend

Removed lines
+ Added lines
< Changed lines
> Changed lines