ViewVC Help
View File | Revision Log | Show Annotations | Download File
/cvs/AnyEvent-MP/MP/Intro.pod
(Generate patch)

Comparing AnyEvent-MP/MP/Intro.pod (file contents):
Revision 1.20 by elmex, Fri Aug 28 15:44:39 2009 UTC vs.
Revision 1.21 by elmex, Fri Aug 28 15:58:23 2009 UTC

… …
6module, which allows us to transparently pass messages to our own process 6module, which allows us to transparently pass messages to our own process
7and to other processes on another or the same host. 7and to other processes on another or the same host.
8 8
9What kind of messages? Well, basically a message here means a list of Perl 9What kind of messages? Well, basically a message here means a list of Perl
10strings, numbers, hashes and arrays, anything that can be expressed as a 10strings, numbers, hashes and arrays, anything that can be expressed as a
11L<JSON> text (as JSON is used by default in the protocol). 11L<JSON> text (as JSON is used by default in the protocol). Here is an example:
12 12
13It's custom in L<AnyEvent::MP> to have a string which describes the type of the 13 [123, ["a", "b", "c"], { foo => 'bar' }]
14
15When using L<AnyEvent::MP> you should usually use a string as first element
16of a message, which describes the type of the
14message as first element (this is called a I<tag> in L<AnyEvent::MP>), as some 17message. That element is called a I<tag> in L<AnyEvent::MP>, as some
15API functions (C<rcv>) support matching it directly. So supposedly you want to 18API functions (C<rcv>) support matching it directly. So supposedly you want to
16send a ping message with your current time to something, this is how such a 19send a ping message with your current time to something, this is how such a
17message might look like (in Perl syntax): 20message might look like (in Perl syntax):
18 21
19 ['ping', 1251381636] 22 ['ping', 1251381636]
20 23
21And next you might ask: between which entities are those messages being 24The next interesting question is: Between which entities are those messages
22I<passed>? They are I<passed> between I<ports>. I<ports> are just sources and 25being I<passed>? They are I<passed> between I<ports>. I<ports> are just sources
23destinations for messages. How do these ports relate to things you know? Well, 26and destinations for messages. How do these ports relate to things you know?
24each I<port> belongs to a I<node>, and a I<node> is just the UNIX process that 27Well, each I<port> belongs to a I<node>, and a I<node> is just the UNIX process
25runs your L<AnyEvent::MP> application. 28that runs your L<AnyEvent::MP> application.
26 29
27Each I<node> is distinguished from other I<nodes> running on the same host or 30Each I<node> is distinguished from other I<nodes>, that run on the same host or
28multiple hosts in a network by it's I<node ID>. A I<node ID> can be manually 31multiple hosts in a network, by it's I<node ID>. A I<node ID> can be manually
29assigned or L<AnyEvent::MP> will assign one it self for you. 32assigned or L<AnyEvent::MP> will assign one it self for you.
30 33
31So, you might want to visualize it like this (setup is two nodes (more are of 34Here is a visualisation about how I<nodes>, I<ports> and UNIX processes
35relate to each other. The setup consists of two nodes (more are of
32course possible): Node C<A> (in UNIX process 7066) with ports C<ABC> and C<DEF> 36course possible): Node C<A> (in UNIX process 7066) with the ports C<ABC> and C<DEF>.
33and C<B> (in UNIX process 8321) with ports C<FOO> and C<BAR>). 37And the node C<B> (in UNIX process 8321) with the ports C<FOO> and C<BAR>.
34 38
35 39
36 |- PID: 7066 -| |- PID: 8321 -| 40 |- PID: 7066 -| |- PID: 8321 -|
37 | | | | 41 | | | |
38 | Node ID: A | | Node ID: B | 42 | Node ID: A | | Node ID: B |
… …
41 | | X | | 45 | | X | |
42 | Port DEF =|= <----/ \-----> =|= Port BAR | 46 | Port DEF =|= <----/ \-----> =|= Port BAR |
43 | | | | 47 | | | |
44 |-------------| |-------------| 48 |-------------| |-------------|
45 49
46The strings for the ports here are just for illustrative purposes. Even if in 50The strings for the I<port ids> here are just for illustrative purposes. Even
47reality I<ports> in L<AnyEvent::MP> are also identified by strings they can't 51if in reality I<ports> in L<AnyEvent::MP> are also identified by strings they
48be choosen manually and are assigned randomly. These I<port ids> should also 52can't be choosen manually and are assigned randomly. These I<port ids> should
49not be used directly for other purposes than referring to an endpoint for 53also not be used directly for other purposes than referring to an endpoint for
50messages. 54messages.
51 55
52The next sections will explain the API of L<AnyEvent::MP>. First the API is 56The next sections will explain the API of L<AnyEvent::MP> by going through a
53laid out by simple examples. Later some more complex idioms are introduced, 57few simple examples. Later some more complex idioms are introduced, which are
54which are maybe useful to solve some real world purposes. 58maybe useful to solve some real world problems.
55
56# In this tutorial I'll show you how to write a simple chat server based on
57# L<AnyEvent::MP>. This example is used because it nicely shows how to organise a
58# simple application, but keep in mind that every node trusts any other, so this
59# chat cannot be used to implement a real public chat server and client system,
60# but it can be used to implement a distributed chat server for example.
61 59
62=head1 Passing Your First Message 60=head1 Passing Your First Message
63 61
64As start lets have a look at the messaging API. The next example is just a 62As start lets have a look at the messaging API. The next example is just a
65demo to show the basic elements of message passing with L<AnyEvent::MP>. 63demo to show the basic elements of message passing with L<AnyEvent::MP>.

Diff Legend

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