view release on metacpan or  search on metacpan

README  view on Meta::CPAN

NAME
    RPC::PlServer - Perl extension for writing PlRPC servers

SYNOPSIS
      # Create a subclass of RPC::PlServer
      use RPC::PlServer;

      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();

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 PlRPC::Client(3) and 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.

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

    *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.

    *maxmessage* (--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.

    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. "CONFIGURATION FILE".

  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.
          ...
      }

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

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

  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
    *Accept* from Net::Daemon is split into three methods,
    *AcceptApplication*, *AcceptVersion* and *AcceptUser*, each of them
    returning TRUE or FALSE. The client receives the arguments as the
    attributes *application*, *version*, *user* and *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 $self is a subclass of $app. The AcceptVersion method
    returns TRUE, if the requested version is less or equal to
    ${$class}::VERSION, $self being an instance of $class. Whether a user is
    permitted to connect depends on the client configuration. See
    "CONFIGURATION FILE" below for examples.

  Method based access control
    Giving a client the ability to invoke arbitrary methods can be a
    terrible security hole. Thus the server has a *methods* attribute. This
    is a hash ref of class names as keys, the values being hash refs again
    with method names as the keys. That is, if your hash looks as follows: