| … | |
… | |
| 118 | each other. To do this, nodes should listen on one or more local transport |
118 | each other. To do this, nodes should listen on one or more local transport |
| 119 | endpoints - binds. |
119 | endpoints - binds. |
| 120 | |
120 | |
| 121 | Currently, only standard C<ip:port> specifications can be used, which |
121 | Currently, only standard C<ip:port> specifications can be used, which |
| 122 | specify TCP ports to listen on. So a bind is basically just a tcp socket |
122 | specify TCP ports to listen on. So a bind is basically just a tcp socket |
| 123 | in listening mode thta accepts conenctions form other nodes. |
123 | in listening mode that accepts connections from other nodes. |
| 124 | |
124 | |
| 125 | =item seed nodes |
125 | =item seed nodes |
| 126 | |
126 | |
| 127 | When a node starts, it knows nothing about the network it is in - it |
127 | When a node starts, it knows nothing about the network it is in - it |
| 128 | needs to connect to at least one other node that is already in the |
128 | needs to connect to at least one other node that is already in the |
| 129 | network. These other nodes are called "seed nodes". |
129 | network. These other nodes are called "seed nodes". |
| 130 | |
130 | |
| 131 | Seed nodes themselves are not special - they are seed nodes only because |
131 | Seed nodes themselves are not special - they are seed nodes only because |
| 132 | some other node I<uses> them as such, but any node can be used as seed |
132 | some other node I<uses> them as such, but any node can be used as seed |
| 133 | node for other nodes, and eahc node cna use a different set of seed nodes. |
133 | node for other nodes, and eahc node can use a different set of seed nodes. |
| 134 | |
134 | |
| 135 | In addition to discovering the network, seed nodes are also used to |
135 | In addition to discovering the network, seed nodes are also used to |
| 136 | maintain the network - all nodes using the same seed node form are part of |
136 | maintain the network - all nodes using the same seed node are part of the |
| 137 | the same network. If a network is split into multiple subnets because e.g. |
137 | same network. If a network is split into multiple subnets because e.g. the |
| 138 | the network link between the parts goes down, then using the same seed |
138 | network link between the parts goes down, then using the same seed nodes |
| 139 | nodes for all nodes ensures that eventually the subnets get merged again. |
139 | for all nodes ensures that eventually the subnets get merged again. |
| 140 | |
140 | |
| 141 | Seed nodes are expected to be long-running, and at least one seed node |
141 | Seed nodes are expected to be long-running, and at least one seed node |
| 142 | should always be available. They should also be relatively responsive - a |
142 | should always be available. They should also be relatively responsive - a |
| 143 | seed node that blocks for long periods will slow down everybody else. |
143 | seed node that blocks for long periods will slow down everybody else. |
| 144 | |
144 | |
| … | |
… | |
| 168 | |
168 | |
| 169 | Any node that loads the L<AnyEvent::MP::Global> module becomes a global |
169 | Any node that loads the L<AnyEvent::MP::Global> module becomes a global |
| 170 | node and tries to keep connections to all other nodes. So while it can |
170 | node and tries to keep connections to all other nodes. So while it can |
| 171 | make sense to make every node "global" in small networks, it usually makes |
171 | make sense to make every node "global" in small networks, it usually makes |
| 172 | sense to only make seed nodes into global nodes in large networks (nodes |
172 | sense to only make seed nodes into global nodes in large networks (nodes |
| 173 | keep connections to seed nodes and global nodes, so makign them the same |
173 | keep connections to seed nodes and global nodes, so making them the same |
| 174 | reduces overhead). |
174 | reduces overhead). |
| 175 | |
175 | |
| 176 | =back |
176 | =back |
| 177 | |
177 | |
| 178 | =head1 VARIABLES/FUNCTIONS |
178 | =head1 VARIABLES/FUNCTIONS |
| … | |
… | |
| 265 | =over 4 |
265 | =over 4 |
| 266 | |
266 | |
| 267 | =item norc => $boolean (default false) |
267 | =item norc => $boolean (default false) |
| 268 | |
268 | |
| 269 | If true, then the rc file (e.g. F<~/.perl-anyevent-mp>) will I<not> |
269 | If true, then the rc file (e.g. F<~/.perl-anyevent-mp>) will I<not> |
| 270 | be consulted - all configuraiton options must be specified in the |
270 | be consulted - all configuration options must be specified in the |
| 271 | C<configure> call. |
271 | C<configure> call. |
| 272 | |
272 | |
| 273 | =item force => $boolean (default false) |
273 | =item force => $boolean (default false) |
| 274 | |
274 | |
| 275 | IF true, then the values specified in the C<configure> will take |
275 | IF true, then the values specified in the C<configure> will take |
| … | |
… | |
| 540 | } |
540 | } |
| 541 | |
541 | |
| 542 | =item peval $port, $coderef[, @args] |
542 | =item peval $port, $coderef[, @args] |
| 543 | |
543 | |
| 544 | Evaluates the given C<$codref> within the contetx of C<$port>, that is, |
544 | Evaluates the given C<$codref> within the contetx of C<$port>, that is, |
| 545 | when the code throews an exception the C<$port> will be killed. |
545 | when the code throws an exception the C<$port> will be killed. |
| 546 | |
546 | |
| 547 | Any remaining args will be passed to the callback. Any return values will |
547 | Any remaining args will be passed to the callback. Any return values will |
| 548 | be returned to the caller. |
548 | be returned to the caller. |
| 549 | |
549 | |
| 550 | This is useful when you temporarily want to execute code in the context of |
550 | This is useful when you temporarily want to execute code in the context of |
| … | |
… | |
| 1057 | Same as C<db_family>, except it only queries the family I<values> and passes them |
1057 | Same as C<db_family>, except it only queries the family I<values> and passes them |
| 1058 | as array reference to the callback. |
1058 | as array reference to the callback. |
| 1059 | |
1059 | |
| 1060 | =item $guard = db_mon $family => $cb->(\%familyhash, \@added, \@changed, \@deleted) |
1060 | =item $guard = db_mon $family => $cb->(\%familyhash, \@added, \@changed, \@deleted) |
| 1061 | |
1061 | |
| 1062 | Creates a monitor on the given database family. Each time a key is set |
1062 | Creates a monitor on the given database family. Each time a key is |
| 1063 | or or is deleted the callback is called with a hash containing the |
1063 | set or is deleted the callback is called with a hash containing the |
| 1064 | database family and three lists of added, changed and deleted subkeys, |
1064 | database family and three lists of added, changed and deleted subkeys, |
| 1065 | respectively. If no keys have changed then the array reference might be |
1065 | respectively. If no keys have changed then the array reference might be |
| 1066 | C<undef> or even missing. |
1066 | C<undef> or even missing. |
| 1067 | |
1067 | |
| 1068 | If not called in void context, a guard object is returned that, when |
1068 | If not called in void context, a guard object is returned that, when |
| … | |
… | |
| 1096 | return unless %$family; |
1096 | return unless %$family; |
| 1097 | undef $guard; |
1097 | undef $guard; |
| 1098 | print "My::Module::workers now nonempty\n"; |
1098 | print "My::Module::workers now nonempty\n"; |
| 1099 | }; |
1099 | }; |
| 1100 | |
1100 | |
| 1101 | Example: print all changes to the family "AnyRvent::Fantasy::Module". |
1101 | Example: print all changes to the family "AnyEvent::Fantasy::Module". |
| 1102 | |
1102 | |
| 1103 | my $guard = db_mon AnyRvent::Fantasy::Module => sub { |
1103 | my $guard = db_mon AnyEvent::Fantasy::Module => sub { |
| 1104 | my ($family, $a, $c, $d) = @_; |
1104 | my ($family, $a, $c, $d) = @_; |
| 1105 | |
1105 | |
| 1106 | print "+$_=$family->{$_}\n" for @$a; |
1106 | print "+$_=$family->{$_}\n" for @$a; |
| 1107 | print "*$_=$family->{$_}\n" for @$c; |
1107 | print "*$_=$family->{$_}\n" for @$c; |
| 1108 | print "-$_=$family->{$_}\n" for @$d; |
1108 | print "-$_=$family->{$_}\n" for @$d; |
| … | |
… | |
| 1159 | filter messages without dequeuing them. |
1159 | filter messages without dequeuing them. |
| 1160 | |
1160 | |
| 1161 | This is not a philosophical difference, but simply stems from AnyEvent::MP |
1161 | This is not a philosophical difference, but simply stems from AnyEvent::MP |
| 1162 | being event-based, while Erlang is process-based. |
1162 | being event-based, while Erlang is process-based. |
| 1163 | |
1163 | |
| 1164 | You cna have a look at L<Coro::MP> for a more Erlang-like process model on |
1164 | You can have a look at L<Coro::MP> for a more Erlang-like process model on |
| 1165 | top of AEMP and Coro threads. |
1165 | top of AEMP and Coro threads. |
| 1166 | |
1166 | |
| 1167 | =item * Erlang sends are synchronous, AEMP sends are asynchronous. |
1167 | =item * Erlang sends are synchronous, AEMP sends are asynchronous. |
| 1168 | |
1168 | |
| 1169 | Sending messages in Erlang is synchronous and blocks the process until |
1169 | Sending messages in Erlang is synchronous and blocks the process until |
| 1170 | a conenction has been established and the message sent (and so does not |
1170 | a connection has been established and the message sent (and so does not |
| 1171 | need a queue that can overflow). AEMP sends return immediately, connection |
1171 | need a queue that can overflow). AEMP sends return immediately, connection |
| 1172 | establishment is handled in the background. |
1172 | establishment is handled in the background. |
| 1173 | |
1173 | |
| 1174 | =item * Erlang suffers from silent message loss, AEMP does not. |
1174 | =item * Erlang suffers from silent message loss, AEMP does not. |
| 1175 | |
1175 | |
| … | |
… | |
| 1377 | |
1377 | |
| 1378 | =back |
1378 | =back |
| 1379 | |
1379 | |
| 1380 | =head1 LOGGING |
1380 | =head1 LOGGING |
| 1381 | |
1381 | |
| 1382 | AnyEvent::MP does not normally log anything by itself, but sinc eit is the |
1382 | AnyEvent::MP does not normally log anything by itself, but since it is the |
| 1383 | root of the contetx hierarchy for AnyEvent::MP modules, it will receive |
1383 | root of the contetx hierarchy for AnyEvent::MP modules, it will receive |
| 1384 | all log messages by submodules. |
1384 | all log messages by submodules. |
| 1385 | |
1385 | |
| 1386 | =head1 SEE ALSO |
1386 | =head1 SEE ALSO |
| 1387 | |
1387 | |
