> > As I am redesigning PoCo::Server::HTTP wanted to make
> > PoCo::Server::HTTP a subclass of of Poco::S::TCP.
> >
> > Currently this is impossible so I end up having two sessions, one
> > which handles the new socket and one which handles the request, this
> > is inefficent at best.
> >
> > So I propose that PC::S::TCP has a constructor argument which is
> > called inside it's _start.
> >
> > POE::Component::Server::TCP->new( Port => $self->{Port}, Acceptor =>
> > sub {}, Constructor => {});
>
> This is a good idea, and it might be possible to extend it so that
> arbirtrary states could be defined.  I also like the one where
> Server::TCP encapsulates simple client ReadWrite sessions, so for most
> cases all you need are constructor arguments and a client input
> handler.

Hmm... I was just reviewing this last nite...

The flow as I understand it (warning, gaping holes alert!) is:

A new session is created.  it's WHOLE start method is to set an alias for
itself (optional) and yield() it's "constructor".

The constructor state spawns a PC:S:TCP, with 1) SOCKET parameters, 2) ERROR
handler, and 3) the identity of a NEW SESSION to spawn PER CONNECTION.

"constructor" => sub {
    POE::Component::Server::TCP->new
        ( Port     => 30003,
          # Address  => '127.0.0.1',
          Acceptor => sub {
              my ($socket, $peer_addr, $peer_port) = @_[ARG0, ARG1, ARG2];
              log_debug( "Server::TCP received a connection.\n" ) if DEBUG;
              # spawn the server session
              ServerSession->new($socket, $peer_addr, $peer_port);
          },

          Error => sub {
              # ...
              }
        ); # S::TCP::new
}
OK, so the Server::TCP has that part handled.  There is no significant
difference between that one and my webserver session.

I'll mention my UDP server in a second.

SO each TCP server enters the new() argument for my (package based) servers,
to handle a single connection (session).  Maybe I should rename new() to
connected(), so that the method names are mnemonic instead of "classic?"

[unrelated side note:  ever notice that as a programmer, it now feels weird
to put the sentence-ending punctuation mark INSIDE the closing quote, as is
correct in English? :-]

And now each of my server sessions begins its life by creating a wheel (in
my mind it's like a water-wheel), powered by the socket that now exists
courtesy S::TCP.  And the wheels, again simply, understand "heard
something," "said something," and "oops."

One of these days, I'd love to really understand... no... the word I learned
in church is "ramah" (sp?), where the teaching on the paper (logos) becomes
revelation in your heart (ramah) and is now a part of you.
Anyway, I'd love to get the ramah of dynamically assigning states.  That
*would* be appropriate for the wheel, right?

OK, so I see now a basic template for a TCP server, that includes all of the
elements needed to run in POE... if any pieces are missing in this, then
help me to understand, PLEASE!


My UDP server is slightly different, and I think it accurately reflects the
differences between TCP/UDP without hurting the above mental image too much.


Instead of using S::TCP to create the sockets and then deal with them, my
UDP server just comes into being (CountBouncer->new())... and new() just
wraps POE::Session->new() anyway... should we call it spawn()? :-).

But _start, instead of a wheel wrapped around a new, connected socket, is a
wheel wrapped around a LISTENING socket.  Big difference here.  Incoming
messages are all handled by the same state... or, incoming messages all
trigger the same event:

sub got_socket {
    delete $heap->{wheel};
    $heap->{socket_handle} = $socket;
    $kernel->select_read( $socket, 'got_message' );
}

But... but... ?? I wrote it months ago, after stealing it from the examples,
and now I'm *really* confused.  How can I delete the wheel (which started
this chain of events) and still accept incoming UDP messages, unless I've
transparently spawned a new POE::Session??

And if I've transparently spawned a transparent session, then why isn't
there a S::UDP written around this model?

And aren't Wheels just wrappers around select_read() in the first place????

There it goes again... I start thinking outside the box and suddenly it
seems I don't understand nearly as well as I'd hoped. <sigh>

L8r,
Rob

#!/usr/bin/perl -w
use Disclaimer qw/:standard/;


Reply via email to