view release on metacpan or  search on metacpan

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

  package MyServer;
  $MyServer::VERSION = '0.01';
  @MyServer::ISA = qw(RPC::PlServer);

  # Overwrite the Run() method to handle a single connection
  sub Run {
      my $self = shift;
      my $socket = $self->{'socket'};
  }

  # Create an instance of the MyServer class
  package main;
  my $server = MyServer->new({'localport' => '1234'}, \@ARGV);

  # Bind the server to its port to make it actually running
  $server->Bind();


=head1 DESCRIPTION

PlRPC (Perl RPC) is a package for implementing servers and clients that
are written in Perl entirely. The name is borrowed from Sun's RPC
(Remote Procedure Call), but it could as well be RMI like Java's "Remote
Method Interface), because PlRPC gives you the complete power of Perl's
OO framework in a very simple manner.

RPC::PlServer is the package used on the server side, and you guess what
RPC::PlClient is for. Both share the package RPC::PlServer::Comm for
communication purposes. See L<PlRPC::Client(3)> and L<RPC::PlServer::Comm>
for these parts.

PlRPC works by defining a set of methods that may be executed by the client.
For example, the server might offer a method "multiply" to the client. Now
the clients method call

    @result = $client->multiply($a, $b);

will be immediately mapped to a method call

    @result = $server->multiply($a, $b);

on the server. The arguments and results will be transferred to or from
the server automagically. (This magic has a name in Perl: It's the
Storable module, my thanks to Raphael Manfredi for this excellent
package.) Simple, eh? :-)

The RPC::PlServer and RPC::PlClient are abstract servers and clients: You
have to derive your own classes from it.


=head2 Additional options

The RPC::PlServer inherits all of Net::Daemon's options and attributes
and adds the following:

=over 8

=item I<cipher>

The attribute value is an instance of Crypt::DES, Crypt::IDEA or any
other class with the same API for block encryption. If you supply
such an attribute, the traffic between client and server will be
encrypted using this option.

=item I<maxmessage> (B<--maxmessage=size>)

The size of messages exchanged between client and server is restricted,
in order to omit denial of service attacks. By default the limit is
65536 bytes.

=item users

This is an attribute of the client object used for Permit/Deny rules
in the config file. It's value is an array ref of user names that
are allowed to connect from the given client. See the example config
file below. L<CONFIGURATION FILE>.

=back

=head2 Error Handling

Error handling is simple with the RPC package, because it is based on
Perl exceptions completely. Thus your typical code looks like this:

  eval {
      # Do something here. Don't care for errors.
      ...
  };
  if ($@) {
      # An error occurred.
      ...
  }


=head2 Server Constructors

  my $server = RPC::PlServer(\%options, \@args);

(Class method) This constructor is immediately inherited from the
Net::Daemon package. See L<Net::Daemon(3)> for details.


=head2 Access Control

  $ok = $self->AcceptApplication($app);
  $ok = $self->AcceptVersion($version);
  $ok = $self->AcceptUser($user, $password);

The RPC::PlServer package has a very detailed access control scheme: First
of all it inherits Net::Daemon's host based access control. It adds
version control and user authorization. To achieve that, the method
I<Accept> from Net::Daemon is split into three methods,
I<AcceptApplication>, I<AcceptVersion> and I<AcceptUser>, each of them
returning TRUE or FALSE. The client receives the arguments as the attributes
I<application>, I<version>, I<user> and I<password>. A client is accepted
only if all of the above methods are returning TRUE.

The default implementations are as follows: The AcceptApplication method
returns TRUE, if B<$self> is a subclass of B<$app>. The AcceptVersion
method returns TRUE, if the requested version is less or equal to