… | |
… | |
76 | |
76 | |
77 | =over 4 |
77 | =over 4 |
78 | |
78 | |
79 | =item port |
79 | =item port |
80 | |
80 | |
81 | Not to be confused with a TCP port, a "port" is something you can send |
81 | Not to be confused with TCP ports, a "port" is something you can send |
82 | messages to (with the C<snd> function). |
82 | messages to (with the C<snd> function). |
83 | |
83 | |
84 | Ports allow you to register C<rcv> handlers that can match all or just |
84 | Ports allow you to register C<rcv> handlers that can match all or just |
85 | some messages. Messages send to ports will not be queued, regardless of |
85 | some messages. Messages send to ports will not be queued, regardless of |
86 | anything was listening for them or not. |
86 | whether anything was listening for them or not. |
87 | |
87 | |
88 | Ports are represented by (printable) strings called "port IDs". |
88 | Ports are represented by (printable) strings called "port IDs". |
89 | |
89 | |
90 | =item port ID - C<nodeid#portname> |
90 | =item port ID - C<nodeid#portname> |
91 | |
91 | |
… | |
… | |
302 | this process. If not, then the profile name will be used as node ID, with |
302 | this process. If not, then the profile name will be used as node ID, with |
303 | a unique randoms tring (C</%u>) appended. |
303 | a unique randoms tring (C</%u>) appended. |
304 | |
304 | |
305 | The node ID can contain some C<%> sequences that are expanded: C<%n> |
305 | The node ID can contain some C<%> sequences that are expanded: C<%n> |
306 | is expanded to the local nodename, C<%u> is replaced by a random |
306 | is expanded to the local nodename, C<%u> is replaced by a random |
307 | strign to make the node unique. For example, the F<aemp> commandline |
307 | string to make the node unique. For example, the F<aemp> commandline |
308 | utility uses C<aemp/%n/%u> as nodename, which might expand to |
308 | utility uses C<aemp/%n/%u> as nodename, which might expand to |
309 | C<aemp/cerebro/ZQDGSIkRhEZQDGSIkRhE>. |
309 | C<aemp/cerebro/ZQDGSIkRhEZQDGSIkRhE>. |
310 | |
310 | |
311 | =item step 2, bind listener sockets |
311 | =item step 2, bind listener sockets |
312 | |
312 | |
… | |
… | |
650 | In the last form (message), a message of the form C<$rcvport, @msg, |
650 | In the last form (message), a message of the form C<$rcvport, @msg, |
651 | @reason> will be C<snd>. |
651 | @reason> will be C<snd>. |
652 | |
652 | |
653 | Monitoring-actions are one-shot: once messages are lost (and a monitoring |
653 | Monitoring-actions are one-shot: once messages are lost (and a monitoring |
654 | alert was raised), they are removed and will not trigger again, even if it |
654 | alert was raised), they are removed and will not trigger again, even if it |
655 | turns out that the port is still alive. |
655 | turns out that the port is still alive (but monitoring actions added after |
|
|
656 | that will again trigger). |
656 | |
657 | |
657 | As a rule of thumb, monitoring requests should always monitor a remote |
658 | As a rule of thumb, monitoring requests should always monitor a remote |
658 | port locally (using a local C<$rcvport> or a callback). The reason is that |
659 | port locally (using a local C<$rcvport> or a callback). The reason is that |
659 | kill messages might get lost, just like any other message. Another less |
660 | kill messages might get lost, just like any other message. Another less |
660 | obvious reason is that even monitoring requests can get lost (for example, |
661 | obvious reason is that even monitoring requests can get lost (for example, |
… | |
… | |
876 | #=item $cb2 = timeout $seconds, $cb[, @args] |
877 | #=item $cb2 = timeout $seconds, $cb[, @args] |
877 | |
878 | |
878 | =item cal $port, @msg, $callback[, $timeout] |
879 | =item cal $port, @msg, $callback[, $timeout] |
879 | |
880 | |
880 | A simple form of RPC - sends a message to the given C<$port> with the |
881 | A simple form of RPC - sends a message to the given C<$port> with the |
881 | given contents (C<@msg>), but adds a reply port to the message. |
882 | given contents (C<@msg>), but appends a reply port to the message. |
882 | |
883 | |
883 | The reply port is created temporarily just for the purpose of receiving |
884 | The reply port is created temporarily just for the purpose of receiving |
884 | the reply, and will be C<kil>ed when no longer needed. |
885 | the reply, and will be C<kil>ed when no longer needed. |
885 | |
886 | |
886 | A reply message sent to the port is passed to the C<$callback> as-is. |
887 | A reply message sent to the port is passed to the C<$callback> as-is. |
… | |
… | |
965 | |
966 | |
966 | Different subkeys in the same family can be owned by different nodes |
967 | Different subkeys in the same family can be owned by different nodes |
967 | without problems, and in fact, this is the common method to create worker |
968 | without problems, and in fact, this is the common method to create worker |
968 | pools. For example, a worker port for image scaling might do this: |
969 | pools. For example, a worker port for image scaling might do this: |
969 | |
970 | |
970 | db_set my_image_scalers => $port; |
971 | db_set my_image_scalers => $port; # value not used |
971 | |
972 | |
972 | And clients looking for an image scaler will want to get the |
973 | And clients looking for an image scaler will want to get the |
973 | C<my_image_scalers> keys from time to time: |
974 | C<my_image_scalers> keys from time to time: |
974 | |
975 | |
975 | db_keys my_image_scalers => sub { |
976 | db_keys my_image_scalers => sub { |