Module Version: 1.287 Source
NAME
SYNOPSIS
DESCRIPTION
Accepting Connections Yourself
Master Listener Session
Default Child Connection Sessions
Performance Considerations
Special Needs Considerations
PUBLIC METHODS
new
Server Sesson Configuration
Acceptor
Address
Alias
Concurrency
Domain
Error
Hostname
InlineStates
ObjectStates
PackageStates
Port
Started
ListenerArgs
Connection Session Configuration
ClientArgs
ClientConnected
ClientDisconnected
ClientError
ClientFilter
ClientFlushed
ClientInput
ClientInputFilter
ClientOutputFilter
ClientShutdownOnError
SessionParams
SessionType
EVENTS
Main Server Commands
disconnected
set_concurrency
shutdown
Per-Connection Commands
shutdown
Reserved HEAP Members
HEAP Members for Master Listening Sessions
alias
concurrency
connections
listener
HEAP Members for Connection Sessions
client
got_an_error
remote_ip
remote_port
remote_addr
shutdown
shutdown_on_error
SEE ALSO
BUGS
AUTHORS & COPYRIGHTS
NAME
POE::Component::Server::TCP - a simplified TCP server
SYNOPSIS
#!perl
use warnings;
use strict;
use POE qw(Component::Server::TCP);
POE::Component::Server::TCP->new(
Port => 12345,
ClientConnected => sub {
print "got a connection from $_[HEAP]{remote_ip}\n";
$_[HEAP]{client}->put("Smile from the server!");
},
ClientInput => sub {
my $client_input = $_[ARG0];
$client_input =~ tr[a-zA-Z][n-za-mN-ZA-M];
$_[HEAP]{client}->put($client_input);
},
);
POE::Kernel->run;
exit;
DESCRIPTION
POE::Component::Server::TCP implements a generic multi-Session server. Simple services may be put together in a few lines of code. For example, a server that echoes input back to the client:
use POE qw(Component::Server::TCP);
POE::Component::Server::TCP->new(
Port => 12345,
ClientInput => sub { $_[HEAP]{client}->put($_[ARG0]) },
);
POE::Kernel->run();
Accepting Connections Yourself
POE::Component::Server::TCP has a default mode where it accepts new connections and creates the sessions to handle them. Programs can do this themselves by providing their own Acceptor callbacks. See "Acceptor" for details.
Master Listener Session
At creation time, POE::Component::Server::TCP starts one POE::Session to listen for new connections. The component's Alias refers to this master session.
If Acceptor is specified, then it's up to that callback to deal with newly accepted sockets. Its parameters are that of POE::Wheel::SocketFactory's SuccessEvent.
Otherwise, the default Acceptor callback will start a new session to handle each connection. These child sessions do not have their own aliases, but their ClientConnected and ClientDisconnected callbacks may be used to register and unregister the sessions with a shared namespace, such as a hash keyed on session IDs, or an object that manages such a hash.
my %client_namespace;
sub handle_client_connected {
my $client_session_id = $_[SESSION]->ID;
$client_namespace{$client_session_id} = \%anything;
}
sub handle_client_disconnected {
my $client_session_id = $_[SESSION]->ID;
$client_namespace{$client_session_id} = \%anything;
}
The component's Started callback is invoked at the end of the master session's start-up routine. The @_[ARG0..$#_] parameters are set to a copy of the values in the server's ListenerArgs constructor parameter. The other parameters are standard for POE::Session's _start handlers.
The component's Error callback is invoked when the server has a problem listening for connections. Error may also be called if the component's default acceptor has trouble accepting a connection. Error receives the usual ones for POE::Wheel::SocketFactory and POE::Wheel::ReadWrite ErrorEvent.
Default Child Connection Sessions
If Acceptor isn't specified, POE::Component::Server::TCP's default handler will start a new session for each new client connection. As mentioned above, these child sessions have no aliases of their own, but they may set aliases or register themselves another way during their ClientConnected and ClientDisconnected callbacks.
It can't be stressed enough that the following callbacks are executed within the context of dynamic child sessions---one per client connection---and not in the master listening session. This has been a major point of confusion. We welcome suggestions for making this clearer.
TODO - Document some of the implications of having each connection handled by a separate session.
The component's ClientInput callback defines how child sessions will handle input from their clients. Its parameters are that of POE::Wheel::ReadWrite's InputEvent.
As mentioned ClientConnected is called at the end of the child session's _start routine. The ClientConneted callback receives the same parameters as the client session's _start does. The arrayref passed to the constructor's Args parameter is flattened and included in ClientConnected's parameters as @_[ARG0..$#_].
sub handle_client_connected {
my @constructor_args = @_[ARG0..$#_];
...
}
ClientPreConnect is called before ClientConnected, and it has different parameters: $_[ARG0] contains a copy of the client socket before it's given to POE::Wheel::ReadWrite for management. Most HEAP members are set, except of course $_[HEAP]{client}, because the POE::Wheel::ReadWrite has not yet been created yet. ClientPreConnect may enable SSL on the socket, using POE::Component::SSLify. ClientPreConnect must return a valid socket to complete the connection; the client will be disconnected if anything else is returned.
sub handle_client_pre_connect {
# Make sure the remote address and port are valid.
return undef unless validate(
$_[HEAP]{remote_ip}, $_[HEAP]{remote_port}
);
# SSLify the socket, which is in $_[ARG0].
my $socket = eval { Server_SSLify($_[ARG0]) };
return undef if $@;
# Return the SSL-ified socket.
return $socket;
}
ClientDisconnected is called when the client has disconnected, either because the remote socket endpoint has closed or the local endpoint has been closed by the server. This doesn't mean the client's session has ended, but the session most likely will very shortly. ClientDisconnected is called from a couple disparate places within the component, so its parameters are neither consistent nor generally useful.
ClientError is called when an error has occurred on the socket. Its parameters are those of POE::Wheel::ReadWrite's ErrorEvent.
ClientFlushed is called when all pending output has been flushed to the client socket. Its parameters come from POE::Wheel::ReadWrite's ErrorEvent.
Performance Considerations
This ease of use comes at a price: POE::Component::Server::TCP often performs significantly slower than a comparable server written with POE::Wheel::SocketFactory and POE::Wheel::ReadWrite.
If performance is your primary goal, POE::Kernel's select_read() and select_write() perform about the same as IO::Select, but your code will be portable across every event loop POE supports.
Special Needs Considerations
POE::Component::Server::TCP is written to be easy for the most common use cases. Programs with more special needs should consider using POE::Wheel::SocketFactory and POE::Wheel::ReadWrite instead. These are lower-level modules, and using them requires more effort. They are more flexible and customizable, however.
PUBLIC METHODS
new
new() starts a server based on POE::Component::Server::TCP and returns a session ID for the master listening session. All error handling is done within the server, via the Error and ClientError callbacks.
The server may be shut down by posting a "shutdown" event to the master session, either by its ID or the name given to it by the Alias parameter.
POE::Component::Server::TCP does a lot of work in its constructor. The design goal is to push as much overhead into one-time construction so that ongoing run-time has less overhead. Because of this, the server's constructor can take quite a daunting number of parameters.
POE::Component::Server::TCP always returns a POE::Session ID for the session that will be listening for new connections.
Many of the constructor parameters have been previously described. They are covered briefly again below.
Server Sesson Configuration
These constructor parameters affect POE::Component::Server::TCP's main listening session.
TODO - Document the shutdown procedure somewhere.
Acceptor
Acceptor defines a CODE reference that POE::Wheel::SocketFactory's SuccessEvent will trigger to handle new connections. Therefore the parameters passed to Acceptor are identical to those given to SuccessEvent.
Acceptor is optional; the default handler will create a new session for each connection. All the "Client" constructor parameters are used to customize this session. In other words, CleintInput and such are not used when Acceptor is set.
The default Acceptor adds significant convenience and flexibility to POE::Component::Server::TCP, but it's not always a good fit for every application. In some cases, a custom Acceptor or even rolling one's own server with POE::Wheel::SocketFactory and POE::Wheel::ReadWrite may be better and/or faster.
Acceptor => sub {
my ($socket, $remote_address, $remote_port) = @_[ARG0..ARG2];
# Set up something to interact with the client.
}
Address
Address defines a single interface address the server will bind to. It defaults to INADDR_ANY or INADDR6_ANY, when using IPv4 or IPv6, respectively. It is often used with Port.
The value in Address is passed to POE::Wheel::SocketFactory's BindAddress parameter, so it may be in whatever form that module supports. At the time of this writing, that may be a dotted IPv4 quad, an IPv6 address, a host name, or a packed Internet address. See also "Hostname".
TODO - Example, using the lines below.
Address => '127.0.0.1' # Localhost IPv4
Address => "::1" # Localhost IPv6
Alias
Alias is an optional name that will be given to the server's master listening session. Events sent to this name will not be delivered to individual connections.
The server's Alias may be important if it's necessary to shut a server down.
sub sigusr1_handler {
$_[KERNEL]->post(chargen_server => 'shutdown');
$_[KERNEL]->sig_handled();
}
Concurrency
Concurrency controls how many connections may be active at the same time. It defaults to -1, which allows POE::Component::Server::TCP to accept concurrent connections until the process runs out of resources.
Setting Concurrency to 0 prevents the server from accepting new connections. This may be useful if a server must perform lengthy initialization before allowing connections. When the initialization finishes, it can yield(set_concurrency => -1) to enable connections. Likewise, a running server may yield(set_concurrency => 0) or any other number to dynamically tune its concurrency. See EVENTS for more about the set_concurrency event.
Note: For Concurrency to work with a custom Acceptor, the server's listening session must receive a disconnected event whenever clients disconnect. Otherwise the listener cannot mediate between its connections.
Example:
Acceptor => sub {
# ....
POE::Session->create(
# ....
inline_states => {
_start => sub {
# ....
# remember who our parent is
$_[HEAP]->{server_tcp} = $_[SENDER]->ID;
# ....
},
got_client_disconnect => sub {
# ....
$_[KERNEL]->post( $_[HEAP]->{server_tcp} => 'disconnected' );
# ....
}
}
);
}
Domain
Domain sets the address or protocol family within which to operate. The Domain may be any value that POE::Wheel::SocketFactory supports. AF_INET (Internet address space) is used by default.
Use AF_INET6 for IPv6 support. This constant is exported by Socket6, which must be loaded before POE::Component::Server::TCP.
Error
Error is the callback that will be invoked when the server socket reports an error. The Error callback will be used to handle POE::Wheel::SocketFactory's FailureEvent, so it will receive the same parameters as discussed there.
A default error handler will be provided if Error is omitted. The default handler will log the error to STDERR and shut down the server. Active connections will be permitted to to complete their transactions.
Error => sub {
my ($syscall_name, $err_num, $err_str) = @_[ARG0..ARG2];
# Handle the error.
}
Hostname
Hostname is the optional non-packed name of the interface the TCP server will bind to. The hostname will always be resolved via inet_aton() and so can either be a dotted quad or a name. Name resolution is a one-time start-up action; there are no ongoing run-time penalties for using it.
Hostname guarantees name resolution, where Address does not. It's therefore preferred to use Hostname in cases where resolution must always be done.
InlineStates
InlineStates is optional. If specified, it must hold a hashref of named callbacks. Its syntax is that of POE:Session->create()'s inline_states parameter.
Remember: These InlineStates handlers will be added to the client sessions, not to the main listening session. A yield() in the listener will not reach these handlers.
If POE::Kernel::ASSERT_USAGE is enabled, the constructor will croak() if it detects a state that it uses internally. For example, please use the "Started" callback if you want to specify your own "_start" event.
ObjectStates
If ObjectStates is specified, it must holde an arrayref of objects and the events they will handle. The arrayref must follow the syntax for POE::Session->create()'s object_states parameter.
Remember: These ObjectStates handlers will be added to the client sessions, not to the main listening session. A yield() in the listener will not reach these handlers.
If POE::Kernel::ASSERT_USAGE is enabled, the constructor will croak() if it detects a state that it uses internally. For example, please use the "Started" callback if you want to specify your own "_start" event.
PackageStates
When the optional PackageStates is set, it must hold an arrayref of package names and the events they will handle The arrayref must follow the syntax for POE::Session->create()'s package_states parameter.
Remember: These PackageStates handlers will be added to the client sessions, not to the main listening session. A yield() in the listener will not reach these handlers.
If POE::Kernel::ASSERT_USAGE is enabled, the constructor will croak() if it detects a state that it uses internally. For example, please use the "Started" callback if you want to specify your own "_start" event.
Port
Port contains the port the listening socket will be bound to. It defaults to 0, which usually lets the operating system pick a port at random.
Port => 30023
It is often used with Address.
Started
Started sets an optional callback that will be invoked within the main server session's context. It notifies the server that it has fully started. The callback's parameters are the usual for a session's _start handler.
ListenerArgs
ListenerArgs is passed to the listener session as the args parameter. In other words, it must be an arrayref, and the values are are passed into the Started handler as ARG0, ARG1, etc.
Connection Session Configuration
These constructor parameters affect the individual sessions that interact with established connections.
ClientArgs
ClientArgs is optional. When specified, it holds an ARRAYREF that will be expanded one level and passed to the ClientConnected callback in @_[ARG0..$#_].
ClientConnected
Each new client connection is handled by a new POE::Session instance. ClientConnected is a callback that notifies the application when a client's session is started and ready for operation. Banners are often sent to the remote client from this callback.
The @_[ARG0..$#_] parameters to ClientConnected are a copy of the values in the ClientArgs constructor parameter's array reference. The other @_ members are standard for a POE::Session _start handler.
ClientConnected is called once per session start-up. It will never be called twice for the same connection.
ClientConnected => sub {
$_[HEAP]{client}->put("Hello, client!");
# Other client initialization here.
},
ClientDisconnected
ClientDisconnected is a callback that will be invoked when the client disconnects or has been disconnected by the server. It's useful for cleaning up global client information, such as chat room structures. ClientDisconnected callbacks receive the usual POE parameters, but nothing special is included.
ClientDisconnected => sub {
warn "Client disconnected"; # log it
}
ClientError
The ClientError callback is invoked when a client socket reports an error. ClientError is called with POE's usual parameters, plus the common error parameters: $_[ARG0] describes what was happening at the time of failure. $_[ARG1] and $_[ARG2] contain the numeric and string versions of $!, respectively.
ClientError is optional. If omitted, POE::Component::Server::TCP will provide a default callback that logs most errors to STDERR.
If ClientShutdownOnError is set, the connection will be shut down after ClientError returns. If ClientDisconnected is specified, it will be called as the client session is cleaned up.
ClientError is triggered by POE::Wheel::ReadWrite's ErrorEvent, so it follows that event's form. Please see the ErrorEvent documentation in POE::Wheel::ReadWrite for more details.
ClientError => sub {
my ($syscall_name, $error_num, $error_str) = @_[ARG0..ARG2];
# Handle the client error here.
}
ClientFilter
ClientFilter specifies the POE::Filter object or class that will parse input from each client and serialize output before it's sent to each client.
ClientFilter may be a SCALAR, in which case it should name the POE::Filter class to use. Each new connection will be given a freshly instantiated filter of that class. No constructor parameters will be passed.
ClientFilter => "POE::Filter::Stream",
Some filters require constructor parameters. These may be specified by an ARRAYREF. The first element is the POE::Filter class name, and subsequent elements are passed to the class' constructor.
ClientFilter => [ "POE::Filter::Line", Literal => "\n" ],
ClientFilter may also be given an archetypical POE::Filter OBJECT. In this case, each new client session will receive a clone() of the given object.
ClientFilter => POE::Filter::Line->new(Literal => "\n"),
ClientFilter is optional. The component will use "POE::Filter::Line" if it is omitted.
Filter modules are not automatically loaded. Be sure that the program loads the class before using it.
ClientFlushed
ClientFlushed exposes POE::Wheel::ReadWrite's FlushedEvent as a callback. It is called whenever the client's output buffer has been fully flushed to the client socket. At this point it's safe to shut down the socket without losing data.
ClientFlushed is useful for streaming servers, where a "flushed" event signals the need to send more data.
ClientFlushed => sub {
my $data_source = $_[HEAP]{file_handle};
my $read_count = sysread($data_source, my $buffer = "", 65536);
if ($read_count) {
$_[HEAP]{client}->put($buffer);
}
else {
$_[KERNEL]->yield("shutdown");
}
},
POE::Component::Server::TCP's default Acceptor ensures that data is flushed before finishing a client shutdown.
ClientInput
ClientInput defines a per-connection callback to handle client input. This callback receives its parameters directly from POE::Wheel::ReadWrite's InputEvent. ARG0 contains the input record, the format of which is defined by ClientFilter or ClientInputFilter. ARG1 has the wheel's unique ID, and so on. Please see POE:Wheel::ReadWrite for an in-depth description of InputEvent.
ClientInput and Acceptor are mutually exclusive. Enabling one prohibits the other.
ClientInput => sub {
my $input = $_[ARG0];
$_[HEAP]{wheel}->put("You said: $input");
},
ClientInputFilter
ClientInputFilter is used with ClientOutputFilter to specify different protocols for input and output. Both must be used together. Both follow the same usage as "ClientFilter".
ClientInputFilter => [ "POE::Filter::Line", Literal => "\n" ],
ClientOutputFilter => 'POE::Filter::Stream',
ClientOutputFilter
ClientOutputFilter is used with ClientInputFilter to specify different protocols for input and output. Both must be used together. Both follow the same usage as "ClientFilter".
ClientInputFilter => POE::Filter::Line->new(Literal => "\n"),
ClientOutputFilter => 'POE::Filter::Stream',
ClientShutdownOnError
ClientShutdownOnError tells the component whether client connections should be shut down automatically if an error is detected. It defaults to "true". Setting it to false (0, undef, "") turns off this feature.
The application is responsible for dealing with client errors if this feature is disabled. Not doing so may cause the component to emit a constant stream of errors, eventually bogging down the application with dead connections that spin out of control.
Yes, this is terrible. You have been warned.
SessionParams
SessionParams specifies additional parameters that will be passed to the SessionType constructor at creation time. It must be an array reference.
SessionParams => [ options => { debug => 1, trace => 1 } ],
Note: POE::Component::Server::TCP supplies its own POE::Session constructor parameters. Conflicts between them and SessionParams may cause the component to behave erratically. To avoid such problems, please limit SessionParams to the options hash. See POE::Session for an known options.
We may enable other options later. Please let us know if you need something.
SessionType
SessionType specifies the POE::Session subclass that will be created for each new client connection. "POE::Session" is the default.
SessionType => "POE::Session::MultiDispatch"
EVENTS
It's possible to manipulate a TCP server component by sending it messages.
Main Server Commands
These events must be sent to the main server, usually by the alias set in its Alias parameter.
disconnected
The "disconnected" event informs the TCP server that a connection was closed. It is needed when using Concurrency with an Acceptor callback. The custom Acceptor must provide its own disconnect notification so that the server's connection counting logic works.
Otherwise Concurrency clients will be accepted, and then no more. The server will never know when clients have disconnected.
set_concurrency
"set_concurrency" set the number of simultaneous connections the server will be willing to accept. See Concurrency for more details. "set_concurrency" must have one parameter: the new maximum connection count.
$kernel->call("my_server_alias", "set_concurrency", $max_count);
shutdown
The "shutdown" event starts a graceful server shutdown. No new connections will be accepted. Existing connections will be allowed to finish. The server will be destroyed after the last connection ends.
Per-Connection Commands
These commands affect each client connection session.
shutdown
Sending "shutdown" to an individual client session instructs the server to gracefully shut down that connection. No new input will be received, and any buffered output will be sent before the session ends.
Client sessions usually yield("shutdown") when they wish to disconnect the client.
ClientInput => sub {
if ($_[ARG0] eq "quit") {
$_[HEAP]{client}->put("B'bye!");
$_[KERNEL]->yield("shutdown");
return;
}
# Handle other input here.
},
Reserved HEAP Members
Unlike most POE modules, POE::Component::Server::TCP stores data in the client sessions' HEAPs. These values are provided as conveniences for application developers.
HEAP Members for Master Listening Sessions
The master listening session holds different data than client connections.
alias
$_[HEAP]{alias} contains the server's Alias.
concurrency
$_[HEAP]{concurrency} remembers the server's Concurrency parameter.
connections
$_[HEAP]{connections} is used to track the current number of concurrent client connections. It's incremented whenever a new connection is accepted, and it's decremented whenever a client disconnects.
listener
$_[HEAP]{listener} contains the POE::Wheel::SocketFactory object used to listen for connections and accept them.
HEAP Members for Connection Sessions
These data members exist within the individual connections' sessions.
client
$_[HEAP]{client} contains a POE::Wheel::ReadWrite object used to interact with the client. All POE::Wheel::ReadWrite methods work.
got_an_error
$_[HEAP]{got_an_error} remembers whether the client connection has already encountered an error. It is part of the shutdown-on-error procedure.
remote_ip
$_[HEAP]{remote_ip} contains the remote client's numeric address in human-readable form.
remote_port
$_[HEAP]{remote_port} contains the remote client's numeric socket port in human-readable form.
remote_addr
$_[HEAP]{remote_addr} contains the remote client's packed socket address in computer-readable form.
shutdown
$_[HEAP]{shutdown} is true if the client is in the process of shutting down. The component uses it to ignore client input during shutdown, and to close the connection after pending output has been flushed.
shutdown_on_error
$_[HEAP]{shutdown_on_error} remembers whether the client connection should automatically shut down if an error occurs.
SEE ALSO
The SEE ALSO section in POE contains a table of contents covering the entire POE distribution.
POE::Component::Client::TCP is the client-side counterpart to this module.
This component uses and exposes features from POE::Filter, POE::Wheel::SocketFactory, and POE::Wheel::ReadWrite.
BUGS
This looks nothing like what Ann envisioned.
This component currently does not accept many of the options that POE::Wheel::SocketFactory does.
This component will not bind to several addresses at once. This may be a limitation in SocketFactory, but it's not by design.
This component needs better error handling.
Some use cases require different session classes for the listener and the connection handlers. This isn't currently supported. Please send patches. :)
TODO - Document that Reuse is set implicitly.
AUTHORS & COPYRIGHTS
POE::Component::Server::TCP is Copyright 2000-2009 by Rocco Caputo. All rights are reserved. POE::Component::Server::TCP is free software, and it may be redistributed and/or modified under the same terms as Perl itself.
POE::Component::Server::TCP is based on code, used with permission, from Ann Barcomb <>.
POE::Component::Server::TCP is based on code, used with permission, from Jos Boumans <>.
