Provided by: libpoe-perl_1.3670-2_all bug

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 "Stopped" callback is invoked at the beginning of the master session's
       _stop routine. The parameters are standard for POE::Session's _stop 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 "FailureEvent" in
       POE::Wheel::SocketFactory and "ErrorEvent" in POE::Wheel::ReadWrite.

   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.

       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 its purpose is to allow
       programs to reject connections or condition sockets before they're given to
       POE::Wheel::ReadWrite for management.

       The "ClientPreConnect" handler is called with the client socket in $_[ARG0], and its
       return value is significant.  It must return a valid client socket if the connection is
       acceptable.  It must return undef to reject the connection.

       Most $_[HEAP] values are valid in the "ClientPreConnect" handler.  Obviously,
       $_[HEAP]{client} is not because that wheel hasn't been created yet.

       In the following example, the "ClientPreConnect" handler returns the client socket after
       it has been upgraded to an SSL connection.

         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 Session Configuration

       These constructor parameters affect POE::Component::Server::TCP's main listening session.

       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, "ClientInput" 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".

         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 Socket or Socket6, depending
       on your version of Perl. Also be sure to have Socket::GetAddrInfo installed, which is
       required by POE::Wheel::SocketFactory for IPv6 support.

       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
       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" and "Stopped"
       callbacks if you want to specify your own "_start" and "_stop" events respectively.

       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" and "Stopped"
       callbacks if you want to specify your own "_start" and "_stop" events respectively.

       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" and "Stopped"
       callbacks if you want to specify your own "_start" and "_stop" events respectively.

       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.

       Stopped

       "Stopped" sets an optional callback that will be invoked within the main server session's
       context.  It notifies the server that it has fully stopped.  The callback's parameters are
       the usual for a session's _stop 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 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.
       There is "ClientInputFilter" and "ClientOutputFilter" if you want to specify a different
       filter for both directions.

       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".  Overrides the filter set by "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".  Overrides the filter set by "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. :)

AUTHORS & COPYRIGHTS

       POE::Component::Server::TCP is Copyright 2000-2013 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
       <kudra@domaintje.com>.

       POE::Component::Server::TCP is based on code, used with permission, from Jos Boumans
       <kane@cpan.org>.