NAME

RPC::Lite::Server - Lightweight RPC server framework.

SYNOPSIS

use strict;

use RPC::Lite::Server;

my $server = ExampleServer->new(
  {
    Transports  => [ 'TCP:ListenPort=10000,LocalAddr=localhost' ],
    Threaded    => 1,
  }
);

$server->Loop;

###########################

package ExampleServer;

use base qw(RPC::Lite::Server);

sub Initialize
{
  my $self = shift;

  $self->AddSignature( 'GetTime=int:' ); # optional signatures
}

sub GetTime
{
  return time();
}

...

DESCRIPTION

RPC::Lite::Server implements a very lightweight remote process
communications server framework.  It can use arbitrary Transport
(RPC::Lite::Transport) and Serialization (RPC::Lite::Serializer)
mechanisms.  It supports optional method signatures and threading.

new

Creates a new RPC::Lite::Server object. Takes a hash reference to specify arguments.

Supported Arguments

Transports

An array reference to transport specifications which will determine which transport layers are initialized by the Session Manager.

Threaded

Boolean value indicating whether or not the server should operate in a threaded mode where requests are handed to worker threads for completion.

This functionality depends on having the Thread::Pool module installed.

This functionality can also seriously impact the way a server must be implemented to handle concurrency, etc. It is not recommended that this option be used unless you understand the necessary precautions that must be taken when implementing threaded applications.

WortherThreads

Specifies the number of worker threads to use when threading is enabled. Defaults to 10.

IsThreadingSupported

Returns true if server multithreading support is available, false otherwise.

This is a class method, eg:

my $server = RPC::Lite::Server->new(
  {
    ...,
    Threaded => RPC::Lite::Server::IsThreadingSupported() ? 1 : 0,
  }
);

WARNING: Calling this before forking and doing some threading stuff in the child process may hang the child. The ithreads docs even say it doesn't play well with fork(). It is just mentioned here because it isn't obvious that calling this method does any thread stuff.

Loop

Loops, calling HandleRequest, and HandleResponses, does not return. Useful for a trivial server that doesn't need to do anything else in its event loop.

HandleRequests

Handles all pending requests, dispatching them to the underlying RPC implementation class.

Instead of calling Loop some servers may implement their own update loops, calling HandleRequests repeatedly.

HandleResponses

When threading is enabled, this method looks for completed requests and returns them to the requesting client.

AddSignature

Adds a signature for the given method. Signatures can be used to verify that clients and servers agree on method specifications. However, they are optional because most RPC implementations are done with close coupling of server and client development where developers are unlikely to need verification of server/client agreement.

See RPC::Lite::Signature for details on the format for specifying signatures.

AUTHORS

Andrew Burke (aburke@bitflood.org)
Jeremy Muhlich (jmuhlich@bitflood.org)