POE::C...er::TCP(3pm)

📦

version 1.3700 · 7 versions

1.3700 · debian bookworm, debian trixie, ubuntu noble, ubuntu questing (latest)
1.368 · epel 9
1.370 · arch rolling
1.370 · fedora 43
1.3680 · ubuntu jammy
1.370 · fedora 44
1.3700 · ubuntu resolute, ubuntu stonking

, in debian bookworm, debian trixie, ubuntu noble, ubuntu questing

💖 POE::C...er::TCP — the manual, but make it make sense 💖

okay bestie, welcome to the manual page for POE::Component::Server::TCP, straight out of the User Contributed Perl Documentation for POE::C...er::TCP(3pm). buckle up, this one's a whole journey (and it's part 1 of 3, so don't go anywhere 🫶).

✨ NAME ✨

POE::Component::Server::TCP — it's a simplified TCP server, and yes that's literally the whole vibe. a whole TCP server, but make it chill 💅

🌸 SYNOPSIS 🌸

here's the look, bestie:

#!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;

that tr[a-zA-Z][n-za-mN-ZA-M] is a ROT13 glow-up in case you were wondering. iconic. ✨

🦋 DESCRIPTION 🦋

POE::Component::Server::TCP implements a generic multi-Session server. like, a generic one. simple services can be put together in just a few lines of code — no cap. for example, a server that echoes input right 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();

five lines. FIVE. it's giving effortless 💅

💫 Accepting Connections Yourself 💫

POE::Component::Server::TCP has a default mode where it accepts new connections and creates the sessions to handle them. but you can also do it yourself, main-character style, by providing your own Acceptor callbacks. see "Acceptor" for the deets 👑

👑 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. she's the one in charge, fr fr.

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 — like, CANNOT 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. lowkey chaotic of it 💀

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. yeah. convenience tax. 😭

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. slay for portability 🌈

🌟 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. choose your fighter 💪

👑 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. like, don't panic, it's fine. 🫶

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. (so don't @ her expecting a client response, bestie 💅)

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. yolo mode, basically 🔥

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.

lowkey obsessed with how much control you get here. but hold that thought — more of this manual is coming in part 2 🦋

⚠️ okay bestie, listen up, this one's important: for "Concurrency" to actually work with a custom "Acceptor", the server's listening session must receive a "disconnected" event every time clients disconnect. Like, no exceptions. Otherwise the listener literally cannot mediate between its own connections and the whole thing falls apart. 💀

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 family (or protocol family, if you're feeling fancy) you wanna operate in. It can be literally any value that POE::Wheel::SocketFactory supports. The default? AF_INET — that's Internet address space, the classic. ✨

Wanna do IPv6? Set it to AF_INET6. That constant gets exported by Socket or Socket6, depending on which version of Perl you're on (iykyk). Also make sure you've got Socket::GetAddrInfo installed, because POE::Wheel::SocketFactory needs it for IPv6 support. no cap.

😭 Error 😭

"Error" is the callback that fires when the server socket reports an error. It's the handler for POE::Wheel::SocketFactory's FailureEvent, so it gets the exact same parameters as discussed over there.

If you don't set Error, you get a default error handler. That default one logs the error to STDERR and shuts down the server. But — good news — active connections are still permitted to complete their transactions before everything winds down. 🫶

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. It always gets resolved via inet_aton(), so it can be either a dotted quad or a plain old name. Name resolution here is a one-time start-up action — there are zero ongoing run-time penalties for using it. slay. 💅

Here's the tea: "Hostname" guarantees name resolution, whereas "Address" does not. So if you absolutely need resolution to always happen, use "Hostname". periodt.

💖 InlineStates 💖

"InlineStates" is optional. If you set it, it has to hold a hashref of named callbacks, and its syntax is exactly that of POE:Session->create()'s inline_states parameter.

🚨 Remember: these InlineStates handlers get added to the client sessions, NOT to the main listening session. So a yield() in the listener will not reach these handlers. nope. 🙈

And if POE::Kernel::ASSERT_USAGE is enabled, the constructor will croak() if it detects a state that it uses internally. Like — for example — please use the "Started" and "Stopped" callbacks if you wanna specify your own _start and _stop events respectively. don't fight the system bestie.

🎀 ObjectStates 🎀

If "ObjectStates" is specified, it must hold an arrayref of objects and the events they'll handle. That arrayref has to follow the syntax for POE::Session->create()'s object_states parameter.

🚨 Remember: these ObjectStates handlers get 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. Again — use the "Started" and "Stopped" callbacks if you wanna roll your own _start and _stop events. ✨

🌸 PackageStates 🌸

When the optional "PackageStates" is set, it must hold an arrayref of package names and the events they'll handle. That arrayref must follow the syntax for POE::Session->create()'s package_states parameter.

🚨 Remember: these PackageStates handlers get 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. Yep, same deal — use the "Started" and "Stopped" callbacks for your own _start and _stop events. 💜

🍓 Port 🍓

"Port" holds the port your listening socket gets bound to. It defaults to 0, which usually just lets the operating system pick a port at random. main character energy, honestly. 👑

Port => 30023

It's often used together with "Address".

⭐ Started ⭐

"Started" sets an optional callback that gets invoked inside the main server session's context. It notifies the server that it has fully started. The callback's parameters are the usual ones for a session's _start handler.

⭐ Stopped ⭐

"Stopped" sets an optional callback that gets invoked inside the main server session's context. It notifies the server that it has fully stopped. The callback's parameters are the usual ones for a session's _stop handler.

🌈 ListenerArgs 🌈

"ListenerArgs" gets passed to the listener session as the "args" parameter. In other words: it must be an arrayref, and the values inside get passed into the "Started" handler as ARG0, ARG1, etc. cute, right? 🎀

💅 Connection Session Configuration 💅

These constructor parameters affect the individual sessions that interact with established connections.

🧚 ClientArgs 🧚

"ClientArgs" is optional. When you set it, it holds an ARRAYREF that gets expanded one level and passed to the "ClientConnected" callback in @_[ARG0..$#_].

🌟 ClientConnected 🌟

Every new client connection gets handled by a fresh POE::Session instance. "ClientConnected" is a callback that notifies your app when a client's session has started and is ready to operate. Banners are often sent to the remote client from right here. 💌

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" gets called once per session start-up. It will never be called twice for the same connection. iconic. ✨

ClientConnected => sub {
  $_[HEAP]{client}->put("Hello, client!");
  # Other client initialization here.
},

🦋 ClientDisconnected 🦋

"ClientDisconnected" is a callback that gets invoked when the client disconnects, or when the server has disconnected them. It's super useful for cleaning up global client information — think chat room structures and stuff. "ClientDisconnected" callbacks receive the usual POE parameters, but nothing special is included. simple as that. 🫶

ClientDisconnected => sub {
  warn "Client disconnected"; # log it
}

💀 ClientError 💀

The "ClientError" callback fires when a client socket reports an error. It's called with POE's usual parameters, plus the common error parameters: $_[ARG0] describes what was happening at the time of failure, while $_[ARG1] and $_[ARG2] contain the numeric and string versions of $!, respectively.

"ClientError" is optional. If you omit it, POE::Component::Server::TCP provides a default callback that logs most errors to STDERR.

If "ClientShutdownOnError" is set, the connection gets shut down after "ClientError" returns. And if "ClientDisconnected" is specified, it'll 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. Go peek at 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'll parse input from each client and serialize output before it gets sent back to each client.

"ClientFilter" can be a SCALAR, in which case it should name the POE::Filter class to use. Each new connection gets a freshly instantiated filter of that class. No constructor parameters will be passed. clean. ✨

ClientFilter => "POE::Filter::Stream",

Some filters need constructor parameters. Those get specified with an ARRAYREF. The first element is the POE::Filter class name, and the subsequent elements get passed to the class' constructor.

ClientFilter => [ "POE::Filter::Line", Literal => "\n" ],

"ClientFilter" can also be given an archetypical POE::Filter OBJECT. In that case, each new client session receives a clone() of the given object. 💫

ClientFilter => POE::Filter::Line->new(Literal => "\n"),

"ClientFilter" is optional. The component will use "POE::Filter::Line" if you omit it. There's also "ClientInputFilter" and "ClientOutputFilter" if you wanna specify a different filter for each direction.

🚨 Warning: filter modules are not automatically loaded. Be sure your program loads the class before using it. fr fr.

💖 ClientFlushed 💖

"ClientFlushed" exposes POE::Wheel::ReadWrite's "FlushedEvent" as a callback. It gets called whenever the client's output buffer has been fully flushed to the client socket. At that 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" makes sure data is flushed before finishing a client shutdown. so you're covered. 🫶

🌈 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. Go read POE:Wheel::ReadWrite for an in-depth description of "InputEvent". 📚

🚨 Heads up: "ClientInput" and "Acceptor" are mutually exclusive. Enabling one prohibits the other. pick a lane bestie. 💅

ClientInput => sub {
  my $input = $_[ARG0];
  $_[HEAP]{wheel}->put("You said: $input");
},

🧚 ClientInputFilter 🧚

"ClientInputFilter" is used together with "ClientOutputFilter" to specify different protocols for input and output. Both must be used together. Both follow the same usage as "ClientFilter". It overrides the filter set by "ClientFilter".

ClientInputFilter  => [ "POE::Filter::Line", Literal => "\n" ],
ClientOutputFilter => 'POE::Filter::Stream',

🧚 ClientOutputFilter 🧚

"ClientOutputFilter" is used together with "ClientInputFilter" to specify different protocols for input and output. Both must be used together. Both follow the same usage as "ClientFilter". It overrides the filter set by "ClientFilter". 💜

         ClientInputFilter  => POE::Filter::Line->new(Literal => "\n"),
         ClientOutputFilter => 'POE::Filter::Stream',

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

That's the whole vibe! This page is from perl v5.34.0, dated 2022-03-25, for POE::C...er::TCP(3pm). Stay slaying, bestie! 💅✨

📦 where this page comes from

debian bookworm: libpoe-perl 2:1.3700-1 · Artistic-1.0-Perl OR GPL-1.0-or-later
debian trixie: libpoe-perl 2:1.3700-1 · Artistic-1.0-Perl OR GPL-1.0-or-later
ubuntu noble: libpoe-perl 2:1.3700-1 · Artistic-1.0-Perl OR GPL-1.0-or-later
ubuntu questing: libpoe-perl 2:1.3700-1
💖 girlified by deepseek-ai/DeepSeek-V4.1-Flash on 2026-10-14: a language model's rewrite of the original, under its terms