view release on metacpan or  search on metacpan

MP/Intro.pod  view on Meta::CPAN

And any F<aemp run> on that host will automatically have the Bummskraut
IRC backend running.

There are plenty of possibilities you can use - it's all up to you how you
structure your application.

=head1 PART 4: Coro::MP - selective receive

Not all problems lend themselves naturally to an event-based solution:
sometimes things are easier if you can decide in what order you want to
receive messages, regardless of the order in which they were sent.

In these cases, L<Coro::MP> can provide a nice solution: instead of
registering callbacks for each message type, C<Coro::MP> attaches a
(coro-) thread to a port. The thread can then opt to selectively receive
messages it is interested in. Other messages are not lost, but queued, and
can be received at a later time.

The C<Coro::MP> module is not part of L<AnyEvent::MP>, but a separate
module. It is, however, tightly integrated into C<AnyEvent::MP> - the

MP/Transport.pm  view on Meta::CPAN

=head2 SIMPLE HANDSHAKE FOR NON-PERL NODES

Implementing the full set of options for handshaking can be a daunting
task.

If security is not so important (because you only connect locally and
control the host, a common case), and you want to interface with an AEMP
node from another programming language, then you can also implement a
simplified handshake.

For example, in a simple implementation you could decide to simply not
check the authenticity of the other side and use cleartext authentication
yourself. The the handshake is as simple as sending three lines of text,
reading three lines of text, and then you can exchange JSON-formatted
messages:

   aemp;1;<nodename>;hmac_sha3_512;json
   <nonce>
   cleartext;<hexencoded secret>;json

The nodename should be unique within the network, preferably unique with

bin/aemp  view on Meta::CPAN

conjunction with F<aemp run>, to configure which services a node should
run.

Despite the daunting name, services really I<are> nothing more than a
module name or a function name with arguments. The "service" aspect comes
only from the behaviour of the module or function, which is supposed to
implement, well, some kind of service for the node, network etc.

Instead of writing a standalone program for each different node type in
your network, you can simply put your code into a module, and then let the
configuration decide which node runs which "services". This also makes it
easy to combine multiple different services within the same node.

=over 4

=item setservices <initfunc>...

Sets or replaces the list of services, which must be specified as a
comma-separated list or a JSON array.

Each string entry in the list is interpreted as either a module name to