IKC(3)

💅 IKC(3) — POE::Component::IKC

okay so bestie, grab a snack 🍓 because this is the manual page for POE::Component::IKC — that's POE Inter-Kernel Communication, and it lives in the Perl section of your man pages (User Contributed Perl Documentation, no cap). It's basically the group chat that lets one POE kernel slide into another POE kernel's DMs. Let's get into it ✨

---

🌸 NAME 🌸

POE::Component::IKC — POE Inter-Kernel Communication. that's it, that's the name, and honestly it's giving main character energy 👑

---

✨ SYNOPSIS ✨

🖥️ IKC server

so like, if you want to be the one listening, you spin up a server:

use POE::Component::IKC::Server;
# create all your sessions
POE::Component::IKC::Server->spawn(
            port=>30, name=>'Server'
    ); # more options are available
$poe_kernel->run();

(yes, the comment literally says more options are available — I'm just the messenger 🫶)

📱 IKC client

and if you're the one connecting, client vibes:

use POE::Component::IKC::Client;

POE::Component::IKC::Client->spawn(
            host=>name,
            port=>30,
            name=>'Client',
            on_connect=>\&build);
$poe_kernel->run();

sub build
{
    # create sessions that depend on the foreign kernel.
}

📮 Post a state on a foreign kernel

$kernel->post('IKC', 'post', "poe://Server/session/state", $ONE_arg);

🔁 The IKC is peer-to-peer.

like, fr fr — the server can post to the client too, nobody's gatekeeping:

$kernel->post('IKC', 'post', 'poe://Client/session/state', $ONE_arg);

📞 Call a state on a remote kernel

okay listen 😭 call semantics are impossible, because they would cause POE to block. like, structurally cannot happen. so IKC call is a bit different — it's a post, but with an extra RSVP parameter:

$kernel->post('IKC', 'call', 'poe://Server/hello/world', $ONE_arg,
              'poe:callback');

what that does is it makes the returned value of the foreign state get sent to state callback in the current session. you may want the callback to be in another session, but lowkey I don't think this is a good idea:

$kernel->post('IKC', 'call', 'poe://Server/hello/world', $ONE_arg,
              'poe:/elsewhere/hi');

💡 note: if you use ->call('IKC'), it will return the number of foreign kernels the state was sent to. handy little vibe check to find out if you're still connected to a foreign kernel 😌

🪄 A little magic

if a state is posted by a foreign kernel, $_[SENDER] is only valid during that state. but — and this is the slay part — you will be able to post back to it:

$kernel->post($_[SENDER], 'something', 'the answer is foo');

The remote caller MUST have published states for them to be callable, eh? 🤨

📢 Publish / Subscribe

you must publish a session's interface for it to be available to remote kernels. no publishing = no access, periodt.

if you subscribe to a remote session, you may access it as if it was a local session. iconic.

first, a session publishes its interfaces:

$kernel->post('IKC', 'publish', 'session_alias',
                    [qw(state1 state2 state3 state4)], );

then a foreign kernel subscribes to it:

# Look for a session on all known foreign kernels
$kernel->post('IKC', 'subscribe', [qw(poe://*/session_alias/)]);
# Look for a session on a specific foreign kernel
$kernel->post('IKC', 'subscribe', [qw(poe://Pulse/timeserver)]);
# Make sure the session has a given state
$kernel->post('IKC', 'subscribe', [qw(poe://*/timeserver/connect)]);

after subscription, a proxy session is created that can be accessed like any old session, though ->call() acts the same as ->post() for obvious reasons:

$kernel->post('poe:/Pulse/timeserver', 'state', $arg1, $arg2...);

⚠️ currently, the session alias used by post to the proxy session must be the same one as used when subscribing. and because kernels have multiple names, if you're using '*' as the kernel name when subscribing, the session alias might not be what you think it is. see "Monitor" for the deets 👀

of course, attempting to post to a proxy session before it is created will be problematic 💀. to be alerted when the proxy session is created, a callback state may be specified:

$kernel->post('IKC', 'subscribe', [qw(poe://*/timeserver)],
        'timeserver_subscribed');

the callback gets called with a list of all the sessions it managed to subscribe to. check this list before continuing — that's not optional, bestie. better yet, you could use the IKC monitor (see below).

one can also let POE::Component::IKC::Client->spawn deal with all the details:

POE::Component::IKC::Client->spawn(
        port=>31337, name=>$name,
        subscribe=>[qw(poe://*/timeserver)],
        on_connect=>\&create_me,
    );

'on_connect' is only called when all the subscriptions have either been accepted. if a subscription was refused, create_ikc_client will give up 😔. if multiple foreign kernels where quieried for a session (as is the case above), subscription is deemed to succeed if at least one foreign kernel accepts the subscription. so like, one yes is enough to be let in 🌈

to undo things:

$kernel->post(IKC=>'retract', 'session_alias'=>[qw(states)]);

$kernel->post(IKC=>'unsubscribe', [qw(poe://Pulse/timeserver)]);

👁️ Monitor

say you wanted to monitor all remote kernels that connect to you:

$kernel->post(IKC=>'monitor', '*'=>{register=>'some_event'});

sub some_event
{
    my($name, $real)=@_[ARG1, ARG2];
    print "- Remote kernel ", ($real ? '' : "alias "), "$name connected\n";
}

later, you want to know when a given remote session disconnects:

$kernel->post(IKC=>'monitor', some_kernel=>{unregister=>'bye_bye'});

or maybe you think a session should clean up and leave whenever IKC does:

$kernel->post(IKC=>'monitor', '*'=>{shutdown=>'other_event'});

sub other_event
{
    # kill wheels, alarms, selects and aliases here
}

see "monitor" in POE::Component::IKC::Responder for more details 🫶

🚪 Shutdown

when you feel the time is right and you want to get rid of all IKC-related sessions, just do the following:

$kernel->post(IKC=>'shutdown');

and they should all disapear. at worst, some will still have registered alises, but this won't prevent the kernel from exiting. so like, worst case is cosmetic 💅

🏠 The local kernel

you can post to the local kernel as if it was remote:

$kernel->post(IKC=>'post',
                "poe://$kernel->ID/session/state"=>$ONE_arg);

however, you can't currently subscribe to local sessions. I don't know how I'm going to resolve this. 🙈 (that's the docs talking, not me — I'm just relaying the whole thing.)

---

🦋 DESCRIPTION 🦋

This is Inter-Kernel Communication for POE. It is used to get events from one POE kernel to another. that's the whole thing. events. kernel to kernel. no cap ✨

---

🌟 SEE ALSO 🌟

• POE::Component::IKC::Responder — Heart of the system 💖
• POE::Component::IKC::Server — Create a process that listens for other kernels.
• POE::Component::IKC::Client — Create a process that connects to other kernels.
• POE::Component::IKC::ClientLite — Light weight IKC implementation for places you can't use POE, such as mod_perl.
• POE::Component::IKC::Channel — Handle communcation with other kernels.
• POE::Component::IKC::Proxy — Proxy session that is created when you subscribe to a remote session.
• POE::Component::IKC::Freezer — Pure-Perl serialization method.
• POE::Component::IKC::Specifier — Helper routines for parsing IKC specifiers.

---

👑 AUTHOR 👑

Philip Gwyn <perl-ikc at pied.nu> — the icon who made all this happen 🫶

---

🎀 COPYRIGHT AND LICENSE 🎀

Copyright 1999-2014 by Philip Gwyn. All rights reserved.

This library is free software; you can redistribute it and/or modify it under the same terms as Perl itself.

See <http://www.perl.com/language/misc/Artistic.html>

---

and that's the whole page, bestie 💖 mwah 💋 this was perl v5.42.0, dated 2025-12-14, filed under IKC(3) — go forth and let your kernels talk to each other 🦋✨