RE: Server pinging
Hmm... poe.perl.org appears to be down right now. Bummer. - MW -Original Message- From: Rocco Caputo [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 06, 2001 8:39 PM To: Peter Scott; [EMAIL PROTECTED]; Wilkinson, Mike Subject: RE: Server pinging On Tue, 6 Mar 2001 09:38:53 -0700, Wilkinson, Mike wrote: >Actually, I've been reading this thread with interest as well. I'm >attempting to do something similar with POE. The biggest problem for me is >that I'm from an EE background, where state machines are defined more by the >transitions than what a state contains, and this appears to be more the >other way around. There seem to be two flavors of state machine: ones that produce output for each transition (http://hissa.nist.gov/dads/HTML/mealyMachine.html) and ones that do the same for each state (http://hissa.nist.gov/dads/HTML/mooreMachine.html). Have you looked at POE::NFA? It's an imperfect attempt at a classical nondeterministic state machine. At its worst, it shows that POE::Kernel can drive different kinds of state machines. -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
RE: Server pinging
On Tue, 6 Mar 2001 09:38:53 -0700, Wilkinson, Mike wrote: >Actually, I've been reading this thread with interest as well. I'm >attempting to do something similar with POE. The biggest problem for me is >that I'm from an EE background, where state machines are defined more by the >transitions than what a state contains, and this appears to be more the >other way around. There seem to be two flavors of state machine: ones that produce output for each transition (http://hissa.nist.gov/dads/HTML/mealyMachine.html) and ones that do the same for each state (http://hissa.nist.gov/dads/HTML/mooreMachine.html). Have you looked at POE::NFA? It's an imperfect attempt at a classical nondeterministic state machine. At its worst, it shows that POE::Kernel can drive different kinds of state machines. -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
Re: Server pinging
> "Rocco" == Rocco Caputo <[EMAIL PROTECTED]> writes: Rocco> On Mon, 05 Mar 2001 19:31:31 -0800, Peter Scott wrote: >> I had been in the process of trying to grok the >> socketfactory.perl example per Torvald's suggestion. Is there >> a need for a POE::Component::Client::TCP on CPAN that would >> basically be the InetTcpClient package from there? Rocco> If a generic TCP client materializes, I'd like to include Rocco> it in POE's distribution. Like Rocco> POE::Component::Server::TCP, it would be widely useful. Maybe there should be a POE modules list akin to the Apache modules list (http://perl.apache.org/src/apache-modlist.html) that tracks just POE related modules (::Component and otherwise)? That way we could also keep track of ideas and things that people are working on that haven't made it to CPAN yet (like the POE::Component::SOAP::Server::TCP and friends that I'm piddling with). -- Fletch| "If you find my answers frightening, __`'/| [EMAIL PROTECTED] | Vincent, you should cease askin' \ o.O' 770 933-0600 x211(w) | scary questions." -- Jules=(___)= | U
Re: Server pinging
At 08:37 AM 3/6/01 -0500, Rocco Caputo wrote: >On Mon, 05 Mar 2001 19:31:31 -0800, Peter Scott wrote: > > > >I had been in the process of trying to grok the socketfactory.perl example > >per Torvald's suggestion. Is there a need for a > >POE::Component::Client::TCP on CPAN that would basically be the > >InetTcpClient package from there? > >If a generic TCP client materializes, I'd like to include it in >POE's distribution. Like POE::Component::Server::TCP, it would >be widely useful. Okay, I will make it a goal to understand this well enough to create such a thing. If anyone else was planning on doing it, though, please go ahead, don't wait on me :-) -- Peter Scott Pacific Systems Design Technologies
RE: Server pinging
Actually, I've been reading this thread with interest as well. I'm
attempting to do something similar with POE. The biggest problem for me is
that I'm from an EE background, where state machines are defined more by the
transitions than what a state contains, and this appears to be more the
other way around.
- MW
-Original Message-
From: Rocco Caputo [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, March 06, 2001 6:33 AM
To: Peter Scott; [EMAIL PROTECTED]
Subject: Re: Server pinging
On Mon, 05 Mar 2001 23:45:06 -0800, Peter Scott wrote:
[ In reference to the code in <[EMAIL PROTECTED]> ]
>May I ask a few questions about the code? I'm copying the list in case
>someone here is keeping up with it. I'm just trying to get this under my
>belt. I have been reading the documentation really thoroughly, believe
>me. In fact I had another five questions here which I've managed to delete
>through sufficient reading.
>
>The reason for putting the new SocketFactory on the heap in
>$heap->{connector} is to keep it alive, is that right? Otherwise if the
>return value were stored in something that went out of scope too soon,
e.g.,
>
> my $connector = POE::Wheel::SocketFactory->new
>
>instead of
>
> $heap->{connector} = ...
>
>then the SocketFactory would be destroyed and its _stop state called when
>the current routine returned, do I have that right?
This is partially true. The SocketFactory (and the other Wheel
subclasses) works in some ways like a plain Perl object, and its
DESTROY method is called when it goes out of scope. Since a heap
persists as long as its Session instance, saving the SocketFactory
reference there ensures that it won't accidentally go out of scope.
It's also partly false. See the next session for more information
about Session destruction.
>The fail() method ends by clearing any pending timeouts. Since you've just
>deleted the reference to its session in $heap->{connector}, what would
>happen if you didn't clear them? Could a timeout be delivered to a
>nonexistent session? The _stop state of the session (if there were one)
>would get called as soon as the fail() method returns,
>right? Doesn't/shouldn't this clear any pending timeouts?
No, the Session would linger until the timeouts became due.
Generally speaking, POE::Kernel tracks six resources used by every
Session. A Session is stopped automatically when all six of its
resource counts drop to zero. Here's a complete list of resources
that affect a Session's reference counts:
Plain events
Pending timers
Child sessions
Selected filehandles
Aliases
"Extra" references
I say "generally speaking" because Sessions are sometimes destroyed
when they still have resources allocated. Consider signals and
similar things. In those cases, POE::Kernel knows the resources are
still active, and it cleans them up as best it can on behalf of the
departed Sessions.
So, no, you need to clear the timer explicitly. In fact, I hadn't
done that to start with, and the pop3 checker always failed with a
timeout.
I've done my job if your net confusion has dropped.
-- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
Re: Server pinging
On Mon, 05 Mar 2001 19:31:31 -0800, Peter Scott wrote: > >I had been in the process of trying to grok the socketfactory.perl example >per Torvald's suggestion. Is there a need for a >POE::Component::Client::TCP on CPAN that would basically be the >InetTcpClient package from there? If a generic TCP client materializes, I'd like to include it in POE's distribution. Like POE::Component::Server::TCP, it would be widely useful. -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
Re: Server pinging
On Mon, 05 Mar 2001 23:45:06 -0800, Peter Scott wrote:
[ In reference to the code in <[EMAIL PROTECTED]> ]
>May I ask a few questions about the code? I'm copying the list in case
>someone here is keeping up with it. I'm just trying to get this under my
>belt. I have been reading the documentation really thoroughly, believe
>me. In fact I had another five questions here which I've managed to delete
>through sufficient reading.
>
>The reason for putting the new SocketFactory on the heap in
>$heap->{connector} is to keep it alive, is that right? Otherwise if the
>return value were stored in something that went out of scope too soon, e.g.,
>
> my $connector = POE::Wheel::SocketFactory->new
>
>instead of
>
> $heap->{connector} = ...
>
>then the SocketFactory would be destroyed and its _stop state called when
>the current routine returned, do I have that right?
This is partially true. The SocketFactory (and the other Wheel
subclasses) works in some ways like a plain Perl object, and its
DESTROY method is called when it goes out of scope. Since a heap
persists as long as its Session instance, saving the SocketFactory
reference there ensures that it won't accidentally go out of scope.
It's also partly false. See the next session for more information
about Session destruction.
>The fail() method ends by clearing any pending timeouts. Since you've just
>deleted the reference to its session in $heap->{connector}, what would
>happen if you didn't clear them? Could a timeout be delivered to a
>nonexistent session? The _stop state of the session (if there were one)
>would get called as soon as the fail() method returns,
>right? Doesn't/shouldn't this clear any pending timeouts?
No, the Session would linger until the timeouts became due.
Generally speaking, POE::Kernel tracks six resources used by every
Session. A Session is stopped automatically when all six of its
resource counts drop to zero. Here's a complete list of resources
that affect a Session's reference counts:
Plain events
Pending timers
Child sessions
Selected filehandles
Aliases
"Extra" references
I say "generally speaking" because Sessions are sometimes destroyed
when they still have resources allocated. Consider signals and
similar things. In those cases, POE::Kernel knows the resources are
still active, and it cleans them up as best it can on behalf of the
departed Sessions.
So, no, you need to clear the timer explicitly. In fact, I hadn't
done that to start with, and the pop3 checker always failed with a
timeout.
I've done my job if your net confusion has dropped.
-- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
Re: Server pinging
At 10:44 PM 3/2/01 -0500, Rocco Caputo wrote:
>On Thu, 01 Mar 2001 23:15:44 -0800, Peter Scott wrote:
>
> >I'm constructing a daemon to respond to user questions about various
> >services, e.g., is sendmail on such-and-such host working, is the web
> >server on another host working, etc; I just came across POE and it looks
> >ideal.
>Here's one way to do it. Mind you, this is just a client thing. It
>doesn't include the daemon bits you'll need to handle users' requests,
>but most of it should be self-contained enough to work unmodified in
>a server. I hope you find it useful.
May I ask a few questions about the code? I'm copying the list in case
someone here is keeping up with it. I'm just trying to get this under my
belt. I have been reading the documentation really thoroughly, believe
me. In fact I had another five questions here which I've managed to delete
through sufficient reading.
The reason for putting the new SocketFactory on the heap in
$heap->{connector} is to keep it alive, is that right? Otherwise if the
return value were stored in something that went out of scope too soon, e.g.,
my $connector = POE::Wheel::SocketFactory->new
instead of
$heap->{connector} = ...
then the SocketFactory would be destroyed and its _stop state called when
the current routine returned, do I have that right?
The fail() method ends by clearing any pending timeouts. Since you've just
deleted the reference to its session in $heap->{connector}, what would
happen if you didn't clear them? Could a timeout be delivered to a
nonexistent session? The _stop state of the session (if there were one)
would get called as soon as the fail() method returns,
right? Doesn't/shouldn't this clear any pending timeouts?
I *think* I understand the rest! It's a far cry from that to being able to
write it in the first place, but ya gotta start somewhere...
Thanks!!!
--
Peter Scott
Pacific Systems Design Technologies
Re: Server pinging
At 10:44 PM 3/2/01 -0500, Rocco Caputo wrote: >On Thu, 01 Mar 2001 23:15:44 -0800, Peter Scott wrote: > > >I'm constructing a daemon to respond to user questions about various > >services, e.g., is sendmail on such-and-such host working, is the web > >server on another host working, etc; I just came across POE and it looks > >ideal. > > > >What I'm wondering is, what class should I use for testing these > >services? I'm still trying to sort out Drivers from Wheels from Filters, > >and what I want is the ability to fire off a session that will attempt to > >connect to port 25 or 80 or whatever, then do a simple transaction in the > >appropriate protocol. > > > >Because the whole point of the program is that those actions may take a > >long time, I need to be able to get on with other stuff while I'm waiting > >for them either to complete or timeout. Again, an event-driven model looks > >right. So for writing something like this, what's the appropriate class to > >start out with for the part that has to go off to this other > >machine? Another example would be, say, pinging port 110 and checking that > >it answers a POP command. The POE documentation appears mostly geared > >towards how to listen for a connection rather than how to open one. > > >Here's one way to do it. Mind you, this is just a client thing. It >doesn't include the daemon bits you'll need to handle users' requests, >but most of it should be self-contained enough to work unmodified in >a server. I hope you find it useful. [528 lines of code deleted] My G*d, I never expected you to do my homework for me! Thank you, this puts me lightyears ahead in my understanding of POE. I had been in the process of trying to grok the socketfactory.perl example per Torvald's suggestion. Is there a need for a POE::Component::Client::TCP on CPAN that would basically be the InetTcpClient package from there? -- Peter Scott Pacific Systems Design Technologies
Re: Server pinging
On Thu, 01 Mar 2001 23:15:44 -0800, Peter Scott wrote:
>I'm constructing a daemon to respond to user questions about various
>services, e.g., is sendmail on such-and-such host working, is the web
>server on another host working, etc; I just came across POE and it looks
>ideal.
>
>What I'm wondering is, what class should I use for testing these
>services? I'm still trying to sort out Drivers from Wheels from Filters,
>and what I want is the ability to fire off a session that will attempt to
>connect to port 25 or 80 or whatever, then do a simple transaction in the
>appropriate protocol.
>
>Because the whole point of the program is that those actions may take a
>long time, I need to be able to get on with other stuff while I'm waiting
>for them either to complete or timeout. Again, an event-driven model looks
>right. So for writing something like this, what's the appropriate class to
>start out with for the part that has to go off to this other
>machine? Another example would be, say, pinging port 110 and checking that
>it answers a POP command. The POE documentation appears mostly geared
>towards how to listen for a connection rather than how to open one.
Here's one way to do it. Mind you, this is just a client thing. It
doesn't include the daemon bits you'll need to handle users' requests,
but most of it should be self-contained enough to work unmodified in
a server. I hope you find it useful.
-- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
#!/usr/bin/perl -w
# This program is Copyright 2001 by Rocco Caputo. All rights reserved.
# You may use, modify and/or distribute it under the same terms as Perl
# itself.
use strict;
use lib '/home/troc/perl/poe';
use POE qw( Wheel::SocketFactory Wheel::ReadWrite Driver::SysRW Filter::Line );
###
# A generic service checker.
package Checker;
use strict;
use Carp qw(croak);
use POE::Kernel; # Imports $poe_kernel.
use POE::Session; # Imports session parameter offsets, like HEAP.
# "Spawn" a checker. This creates a POE session to connect to a
# service and check it according to a simple script. The exact script
# is determined in Checker's subclasses.
sub spawn {
my $package = shift;
# Validate parameters. Subclassed checkers should validate their
# service-dependent parameters.
my %args = @_;
foreach my $param (qw(host port)) {
croak "$package needs a '$param' parameter" unless exists $args{$param};
}
# Create a POE session to actually check the service. This is the
# equivalent of spawning a process or thread to do the work. The
# POE::Session constructor maps event names to their handlers. In
# this case, since we're subclassing Checker, we'll use package
# states. POE will invoke these in the usual Perl way,
# Chandler_start( ... )>, which means the @ISA
# inheritance chain is followed if Checker::Something doesn't
# implement &handler_start.
POE::Session->create
( package_states =>
[ $package =>
{ _start=> 'handler_start',
connect_succeeded => 'handler_connect_success',
connect_failed=> 'handler_connect_failure',
got_input => 'handler_input',
got_timeout => 'handler_timeout',
got_error => 'handler_error',
},
],
# Pass spawn's arguments to the _start event handler. See the
# notes for &handler_start next.
args => [ %args ],
);
}
# The _start handler is called immediately when a session is created.
# In this case, it's when a Checker subclass is spawned. The spawn()
# method passes its paramters to the _start handler through
#
# args => [ %args ]
#
# In the POE::Session->create() parameters. See &spawn.
#
# These arguments are used to create a postback. A postback is a
# plain code reference which, when called, posts a POE event. It does
# other magic, some of which will be covered later.
sub handler_start {
my $heap = $_[HEAP];
my %args = @_[ARG0..$#_];
# Store the parameters in this session's heap. Each session has a
# separate heap, so this Checker has different C than all the
# others.
$heap->{args} = \%args;
# Create a postback. This is used to post a response back to the
# parent session.
$heap->{postback} = $_[SENDER]->postback( status => %args );
# Start a socket factory. This will establish a connection (or
# not). The important part is that it won't block; the connection
# will occur (or not) in the background, and either a "success" or a
# "failure" event will be emitted when the socket's status is known.
$heap->{connector} =
POE::Wheel::SocketFactory->new
( RemoteAddress => $heap->{args}->{host}, # Connect to this host.
RemotePort=> $heap->{args}->{port}, # Connect to this port.
SuccessState => 'connect_succeeded', # Emit this event on success.
Failur
