| … | |
… | |
| 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 conenctions form 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 form are part of |
| 137 | the same network. If a network is split into multiple subnets because e.g. |
137 | the same network. If a network is split into multiple subnets because e.g. |
| 138 | the network link between the parts goes down, then using the same seed |
138 | the network link between the parts goes down, then using the same seed |
| … | |
… | |
| 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 |
| … | |
… | |
| 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 |
| … | |
… | |
| 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 | |
