Event-RPC

 view release on metacpan or  search on metacpan

README  view on Meta::CPAN

NAME
    Event::RPC - Event based transparent Client/Server RPC framework

SYNOPSIS
      #-- Server Code
      use Event::RPC::Server;
      use My::TestModule;
      my $server = Event::RPC::Server->new (
          port    => 5555,
          classes => { "My::TestModule" => { ... } },
      );
      $server->start;

README  view on Meta::CPAN

          port     => 5555,
      );
      $client->connect;

      #-- Call methods of My::TestModule on the server
      my $obj = My::TestModule->new ( foo => "bar" );
      my $foo = $obj->get_foo;

ABSTRACT
    Event::RPC supports you in developing Event based networking
    client/server applications with transparent object/method access from
    the client to the server. Network communication is optionally encrypted
    using IO::Socket::SSL. Several event loop managers are supported due to
    an extensible API. Currently Event, Glib and AnyEvent are implemented.
    The latter lets you use nearly every event loop implementation available
    for Perl. AnyEvent was invented after Event::RPC was created and thus
    Event::RPC started using it's own abstraction model.

DESCRIPTION
    Event::RPC consists of a server and a client library. The server exports
    a list of classes and methods, which are allowed to be called over the
    network. More specific it acts as a proxy for objects created on the
    server side (on demand of the connected clients) which handles client
    side methods calls with transport of method arguments and return values.

    The object proxy handles refcounting and destruction of objects created
    by clients properly. Objects as method parameters and return values are
    handled as well (although with some limitations, see below).

    For the client the whole thing is totally transparent - once connected
    to the server it doesn't know whether it calls methods on local or
    remote objects.

    Also the methods on the server newer know whether they are called
    locally or from a connected client. Your application logic is not
    affected by Event::RPC at all, at least if it has a rudimentary clean OO
    design.

    For details on implementing servers and clients please refer to the man
    pages of Event::RPC::Server and Event::RPC::Client.

README  view on Meta::CPAN

      server.pl
      client.pl

    Just execute them with --help to get the usage. They do some very simple
    communication but are good to test your setup, in particular in a mixed
    environment.

LIMITATIONS
    Although the classes and objects on the server are accessed
    transparently by the client there are some limitations should be aware
    of. With a clean object oriented design these should be no problem in
    real applications:

  Direct object data manipulation is forbidden
    All objects reside on the server and they keep there! The client just
    has specially wrapped proxy objects, which trigger the necessary magic
    to access the object's methods on the server. Complete objects are never
    transferred from the server to the client, so something like this does
    not work:

examples/client.pl  view on Meta::CPAN

    );

    $client->connect;

    print "\nConnected to localhost:5555\n\n";
    print "Server version:  ".$client->get_server_version,"\n";
    print "Server protocol: ".$client->get_server_protocol,"\n";
    print "Message format:  ".eval { $client->get_message_format },"\n";
    print "\n";

    #-- So the call to Event::RPC::Test->new is handled transparently
    #-- by Event::RPC::Client
    print "** Create object on server\n";
    my $object = Test_class->new (
            data => "Initial data",
    );
    print "=> Object created with data: '".$object->get_data."'\n\n";

    #-- and methods calls as well...
    print "** Say hello to server.\n";
    print "=> Server returned: >>".$object->hello,"<<\n";

lib/Event/RPC.pm  view on Meta::CPAN

    my ($user, $pass) = @_;
    return crypt($pass, $user);
}

__END__

=encoding utf8

=head1 NAME

Event::RPC - Event based transparent Client/Server RPC framework

=head1 SYNOPSIS

  #-- Server Code
  use Event::RPC::Server;
  use My::TestModule;
  my $server = Event::RPC::Server->new (
      port    => 5555,
      classes => { "My::TestModule" => { ... } },
  );

lib/Event/RPC.pm  view on Meta::CPAN

      port     => 5555,
  );
  $client->connect;

  #-- Call methods of My::TestModule on the server
  my $obj = My::TestModule->new ( foo => "bar" );
  my $foo = $obj->get_foo;

=head1 ABSTRACT

Event::RPC supports you in developing Event based networking client/server applications with transparent object/method access from the client to the server. Network communication is optionally encrypted using IO::Socket::SSL. Several event loop manag...

=head1 DESCRIPTION

Event::RPC consists of a server and a client library. The server exports a list of classes and methods, which are allowed to be called over the network. More specific it acts as a proxy for objects created on the server side (on demand of the connect...

The object proxy handles refcounting and destruction of objects created by clients properly. Objects as method parameters and return values are handled as well (although with some limitations, see below).

For the client the whole thing is totally transparent - once connected to the server it doesn't know whether it calls methods on local or remote objects.

Also the methods on the server newer know whether they are called locally
or from a connected client. Your application logic is not affected by Event::RPC at all, at least if it has a rudimentary clean OO design.

For details on implementing servers and clients please refer to the man pages of Event::RPC::Server and Event::RPC::Client.

=head1 REQUIREMENTS

Event::RPC needs either one of the following modules on the server
(they're not necessary on the client):

lib/Event/RPC.pm  view on Meta::CPAN

  server.pl
  client.pl

Just execute them with --help to get the usage. They do some very
simple communication but are good to test your setup, in particular
in a mixed environment.

=head1 LIMITATIONS

Although the classes and objects on the server are accessed
transparently by the client there are some limitations should
be aware of. With a clean object oriented design these should
be no problem in real applications:

=head2 Direct object data manipulation is forbidden

All objects reside on the server and they keep there! The client
just has specially wrapped proxy objects, which trigger the
necessary magic to access the object's B<methods> on the server. Complete
objects are never transferred from the server to the client,
so something like this does B<not> work:

lib/Event/RPC/Connection.pm  view on Meta::CPAN

This is a hash reference of object id's which are in use by the client of
this connection. Keys are the object ids, value is always 1.
You can get the corresponding objects by using the

  $connection->get_client_object($oid)

method.

Don't change anything in this hash, in particular don't delete or add
entries. Event::RPC does all the necessary garbage collection transparently,
no need to mess with that.

=back

=head1 AUTHORS

  Jörn Reder <joern AT zyn.de>

=head1 COPYRIGHT AND LICENSE

lib/Event/RPC/Server.pm  view on Meta::CPAN

SSL encryption is fine, now it's really hard for an attacker to
listen or modify your network communication. But without any further
configuration any user on your network is able to connect to your
server. To prevent this users resp. connections to your server
needs to be authenticated somehow.

Since version 0.87 Event::RPC has an API to delegate authentication
tasks to a module, which can be implemented outside Event::RPC.
To be compatible with prior releases it ships the module
Event::RPC::AuthPasswdHash which implements the old behaviour
transparently.

This default implementation is a simple user/password based model. For now
this controls just the right to connect to your server, so knowing
one valid user/password pair is enough to access all exported methods
of your server. Probably a more differentiated model will be added later
which allows granting access to a subset of exported methods only
for each user who is allowed to connect.

The following options control the authentication: