| … | |
… | |
| 88 | |
88 | |
| 89 | use AE (); |
89 | use AE (); |
| 90 | |
90 | |
| 91 | use base "Exporter"; |
91 | use base "Exporter"; |
| 92 | |
92 | |
| 93 | our $VERSION = '0.02'; |
93 | our $VERSION = '0.1'; |
| 94 | our @EXPORT = qw( |
94 | our @EXPORT = qw( |
| 95 | NODE $NODE *SELF node_of _any_ |
95 | NODE $NODE *SELF node_of _any_ |
| 96 | become_slave become_public |
96 | become_slave become_public |
| 97 | snd rcv mon kil reg psub |
97 | snd rcv mon kil reg psub |
| 98 | port |
98 | port |
| … | |
… | |
| 244 | sub mon_guard { |
244 | sub mon_guard { |
| 245 | my ($port, @refs) = @_; |
245 | my ($port, @refs) = @_; |
| 246 | |
246 | |
| 247 | mon $port, sub { 0 && @refs } |
247 | mon $port, sub { 0 && @refs } |
| 248 | } |
248 | } |
|
|
249 | |
|
|
250 | =item lnk $port1, $port2 |
|
|
251 | |
|
|
252 | Link two ports. This is simply a shorthand for: |
|
|
253 | |
|
|
254 | mon $port1, $port2; |
|
|
255 | mon $port2, $port1; |
|
|
256 | |
|
|
257 | It means that if either one is killed abnormally, the other one gets |
|
|
258 | killed as well. |
| 249 | |
259 | |
| 250 | =item $local_port = port |
260 | =item $local_port = port |
| 251 | |
261 | |
| 252 | Create a new local port object that supports message matching. |
262 | Create a new local port object that supports message matching. |
| 253 | |
263 | |
| … | |
… | |
| 498 | snd $NODE, time => $myport, timereply => 1, 2; |
508 | snd $NODE, time => $myport, timereply => 1, 2; |
| 499 | # => snd $myport, timereply => 1, 2, <time> |
509 | # => snd $myport, timereply => 1, 2, <time> |
| 500 | |
510 | |
| 501 | =back |
511 | =back |
| 502 | |
512 | |
|
|
513 | =head1 AnyEvent::MP vs. Distributed Erlang |
|
|
514 | |
|
|
515 | AnyEvent::MP got lots of its ideas from distributed erlang. Despite the |
|
|
516 | similarities (erlang node == aemp node, erlang process == aemp port and so |
|
|
517 | on), there are also some important differences: |
|
|
518 | |
|
|
519 | =over 4 |
|
|
520 | |
|
|
521 | =item * Node references contain the recipe on how to contact them. |
|
|
522 | |
|
|
523 | Erlang relies on special naming and DNS to work everywhere in the |
|
|
524 | same way. AEMP relies on each node knowing it's own address(es), with |
|
|
525 | convenience functionality. |
|
|
526 | |
|
|
527 | =item * Erlang uses processes and a mailbox, AEMP does not queue. |
|
|
528 | |
|
|
529 | Erlang uses processes that selctively receive messages, and therefore |
|
|
530 | needs a queue. AEMP is event based, queuing messages would serve no useful |
|
|
531 | purpose. |
|
|
532 | |
|
|
533 | (But see L<Coro::MP> for a more erlang-like process model on top of AEMP). |
|
|
534 | |
|
|
535 | =item * Erlang sends are synchronous, AEMP sends are asynchronous. |
|
|
536 | |
|
|
537 | Sending messages in erlang is synchronous and blocks the process. AEMP |
|
|
538 | sends are immediate, connection establishment is handled in the |
|
|
539 | background. |
|
|
540 | |
|
|
541 | =item * Erlang can silently lose messages, AEMP cannot. |
|
|
542 | |
|
|
543 | Erlang makes few guarantees on messages delivery - messages can get lost |
|
|
544 | without any of the processes realising it (i.e. you send messages a, b, |
|
|
545 | and c, and the other side only receives messages a and c). |
|
|
546 | |
|
|
547 | AEMP guarantees correct ordering, and the guarantee that there are no |
|
|
548 | holes in the message sequence. |
|
|
549 | |
|
|
550 | =item * In erlang, processes can be declared dead and later be found to be |
|
|
551 | alive. |
|
|
552 | |
|
|
553 | In erlang it can happen that a monitored process is declared dead and |
|
|
554 | linked processes get killed, but later it turns out that the process is |
|
|
555 | still alive - and can receive messages. |
|
|
556 | |
|
|
557 | In AEMP, when port monitoring detects a port as dead, then that port will |
|
|
558 | eventually be killed - it cannot happen that a node detects a port as dead |
|
|
559 | and then later sends messages to it, finding it is still alive. |
|
|
560 | |
|
|
561 | =item * Erlang can send messages to the wrong port, AEMP does not. |
|
|
562 | |
|
|
563 | In erlang it is quite possible that a node that restarts reuses a process |
|
|
564 | ID known to other nodes for a completely different process, causing |
|
|
565 | messages destined for that process to end up in an unrelated process. |
|
|
566 | |
|
|
567 | AEMP never reuses port IDs, so old messages or old port IDs floating |
|
|
568 | around in the network will not be sent to an unrelated port. |
|
|
569 | |
|
|
570 | =item * Erlang uses unprotected connections, AEMP uses secure |
|
|
571 | authentication and can use TLS. |
|
|
572 | |
|
|
573 | AEMP can use a proven protocol - SSL/TLS - to protect connections and |
|
|
574 | securely authenticate nodes. |
|
|
575 | |
|
|
576 | =back |
|
|
577 | |
| 503 | =head1 SEE ALSO |
578 | =head1 SEE ALSO |
| 504 | |
579 | |
| 505 | L<AnyEvent>. |
580 | L<AnyEvent>. |
| 506 | |
581 | |
| 507 | =head1 AUTHOR |
582 | =head1 AUTHOR |
