… | |
… | |
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 | |