[ViewVC] Diff of: cvs/AnyEvent-MP/MP.pm

Comparing AnyEvent-MP/MP.pm (file contents):
Revision 1.22 by root, Tue Aug 4 18:33:30 2009 UTC vs.
Revision 1.29 by root, Tue Aug 4 23:16:57 2009 UTC

…		…
30	This module (-family) implements a simple message passing framework.	30	This module (-family) implements a simple message passing framework.
31		31
32	Despite its simplicity, you can securely message other processes running	32	Despite its simplicity, you can securely message other processes running
33	on the same or other hosts.	33	on the same or other hosts.
34		34
		35	For an introduction to this module family, see the L<AnyEvent::MP::Intro>
		36	manual page.
		37
35	At the moment, this module family is severly brokena nd underdocumented,	38	At the moment, this module family is severly broken and underdocumented,
36	so do not use. This was uploaded mainly to reserve the CPAN namespace -	39	so do not use. This was uploaded mainly to reserve the CPAN namespace -
37	stay tuned!	40	stay tuned! The basic API should be finished, however.
38		41
39	=head1 CONCEPTS	42	=head1 CONCEPTS
40		43
41	=over 4	44	=over 4
42		45
43	=item port	46	=item port
44		47
45	A port is something you can send messages to with the C<snd> function, and	48	A port is something you can send messages to (with the C<snd> function).
46	you can register C<rcv> handlers with. All C<rcv> handlers will receive	49
47	messages they match, messages will not be queued.	50	Some ports allow you to register C<rcv> handlers that can match specific
		51	messages. All C<rcv> handlers will receive messages they match, messages
		52	will not be queued.
48		53
49	=item port id - C<noderef#portname>	54	=item port id - C<noderef#portname>
50		55
51	A port id is always the noderef, a hash-mark (C<#>) as separator, followed	56	A port id is normaly the concatenation of a noderef, a hash-mark (C<#>) as
52	by a port name (a printable string of unspecified format).	57	separator, and a port name (a printable string of unspecified format). An
		58	exception is the the node port, whose ID is identical to it's node
		59	reference.
53		60
54	=item node	61	=item node
55		62
56	A node is a single process containing at least one port - the node	63	A node is a single process containing at least one port - the node
57	port. You can send messages to node ports to let them create new ports,	64	port. You can send messages to node ports to find existing ports or to
58	among other things.	65	create new ports, among other things.
59		66
60	Initially, nodes are either private (single-process only) or hidden	67	Nodes are either private (single-process only), slaves (connected to a
61	(connected to a master node only). Only when they epxlicitly "become	68	master node only) or public nodes (connectable from unrelated nodes).
62	public" can you send them messages from unrelated other nodes.
63		69
64	=item noderef - C<host:port,host:port...>, C<id@noderef>, C<id>	70	=item noderef - C<host:port,host:port...>, C<id@noderef>, C<id>
65		71
66	A noderef is a string that either uniquely identifies a given node (for	72	A node reference is a string that either simply identifies the node (for
67	private and hidden nodes), or contains a recipe on how to reach a given	73	private and slave nodes), or contains a recipe on how to reach a given
68	node (for public nodes).	74	node (for public nodes).
69		75
		76	This recipe is simply a comma-separated list of C<address:port> pairs (for
		77	TCP/IP, other protocols might look different).
		78
		79	Node references come in two flavours: resolved (containing only numerical
		80	addresses) or unresolved (where hostnames are used instead of addresses).
		81
		82	Before using an unresolved node reference in a message you first have to
		83	resolve it.
		84
70	=back	85	=back
71		86
72	=head1 VARIABLES/FUNCTIONS	87	=head1 VARIABLES/FUNCTIONS
73		88
74	=over 4	89	=over 4
…		…
85		100
86	use AE ();	101	use AE ();
87		102
88	use base "Exporter";	103	use base "Exporter";
89		104
90	our $VERSION = '0.02';	105	our $VERSION = '0.1';
91	our @EXPORT = qw(	106	our @EXPORT = qw(
92	NODE $NODE *SELF node_of _any_	107	NODE $NODE *SELF node_of _any_
		108	resolve_node
93	become_slave become_public	109	become_slave become_public
94	snd rcv mon kil reg psub	110	snd rcv mon kil reg psub
95	port	111	port
96	);	112	);
97		113
…		…
111	identifiers become invalid.	127	identifiers become invalid.
112		128
113	=item $noderef = node_of $portid	129	=item $noderef = node_of $portid
114		130
115	Extracts and returns the noderef from a portid or a noderef.	131	Extracts and returns the noderef from a portid or a noderef.
		132
		133	=item $cv = resolve_node $noderef
		134
		135	Takes an unresolved node reference that may contain hostnames and
		136	abbreviated IDs, resolves all of them and returns a resolved node
		137	reference.
		138
		139	In addition to C<address:port> pairs allowed in resolved noderefs, the
		140	following forms are supported:
		141
		142	=over 4
		143
		144	=item the empty string
		145
		146	An empty-string component gets resolved as if the default port (4040) was
		147	specified.
		148
		149	=item naked port numbers (e.g. C<1234>)
		150
		151	These are resolved by prepending the local nodename and a colon, to be
		152	further resolved.
		153
		154	=item hostnames (e.g. C<localhost:1234>, C<localhost>)
		155
		156	These are resolved by using AnyEvent::DNS to resolve them, optionally
		157	looking up SRV records for the C<aemp=4040> port, if no port was
		158	specified.
		159
		160	=back
116		161
117	=item $SELF	162	=item $SELF
118		163
119	Contains the current port id while executing C<rcv> callbacks or C<psub>	164	Contains the current port id while executing C<rcv> callbacks or C<psub>
120	blocks.	165	blocks.
…		…
241	sub mon_guard {	286	sub mon_guard {
242	my ($port, @refs) = @_;	287	my ($port, @refs) = @_;
243		288
244	mon $port, sub { 0 && @refs }	289	mon $port, sub { 0 && @refs }
245	}	290	}
		291
		292	=item lnk $port1, $port2
		293
		294	Link two ports. This is simply a shorthand for:
		295
		296	mon $port1, $port2;
		297	mon $port2, $port1;
		298
		299	It means that if either one is killed abnormally, the other one gets
		300	killed as well.
246		301
247	=item $local_port = port	302	=item $local_port = port
248		303
249	Create a new local port object that supports message matching.	304	Create a new local port object that supports message matching.
250		305
…		…
434		489
435	=head1 FUNCTIONS FOR NODES	490	=head1 FUNCTIONS FOR NODES
436		491
437	=over 4	492	=over 4
438		493
439	=item become_public endpoint...	494	=item become_public $noderef
440		495
441	Tells the node to become a public node, i.e. reachable from other nodes.	496	Tells the node to become a public node, i.e. reachable from other nodes.
442		497
443	If no arguments are given, or the first argument is C<undef>, then	498	The first argument is the (unresolved) node reference of the local node
444	AnyEvent::MP tries to bind on port C<4040> on all IP addresses that the	499	(if missing then the empty string is used).
445	local nodename resolves to.
446		500
447	Otherwise the first argument must be an array-reference with transport	501	It is quite common to not specify anything, in which case the local node
448	endpoints ("ip:port", "hostname:port") or port numbers (in which case the	502	tries to listen on the default port, or to only specify a port number, in
449	local nodename is used as hostname). The endpoints are all resolved and	503	which case AnyEvent::MP tries to guess the local addresses.
450	will become the node reference.
451		504
452	=cut	505	=cut
453		506
454	=back	507	=back
455		508
…		…
458	Nodes understand the following messages sent to them. Many of them take	511	Nodes understand the following messages sent to them. Many of them take
459	arguments called C<@reply>, which will simply be used to compose a reply	512	arguments called C<@reply>, which will simply be used to compose a reply
460	message - C<$reply[0]> is the port to reply to, C<$reply[1]> the type and	513	message - C<$reply[0]> is the port to reply to, C<$reply[1]> the type and
461	the remaining arguments are simply the message data.	514	the remaining arguments are simply the message data.
462		515
		516	While other messages exist, they are not public and subject to change.
		517
463	=over 4	518	=over 4
464		519
465	=cut	520	=cut
466		521
467	=item lookup => $name, @reply	522	=item lookup => $name, @reply
…		…
495	snd $NODE, time => $myport, timereply => 1, 2;	550	snd $NODE, time => $myport, timereply => 1, 2;
496	# => snd $myport, timereply => 1, 2, <time>	551	# => snd $myport, timereply => 1, 2, <time>
497		552
498	=back	553	=back
499		554
		555	=head1 AnyEvent::MP vs. Distributed Erlang
		556
		557	AnyEvent::MP got lots of its ideas from distributed erlang (erlang node
		558	== aemp node, erlang process == aemp port), so many of the documents and
		559	programming techniques employed by erlang apply to AnyEvent::MP. Here is a
		560	sample:
		561
		562	http://www.erlang.se/doc/programming_rules.shtml
		563	http://erlang.org/doc/getting_started/part_frame.html # chapters 3 and 4
		564	http://erlang.org/download/erlang-book-part1.pdf # chapters 5 and 6
		565	http://erlang.org/download/armstrong_thesis_2003.pdf # chapters 4 and 5
		566
		567	Despite the similarities, there are also some important differences:
		568
		569	=over 4
		570
		571	=item * Node references contain the recipe on how to contact them.
		572
		573	Erlang relies on special naming and DNS to work everywhere in the
		574	same way. AEMP relies on each node knowing it's own address(es), with
		575	convenience functionality.
		576
		577	This means that AEMP requires a less tightly controlled environment at the
		578	cost of longer node references and a slightly higher management overhead.
		579
		580	=item * Erlang uses processes and a mailbox, AEMP does not queue.
		581
		582	Erlang uses processes that selctively receive messages, and therefore
		583	needs a queue. AEMP is event based, queuing messages would serve no useful
		584	purpose.
		585
		586	(But see L<Coro::MP> for a more erlang-like process model on top of AEMP).
		587
		588	=item * Erlang sends are synchronous, AEMP sends are asynchronous.
		589
		590	Sending messages in erlang is synchronous and blocks the process. AEMP
		591	sends are immediate, connection establishment is handled in the
		592	background.
		593
		594	=item * Erlang can silently lose messages, AEMP cannot.
		595
		596	Erlang makes few guarantees on messages delivery - messages can get lost
		597	without any of the processes realising it (i.e. you send messages a, b,
		598	and c, and the other side only receives messages a and c).
		599
		600	AEMP guarantees correct ordering, and the guarantee that there are no
		601	holes in the message sequence.
		602
		603	=item * In erlang, processes can be declared dead and later be found to be
		604	alive.
		605
		606	In erlang it can happen that a monitored process is declared dead and
		607	linked processes get killed, but later it turns out that the process is
		608	still alive - and can receive messages.
		609
		610	In AEMP, when port monitoring detects a port as dead, then that port will
		611	eventually be killed - it cannot happen that a node detects a port as dead
		612	and then later sends messages to it, finding it is still alive.
		613
		614	=item * Erlang can send messages to the wrong port, AEMP does not.
		615
		616	In erlang it is quite possible that a node that restarts reuses a process
		617	ID known to other nodes for a completely different process, causing
		618	messages destined for that process to end up in an unrelated process.
		619
		620	AEMP never reuses port IDs, so old messages or old port IDs floating
		621	around in the network will not be sent to an unrelated port.
		622
		623	=item * Erlang uses unprotected connections, AEMP uses secure
		624	authentication and can use TLS.
		625
		626	AEMP can use a proven protocol - SSL/TLS - to protect connections and
		627	securely authenticate nodes.
		628
		629	=item * The AEMP protocol is optimised for both text-based and binary
		630	communications.
		631
		632	The AEMP protocol, unlike the erlang protocol, supports both
		633	language-independent text-only protocols (good for debugging) and binary,
		634	language-specific serialisers (e.g. Storable).
		635
		636	It has also been carefully designed to be implementable in other languages
		637	with a minimum of work while gracefully degrading fucntionality to make the
		638	protocol simple.
		639
		640	=back
		641
500	=head1 SEE ALSO	642	=head1 SEE ALSO
501		643
502	L<AnyEvent>.	644	L<AnyEvent>.
503		645
504	=head1 AUTHOR	646	=head1 AUTHOR

Diff Legend

-–
+Removed lines
-+
+Added lines
-<
+Changed lines
->
+Changed lines

Comparing AnyEvent-MP/MP.pm (file contents): Revision 1.22 by root, Tue Aug 4 18:33:30 2009 UTC vs. Revision 1.29 by root, Tue Aug 4 23:16:57 2009 UTC

Diff Legend

Comparing AnyEvent-MP/MP.pm (file contents):
Revision 1.22 by root, Tue Aug 4 18:33:30 2009 UTC vs.
Revision 1.29 by root, Tue Aug 4 23:16:57 2009 UTC