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.114 by root, Thu Apr 22 16:06:19 2010 UTC vs.
Revision 1.125 by root, Sat Mar 3 13:07:19 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<#>)
86separator, and a port name (a printable string of unspecified format). 88as separator, and a port name (a printable string of unspecified
89format created by AnyEvent::MP).
87 90
88=item node 91=item node
89 92
90A node is a single process containing at least one port - the node port, 93A node is a single process containing at least one port - the node port,
91which enables nodes to manage each other remotely, and to create new 94which enables nodes to manage each other remotely, and to create new
92ports. 95ports.
93 96
94Nodes are either public (have one or more listening ports) or private 97Nodes are either public (have one or more listening ports) or private
95(no listening ports). Private nodes cannot talk to other private nodes 98(no listening ports). Private nodes cannot talk to other private nodes
96currently. 99currently, but all nodes can talk to public nodes.
97 100
101Nodes is represented by (printable) strings called "node IDs".
102
98=item node ID - C<[A-Z_][a-zA-Z0-9_\-.:]*> 103=item node ID - C<[A-Za-z0-9_\-.:]*>
99 104
100A node ID is a string that uniquely identifies the node within a 105A node ID is a string that uniquely identifies the node within a
101network. Depending on the configuration used, node IDs can look like a 106network. Depending on the configuration used, node IDs can look like a
102hostname, a hostname and a port, or a random string. AnyEvent::MP itself 107hostname, a hostname and a port, or a random string. AnyEvent::MP itself
103doesn't interpret node IDs in any way. 108doesn't interpret node IDs in any way except to uniquely identify a node.
104 109
105=item binds - C<ip:port> 110=item binds - C<ip:port>
106 111
107Nodes can only talk to each other by creating some kind of connection to 112Nodes 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 113each other. To do this, nodes should listen on one or more local transport
114endpoints - binds.
115
109endpoints - binds. Currently, only standard C<ip:port> specifications can 116Currently, only standard C<ip:port> specifications can be used, which
110be used, which specify TCP ports to listen on. 117specify TCP ports to listen on. So a bind is basically just a tcp socket
118in listening mode thta accepts conenctions form other nodes.
111 119
112=item seed nodes 120=item seed nodes
113 121
114When a node starts, it knows nothing about the network. To teach the node 122When 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 123needs to connect to at least one other node that is already in the
116network. This node is called a seed. 124network. These other nodes are called "seed nodes".
117 125
118Apart from the fact that other nodes know them as seed nodes and they have 126Seed nodes themselves are not special - they are seed nodes only because
119to have fixed listening addresses, seed nodes are perfectly normal nodes - 127some 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. 128node for other nodes, and eahc node cna use a different set of seed nodes.
121 129
122In addition to discovering the network, seed nodes are also used to 130In addition to discovering the network, seed nodes are also used to
123maintain the network and to connect nodes that otherwise would have 131maintain the network - all nodes using the same seed node form are part of
124trouble connecting. They form the backbone of an AnyEvent::MP network. 132the same network. If a network is split into multiple subnets because e.g.
133the network link between the parts goes down, then using the same seed
134nodes for all nodes ensures that eventually the subnets get merged again.
125 135
126Seed nodes are expected to be long-running, and at least one seed node 136Seed nodes are expected to be long-running, and at least one seed node
127should always be available. They should also be relatively responsive - a 137should always be available. They should also be relatively responsive - a
128seed node that blocks for long periods will slow down everybody else. 138seed node that blocks for long periods will slow down everybody else.
129 139
140For small networks, it's best if every node uses the same set of seed
141nodes. For large networks, it can be useful to specify "regional" seed
142nodes for most nodes in an area, and use all seed nodes as seed nodes for
143each other. What's important is that all seed nodes connections form a
144complete graph, so that the network cannot split into separate subnets
145forever.
146
147Seed nodes are represented by seed IDs.
148
130=item seeds - C<host:port> 149=item seed IDs - C<host:port>
131 150
132Seeds are transport endpoint(s) (usually a hostname/IP address and a 151Seed IDs are transport endpoint(s) (usually a hostname/IP address and a
133TCP port) of nodes that should be used as seed nodes. 152TCP port) of nodes that should be used as seed nodes.
134 153
135The nodes listening on those endpoints are expected to be long-running, 154=item global nodes
136and at least one of those should always be available. When nodes run out 155
137of connections (e.g. due to a network error), they try to re-establish 156An AEMP network needs a discovery service - nodes need to know how to
138connections to some seednodes again to join the network. 157connect to other nodes they only know by name. In addition, AEMP offers a
158distributed "group database", which maps group names to a list of strings
159- for example, to register worker ports.
160
161A network needs at least one global node to work, and allows every node to
162be a global node.
163
164Any node that loads the L<AnyEvent::MP::Global> module becomes a global
165node and tries to keep connections to all other nodes. So while it can
166make sense to make every node "global" in small networks, it usually makes
167sense to only make seed nodes into global nodes in large networks (nodes
168keep connections to seed nodes and global nodes, so makign them the same
169reduces overhead).
139 170
140=back 171=back
141 172
142=head1 VARIABLES/FUNCTIONS 173=head1 VARIABLES/FUNCTIONS
143 174
145 176
146=cut 177=cut
147 178
148package AnyEvent::MP; 179package AnyEvent::MP;
149 180
181use AnyEvent::MP::Config ();
150use AnyEvent::MP::Kernel; 182use AnyEvent::MP::Kernel;
183use AnyEvent::MP::Kernel qw(%NODE %PORT %PORT_DATA $UNIQ $RUNIQ $ID);
151 184
152use common::sense; 185use common::sense;
153 186
154use Carp (); 187use Carp ();
155 188
156use AE (); 189use AE ();
190use Guard ();
157 191
158use base "Exporter"; 192use base "Exporter";
159 193
160our $VERSION = 1.28; 194our $VERSION = $AnyEvent::MP::Config::VERSION;
161 195
162our @EXPORT = qw( 196our @EXPORT = qw(
163 NODE $NODE *SELF node_of after 197 NODE $NODE *SELF node_of after
164 configure 198 configure
165 snd rcv mon mon_guard kil psub peval spawn cal 199 snd rcv mon mon_guard kil psub peval spawn cal
166 port 200 port
201 db_set db_del db_reg
167); 202);
168 203
169our $SELF; 204our $SELF;
170 205
171sub _self_die() { 206sub _self_die() {
191Before a node can talk to other nodes on the network (i.e. enter 226Before 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 227"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 228to know is its own name, and optionally it should know the addresses of
194some other nodes in the network to discover other nodes. 229some other nodes in the network to discover other nodes.
195 230
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 231This function configures a node - it must be called exactly once (or
200never) before calling other AnyEvent::MP functions. 232never) before calling other AnyEvent::MP functions.
233
234The key/value pairs are basically the same ones as documented for the
235F<aemp> command line utility (sans the set/del prefix), with two additions:
236
237=over 4
238
239=item norc => $boolean (default false)
240
241If true, then the rc file (e.g. F<~/.perl-anyevent-mp>) will I<not>
242be consulted - all configuraiton options must be specified in the
243C<configure> call.
244
245=item force => $boolean (default false)
246
247IF true, then the values specified in the C<configure> will take
248precedence over any values configured via the rc file. The default is for
249the rc file to override any options specified in the program.
250
251=back
201 252
202=over 4 253=over 4
203 254
204=item step 1, gathering configuration from profiles 255=item step 1, gathering configuration from profiles
205 256
219That means that the values specified in the profile have highest priority 270That means that the values specified in the profile have highest priority
220and the values specified directly via C<configure> have lowest priority, 271and the values specified directly via C<configure> have lowest priority,
221and can only be used to specify defaults. 272and can only be used to specify defaults.
222 273
223If the profile specifies a node ID, then this will become the node ID of 274If the profile specifies a node ID, then this will become the node ID of
224this process. If not, then the profile name will be used as node ID. The 275this process. If not, then the profile name will be used as node ID, with
225special node ID of C<anon/> will be replaced by a random node ID. 276a slash (C</>) attached.
277
278If the node ID (or profile name) ends with a slash (C</>), then a random
279string is appended to make it unique.
226 280
227=item step 2, bind listener sockets 281=item step 2, bind listener sockets
228 282
229The next step is to look up the binds in the profile, followed by binding 283The next step is to look up the binds in the profile, followed by binding
230aemp protocol listeners on all binds specified (it is possible and valid 284aemp protocol listeners on all binds specified (it is possible and valid
236used, meaning the node will bind on a dynamically-assigned port on every 290used, meaning the node will bind on a dynamically-assigned port on every
237local IP address it finds. 291local IP address it finds.
238 292
239=item step 3, connect to seed nodes 293=item step 3, connect to seed nodes
240 294
241As the last step, the seeds list from the profile is passed to the 295As 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 296L<AnyEvent::MP::Global> module, which will then use it to keep
243connectivity with at least one node at any point in time. 297connectivity with at least one node at any point in time.
244 298
245=back 299=back
246 300
252Example: become an anonymous node. This form is often used for commandline 306Example: become an anonymous node. This form is often used for commandline
253clients. 307clients.
254 308
255 configure nodeid => "anon/"; 309 configure nodeid => "anon/";
256 310
257Example: configure a node using a profile called seed, which si suitable 311Example: 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, 312for a seed node as it binds on all local addresses on a fixed port (4040,
259customary for aemp). 313customary for aemp).
260 314
261 # use the aemp commandline utility 315 # use the aemp commandline utility
262 # aemp profile seed nodeid anon/ binds '*:4040' 316 # aemp profile seed binds '*:4040'
263 317
264 # then use it 318 # then use it
265 configure profile => "seed"; 319 configure profile => "seed";
266 320
267 # or simply use aemp from the shell again: 321 # or simply use aemp from the shell again:
337sub _kilme { 391sub _kilme {
338 die "received message on port without callback"; 392 die "received message on port without callback";
339} 393}
340 394
341sub port(;&) { 395sub port(;&) {
342 my $id = "$UNIQ." . $ID++; 396 my $id = $UNIQ . ++$ID;
343 my $port = "$NODE#$id"; 397 my $port = "$NODE#$id";
344 398
345 rcv $port, shift || \&_kilme; 399 rcv $port, shift || \&_kilme;
346 400
347 $port 401 $port
620 } 674 }
621 675
622 $node->monitor ($port, $cb); 676 $node->monitor ($port, $cb);
623 677
624 defined wantarray 678 defined wantarray
625 and ($cb += 0, AnyEvent::Util::guard { $node->unmonitor ($port, $cb) }) 679 and ($cb += 0, Guard::guard { $node->unmonitor ($port, $cb) })
626} 680}
627 681
628=item $guard = mon_guard $port, $ref, $ref... 682=item $guard = mon_guard $port, $ref, $ref...
629 683
630Monitors the given C<$port> and keeps the passed references. When the port 684Monitors the given C<$port> and keeps the passed references. When the port
734} 788}
735 789
736sub spawn(@) { 790sub spawn(@) {
737 my ($nodeid, undef) = split /#/, shift, 2; 791 my ($nodeid, undef) = split /#/, shift, 2;
738 792
739 my $id = "$RUNIQ." . $ID++; 793 my $id = $RUNIQ . ++$ID;
740 794
741 $_[0] =~ /::/ 795 $_[0] =~ /::/
742 or Carp::croak "spawn init function must be a fully-qualified name, caught"; 796 or Carp::croak "spawn init function must be a fully-qualified name, caught";
743 797
744 snd_to_func $nodeid, "AnyEvent::MP::_spawn" => $id, @_; 798 snd_to_func $nodeid, "AnyEvent::MP::_spawn" => $id, @_;
745 799
746 "$nodeid#$id" 800 "$nodeid#$id"
747} 801}
802
748 803
749=item after $timeout, @msg 804=item after $timeout, @msg
750 805
751=item after $timeout, $callback 806=item after $timeout, $callback
752 807
822 $port 877 $port
823} 878}
824 879
825=back 880=back
826 881
882=head1 DISTRIBUTED DATABASE
883
884AnyEvent::MP comes with a simple distributed database. The database will
885be mirrored asynchronously at all global nodes. Other nodes bind to one of
886the global nodes for their needs.
887
888The database consists of a two-level hash - a hash contains a hash which
889contains values.
890
891The top level hash key is called "family", and the second-level hash key
892is simply called "key".
893
894The family must be alphanumeric, i.e. start with a letter and consist
895of letters, digits, underscores and colons (C<[A-Za-z][A-Za-z0-9_:]*>,
896pretty much like Perl module names.
897
898As the family namespace is global, it is recommended to prefix family names
899with the name of the application or module using it.
900
901The keys must be strings, with no other limitations.
902
903The values should preferably be strings, but other perl scalars should
904work as well (such as undef, arrays and hashes).
905
906Every database entry is owned by one node - adding the same family/key
907combination on multiple nodes will not cause discomfort for AnyEvent::MP,
908but the result might be nondeterministic, i.e. the key might have
909different values on different nodes.
910
911=item db_set $family => $key => $value
912
913Sets (or replaces) a key to the database.
914
915=item db_del $family => $key
916
917Deletes a key from the database.
918
919=item $guard = db_reg $family => $key [=> $value]
920
921Sets the key on the database and returns a guard. When the guard is
922destroyed, the key is deleted from the database. If C<$value> is missing,
923then C<undef> is used.
924
925=cut
926
927=back
928
827=head1 AnyEvent::MP vs. Distributed Erlang 929=head1 AnyEvent::MP vs. Distributed Erlang
828 930
829AnyEvent::MP got lots of its ideas from distributed Erlang (Erlang node 931AnyEvent::MP got lots of its ideas from distributed Erlang (Erlang node
830== aemp node, Erlang process == aemp port), so many of the documents and 932== aemp node, Erlang process == aemp port), so many of the documents and
831programming techniques employed by Erlang apply to AnyEvent::MP. Here is a 933programming techniques employed by Erlang apply to AnyEvent::MP. Here is a
862ports being the special case/exception, where transport errors cannot 964ports being the special case/exception, where transport errors cannot
863occur. 965occur.
864 966
865=item * Erlang uses processes and a mailbox, AEMP does not queue. 967=item * Erlang uses processes and a mailbox, AEMP does not queue.
866 968
867Erlang uses processes that selectively receive messages, and therefore 969Erlang uses processes that selectively receive messages out of order, and
868needs a queue. AEMP is event based, queuing messages would serve no 970therefore needs a queue. AEMP is event based, queuing messages would serve
869useful purpose. For the same reason the pattern-matching abilities of 971no useful purpose. For the same reason the pattern-matching abilities
870AnyEvent::MP are more limited, as there is little need to be able to 972of AnyEvent::MP are more limited, as there is little need to be able to
871filter messages without dequeuing them. 973filter messages without dequeuing them.
872 974
873(But see L<Coro::MP> for a more Erlang-like process model on top of AEMP). 975This is not a philosophical difference, but simply stems from AnyEvent::MP
976being event-based, while Erlang is process-based.
977
978You cna have a look at L<Coro::MP> for a more Erlang-like process model on
979top of AEMP and Coro threads.
874 980
875=item * Erlang sends are synchronous, AEMP sends are asynchronous. 981=item * Erlang sends are synchronous, AEMP sends are asynchronous.
876 982
877Sending messages in Erlang is synchronous and blocks the process (and 983Sending messages in Erlang is synchronous and blocks the process until
984a 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, 985need a queue that can overflow). AEMP sends return immediately, connection
879connection establishment is handled in the background. 986establishment is handled in the background.
880 987
881=item * Erlang suffers from silent message loss, AEMP does not. 988=item * Erlang suffers from silent message loss, AEMP does not.
882 989
883Erlang implements few guarantees on messages delivery - messages can get 990Erlang implements few guarantees on messages delivery - messages can get
884lost without any of the processes realising it (i.e. you send messages a, 991lost 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). 992b, and c, and the other side only receives messages a and c).
886 993
887AEMP guarantees correct ordering, and the guarantee that after one message 994AEMP guarantees (modulo hardware errors) correct ordering, and the
888is lost, all following ones sent to the same port are lost as well, until 995guarantee 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 996same port are lost as well, until monitoring raises an error, so there are
890sequence. 997no silent "holes" in the message sequence.
998
999If you want your software to be very reliable, you have to cope with
1000corrupted and even out-of-order messages in both Erlang and AEMP. AEMP
1001simply tries to work better in common error cases, such as when a network
1002link goes down.
891 1003
892=item * Erlang can send messages to the wrong port, AEMP does not. 1004=item * Erlang can send messages to the wrong port, AEMP does not.
893 1005
894In Erlang it is quite likely that a node that restarts reuses a process ID 1006In Erlang it is quite likely that a node that restarts reuses an Erlang
895known to other nodes for a completely different process, causing messages 1007process ID known to other nodes for a completely different process,
896destined for that process to end up in an unrelated process. 1008causing messages destined for that process to end up in an unrelated
1009process.
897 1010
898AEMP never reuses port IDs, so old messages or old port IDs floating 1011AEMP does not reuse port IDs, so old messages or old port IDs floating
899around in the network will not be sent to an unrelated port. 1012around in the network will not be sent to an unrelated port.
900 1013
901=item * Erlang uses unprotected connections, AEMP uses secure 1014=item * Erlang uses unprotected connections, AEMP uses secure
902authentication and can use TLS. 1015authentication and can use TLS.
903 1016
906 1019
907=item * The AEMP protocol is optimised for both text-based and binary 1020=item * The AEMP protocol is optimised for both text-based and binary
908communications. 1021communications.
909 1022
910The AEMP protocol, unlike the Erlang protocol, supports both programming 1023The AEMP protocol, unlike the Erlang protocol, supports both programming
911language independent text-only protocols (good for debugging) and binary, 1024language independent text-only protocols (good for debugging), and binary,
912language-specific serialisers (e.g. Storable). By default, unless TLS is 1025language-specific serialisers (e.g. Storable). By default, unless TLS is
913used, the protocol is actually completely text-based. 1026used, the protocol is actually completely text-based.
914 1027
915It has also been carefully designed to be implementable in other languages 1028It has also been carefully designed to be implementable in other languages
916with a minimum of work while gracefully degrading functionality to make the 1029with a minimum of work while gracefully degrading functionality to make the
917protocol simple. 1030protocol simple.
918 1031
919=item * AEMP has more flexible monitoring options than Erlang. 1032=item * AEMP has more flexible monitoring options than Erlang.
920 1033
921In Erlang, you can chose to receive I<all> exit signals as messages 1034In 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 1035I<none>, there is no in-between, so monitoring single Erlang processes is
923difficult to implement. Monitoring in AEMP is more flexible than in 1036difficult to implement.
924Erlang, as one can choose between automatic kill, exit message or callback 1037
925on a per-process basis. 1038Monitoring in AEMP is more flexible than in Erlang, as one can choose
1039between automatic kill, exit message or callback on a per-port basis.
926 1040
927=item * Erlang tries to hide remote/local connections, AEMP does not. 1041=item * Erlang tries to hide remote/local connections, AEMP does not.
928 1042
929Monitoring in Erlang is not an indicator of process death/crashes, in the 1043Monitoring in Erlang is not an indicator of process death/crashes, in the
930same way as linking is (except linking is unreliable in Erlang). 1044same way as linking is (except linking is unreliable in Erlang).
953 1067
954Strings can easily be printed, easily serialised etc. and need no special 1068Strings can easily be printed, easily serialised etc. and need no special
955procedures to be "valid". 1069procedures to be "valid".
956 1070
957And as a result, a port with just a default receiver consists of a single 1071And 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. 1072code reference stored in a global hash - it can't become much cheaper.
959 1073
960=item Why favour JSON, why not a real serialising format such as Storable? 1074=item Why favour JSON, why not a real serialising format such as Storable?
961 1075
962In fact, any AnyEvent::MP node will happily accept Storable as framing 1076In 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 1077format, but currently there is no way to make a node use Storable by

Diff Legend

Removed lines
+ Added lines
< Changed lines
> Changed lines