POE状态机入门与进阶

一．前言

至于POE的应用，我不想多说什么，因为需要使用状态机的地方太多。
举一个极端的例子，windows下的perl-tk对于多线程的支持极不稳定，如果在其中加入一个大数据量的处理应用，
结果往往会是一个无法动弹的程序。这时除了使用POE，也许没有更好的解决办法了。
另外，python中有叫twisted的类似框架，被广泛地应用在网络服务中，
具体的使用方法可以参考Oreilly出版的《Python Twisted Network Programming Essentials》。
某种意义上，也说明了状态机的重要性。

二．基本原理与概念
在详细说明POE服务器的建立步骤之前，需要对POE的原理做一个大致的了解。
在这个阶段中，我们将描述这方面的不同概念，以及它们在POE中的应用。

1. 事件与事件句柄
POE 是一个为网络工作和并行任务服务的事件驱动框架。
首先作为前提，需要掌握事件和事件驱动编程的意义。
在抽象意义上，事件就是真实世界中发生的一件事情。
比如说：早晨打铃、面包从烤机里弹出、茶煮好了等。而在用户界面上最常见的事件则是鼠标移动、按钮点击和键盘敲打等等。
具体到程序软件事件，则往往是一些抽象的事件。
也就是说，它不仅包括了发送给程序的外部活动，而且也包括了一些在操作系统内部运行的事件。
比如说，计时器到点了，socket建立了连接，下载完成等。
在事件驱动程序中，中心分配器的作用是将事件分配给不同的处理程序。
这些处理程序就是事件句柄，顾名思义，它们的任务就是处理相应事件。
POE的事件句柄之间的关系是合作性质的。
没有两个句柄会同时运行，每一个句柄在被激发运行期间将独占程序。
通过尽可能快地返回来保证程序的其它部分得以顺畅运行，这就是事件句柄之间的合作方式。

2. POE程序的组成部分
最简单的POE程序包括两个模块和一些用户代码：它们分别是POE::Kernel，POE::Session以及一些事件句柄。

a. POE::Kernel：
POE::Kernel提供了基于事件的操作系统核心服务。
包括I/O事件、警报和其它计时事件、信号事件和一些不被人意识到的事件。
POE::Kernel提供不同的方法对这些事件进行设置，比如select_read(), delay()和sig()。
POE::Kernel还能够跟踪事件发生源和与之相关的任务之间的关系。
之所以能够这么做，是因为当事件发生时，它将跟踪哪个任务被激活了。
于是它便知道了哪个任务调用方法来使用了这些资源，而这些都是自动完成的。
POE::Kernel也知道何事需将任务销毁。它检测任务以确定是否还有事件需要处理，或者是哪个事需要释放占用的资源。当任务没有事件可以触发的时候，POE::Kernel就自动销毁该资源。
POE::Kernel会在最后一个session停止以后终止运行。

b. POE::Session：
POE::Session实例就是上面所讲的由POE::Kernel管理的“任务”。（以下的章节中为了便于识别将使用“session”）
每一个session都有一个自己私有的存储空间，叫“heap”。存储在当前session的heap中的数据很难被一个外部session得到。
每一个session还拥有自己的资源和事件句柄。这些资源为拥有它们的session生成事件，而事件只被指派到其所处的session中。
举例说明，有多个session都可以设置相同的警报，并且任何一个都能接受其所请求的计时事件。
但所有其他session不会在意发生在它们之外的事情。

c. 事件句柄：
事件句柄就是Perl程序。
它们因为使用了POE::Kernel传递的参数而不同于一般的perl程序。
POE::Kernel是通过@_来传递参数。该数组的前七个成员定义了发生该事件的session的上下文。
它包括了一个指向POE::Kernel运行实例的引用、事件自身的名字、指向私有heap的引用以及指向发出事件的session的引用。
@_中剩下的成员属于事件自身，其中的具体内容依照被指派的事件类型而定。
举例说明：对于I/O事件，包括两个参数：一个是缓冲文件句柄，另一个是用来说明采取何种行为（input、output或者异常）的标记。

POE不强求程序员为每一个事件句柄分配所有的参数，要不然这将变成一件非常烦人的工作，因为它们中的一些参数是不常被用到的。
而POE::Session会自动为@_输出剩余的常量，这样就能使我们相对比较轻松地将注意力放在重要的参数上，而让POE来处理不必需的参数。
POE还允许改变参数的顺序和数量，而不会对程序造成影响。
比如说，KERNEL，HEAP和ARG0分别是 POE::Kernel实例、当前session的堆栈和事件的第一个用户参数。
它们可以一个个直接从@_被导出。
my $kernel = $_[KERNEL];
my $heap = $_[HEAP];
my $thingy = $_[ARG0];

或者一次性以队列片段的形式赋值给程序参数。
my ( $kernel, $heap, $thingy ) = @_[KERNEL, HEAP, ARG0];

当然在事件句柄中我们也可以直接使用$_[KERNEL]，$_[HEAP]和$_[AG0]。
但是因为诸如ARG0的参数很难从字面上知道它在事件中代表的真实意义, 所以我们不提倡直接使用这种做法。

三．简单的POE例子
现在大致知道了POE编程的概念，我们将举若干例子来了解它到底是怎么运行的。

1. 一个单session的例子
简单的POE程序包括三个部分：
 一个用来加载模块和配置条件的前端，
 初始化并且运行一个或者多个session的主体
 和用来描述事件句柄的具体程序。

a. 前端：
#!/usr/bin/perl

use warnings;
use strict;
use POE;

引入POE模块的过程的背后隐藏了一些细节，
事实上这么做还加载了一些诸如POE::Kernel和POE:Sesson的模块并相应地做了一些初始化，而通常在每个POE程序中我们都会用到这些隐藏模块。
在POE::Kernel第一次被引入时，它生成了一个将贯穿整个程序POE::Kernel实例。
POE::Session会根据不同的事件输出默认常量给事件句柄的某些参数，如：KERNEL，HEAP，ARG0等等。
所以一个简单的use POE为程序做了大量的初始化工作。

b. 主体session：
当所有的条件都准备好之后，为了保证POE::Kernel的有效运行，我们必须建立至少一个session。不然的话，运行程序意味着无事可做。
在这个例子里，我们将建立一个包含_start，_stop和count这三个事件的任务。
POE::Session将每个事件与一个句柄联系在一起。

POE::Session->create{
    Inline_states => {
        _start => \&session_start,
        _stop => \&session_stop,
        count => \&session_count,
    }
};

前两个事件是由POE::Kernel自身所提供的。它们分别表示该session的启动和销毁。
最后一个事件是用户自定义事件，它被用于程序的逻辑之中。
我们之所以没有为session保留一个引用的原因是因为该session会自动被注册到POE::Kernel中，并接收它的管理，
而我们在程序是很少直接使用该session的。

事实上，保存一个session的应用是存在危险的。
因为如果存在显式的引用，Perl将不会自动销毁session对象或者重新为其分配内存。

接着我们启动POE::Kernel，由此便建立了一个用来探测并分派事件的主循环。
在此示例程序中，为了使运行结果更加明确，我们将注明POE::Kernel运行的开始处和结束点。

print “Starting POE::Kernel.\n”;
POE::Kernel->run();
print “POE::Kernle’s run method returned.\n”;
exit;

Kernel的run方法只有在所有session返回之后才会停止循环。
之后，我们调用一个表示程序结束的提示符的exit系统方法来表示程序被终止，而在实际的应用中这么做是不必要的。

c. 事件句柄：
下面我们来了解一下事件句柄的应用，首先从_start开始。
_start的句柄将在sesson初始化完成之后开始运行，session在其自身的上下文中使用它来实现输入引导。
比如初始化heap中的值，或者分配一些必要的资源等等。

在该句柄中我们建立了一个累加器，并且发出了“count”事件以触发相应的事件句柄。

sub session_start {
    print "Session ", $_[SESSION]->ID, " has started.\n";
    $_[HEAP]->{count} = 0;
    $_[KERNEL]->yield("count");
}

一些熟悉线程编程的人可能会对yield方法在这里的使用产生困惑。
事实上，它并不是用来中止session运行的，而是将一个事件放入fifo分派队列的末尾处，
当队列中在其之前的事件被处理完毕之后，该事件将被触发以运行相应的事件句柄。
这个概念在多任务环境下更容易被理解。我们可以通过在调用yield方法之后立即返回的办法，来清晰地体现yield方法的行为。

接下来的是_stop句柄。POE::Kernel将在所有session再无事件可触发之后，并且是在自身被销毁之前调用它。

sub session_stop {
    print "Session ", $_[SESSION]->ID, " has stopped.\n";
}

在_stop中设置一个事件是无用的。
销毁session的过程本身包括清理与之相关的资源，而事件就是资源的组成部分。
所以对于所有在_stop中的事件，在其能够被分派之前都是将被清理的。

最后讲一下count事件句柄。
该函数用来增加heap中的累加器计数，并打印累加结果。我们可以使用一个while来完成这件工作，
​但是用yield方法一来可以使得程序更短小精悍，二来还能够加深对POE事件处理原理的理解。
sub session_count {
    my ( $kernel, $heap ) = @_[ KERNEL, HEAP ];
    my $session_id = $_[SESSION]->ID;

    my $count = ++$heap->{count};
    print "Session $session_id has counted to $count.\n";

    $kernel->yield("count") if $count < 10;
}
​
该函数的最后一句表示：
​只要累加器计数未超过10，session将再yield一个count事件。
​
​因为不断地触发了session_count句柄，使得当前session可以继续得以生存而不会被POE::Kernel清理。
当计数器到10时，便不再调用yield命令，session也将停止。
​一旦POE::Kernel检测到该session再没有事件句柄可被激发，便在调用_stop事件句柄之后将其清理销毁。
​
以下是运行的结果：
  Session 2 has started.
  Starting POE::Kernel.
  Session 2 has counted to 1.
  Session 2 has counted to 2.
  Session 2 has counted to 3.
  Session 2 has counted to 4.
  Session 2 has counted to 5.
  Session 2 has counted to 6.
  Session 2 has counted to 7.
  Session 2 has counted to 8.
  Session 2 has counted to 9.
  Session 2 has counted to 10.
  Session 2 has stopped.
  POE::Kernel's run() method returned.
​
对于该结果有几点需要解释一下。
A. 为什么在运行结果中session的id是2?
​      因为通常情况下，POE::Kernel是最先被创建的，它的id号会是1。接下来创建session的id号依次被累加。
​B. 为什么_start事件在kernel运行之前?
    因为当运行POE::Session->create时就会分派_start事件，所以_start事件句柄的激发是在POE::Kernel运行之前的。
C. 为什么_strart事件之后的count事件没有立即处理?    
​    第一个count事件句柄并没有被立即处理。这是因为该事件被Kernel放入了分派队列之中。
D. Session停止的原因有哪些?  
​    导致session停止的原因除了再没有事件可触发而之外，外部的终止信号也可以用来停止session。

2．多任务的POE例子
可以将以上的这个计数程序做成多任务的形式，使每一个session将在其自身的heap中保存累加器。
​各个session的事件被依次传送到POE::Kernel的事件队列中，并以先进先出的形式进行处理，以保证这些事件将轮流被执行。
为了演示这个结果，我们将复制以上程序中的session部分，其它部分保持原样不变。
​
for ( 1 .. 2 ) {
    POE::Session->create(
        inline_states => {
            _start => \&session_start,
            _stop  => \&session_stop,
            count  => \&session_count,
          }
    );
}
​
以下便是修改后的程序的运行结果：
  Session 2 has started.
  Session 3 has started.
  Starting POE::Kernel.
  Session 2 has counted to 1.
  Session 3 has counted to 1.
  Session 2 has counted to 2.
  Session 3 has counted to 2.
  Session 2 has counted to 3.
  Session 3 has counted to 3.
  Session 2 has counted to 4.
  Session 3 has counted to 4.
  Session 2 has counted to 5.
  Session 3 has counted to 5.
  Session 2 has counted to 6.
  Session 3 has counted to 6.
  Session 2 has counted to 7.
  Session 3 has counted to 7.
  Session 2 has counted to 8.
  Session 3 has counted to 8.
  Session 2 has counted to 9.
  Session 3 has counted to 9.
  Session 2 has counted to 10.
  Session 2 has stopped.
  Session 3 has counted to 10.
  Session 3 has stopped.
  POE::Kernel's run() method returned.
​
每一个session是在自身heap中保存计数数据的，这与我们建立的session实例数量无关。
​POE轮次处理每一个事件，每次只有一个事件句柄被运行。
​当事件句柄运行的时候，POE::Kernel自身也将被中断，在事件句柄返回之前，没有事件被分派。
当各个session的事件被传送到主程序事件队列后，位于队列头部的事件被首先处理，新来的事件将被放置在队列的尾部。
​以此保证队列的轮次处理。
​ POE::Kernek的run方法在最后一个session停止之后返回。

四．回声服务器
最后我们将用IO::Select建立一个非派生的回声服务器，然后再利用多个抽象层的概念将它移植到POE上。

1. 一个简单的select()服务器
这个非派生的服务器的原型来自于《Perl Cookbook》中的17.13章节。
​为了保持简洁并且也是为了更方便于移植到POE上，对其做了一些修改。
​同时为了增加可读性，还给该服务器设定一些小的目的和功能。
首先，需要引入所需的模块并初始化一些数据结构。
​
#!/usr/bin/perl

use warnings;
use strict;

use IO::Socket;
use IO::Select;
use Tie::RefHash;

my %inbuffer  = ();
my %outbuffer = ();
my %ready = ();

tie %ready, "Tie::RefHash";
​
接下来，我们要建立一个服务器socket。为了不阻塞单进程的服务器，这个socket被设置为非阻塞状态。
​
my $server = IO::Socket::INET->new
  ( LocalPort => 12345,
    Listen => 10,
  ) or die "can't make server socket: $@\n";

$server->blocking(0);
​
然后建立主循环。
​我们制造一个IO::Socket对象用以监视socket上的活动。
​无论何时，当有一个事件发生在socket上，都会有相应的程序来处理它。
​
my $select = IO::Select->new($server);

while (1) {
    foreach my $client ( $select->can_read(1) ) {
        handle_read($client);
    }

    foreach my $client ( keys %ready ) {
        foreach my $request ( @{ $ready{$client} } ) {
            print "Got request: $request";
            $outbuffer{$client} .= $request;
        }
        delete $ready{$client};
    }

    foreach my $client ( $select->can_write(1) ) {
        handle_write($client);
    }
}

exit;
​
以上的主循环对整个程序做了一个大致的总结。
​下面是用于处理socket不同行为的几个函数:
第一个函数用来处理可读状态的socket。
​     如果这个准备就绪的socket是服务器的socket，我们再接收一个新的连接，并将它注册到IO::Socket对象中。
​     如果这是一个存在输入数据的客户端socket，我们读取数据并对其进行处理，并将处理的结果添加到%ready数据结构中。
​     主循环会捕获在%ready中的数据，并将它们回传给客户端。
​
sub handle_read {
    my $client = shift;

    if ( $client == $server ) {
        my $new_client = $server->accept();
        $new_client->blocking(0);
        $select->add($new_client);
        return;
    }

    my $data = "";
    my $rv   = $client->recv( $data, POSIX::BUFSIZ, 0 );

    unless ( defined($rv) and length($data) ) {
        handle_error($client);
        return;
    }

    $inbuffer{$client} .= $data;
    while ( $inbuffer{$client} =~ s/(.*\n)// ) {
        push @{ $ready{$client} }, $1;
    }
}
​
接下来是一个处理可写状态的socket的函数。
​  等待被发送到客户端的数据将被写到这个socket中，之后被从输出缓冲中删除。
​
sub handle_write {
    my $client = shift;

    return unless exists $outbuffer{$client};

    my $rv = $client->send( $outbuffer{$client}, 0 );
    unless ( defined $rv ) {
        warn "I was told I could write, but I can't.\n";
        return;
    }

    if ( $rv == length( $outbuffer{$client} ) or
        $! == POSIX::EWOULDBLOCK
      ) {
        substr( $outbuffer{$client}, 0, $rv ) = "";
        delete $outbuffer{$client} unless length $outbuffer{$client};
        return;
    }

    handle_error($client);
}
​
最后我们需要一个程序来处理客户socket在读取和发送数据时产生的错误。
​它会为发生错误的socket做一些清理工作，并保证它们被正确关闭。
​
sub handle_error {
    my $client = shift;

    delete $inbuffer{$client};
    delete $outbuffer{$client};
    delete $ready{$client};

    $select->remove($client);
    close $client;
}
​
短短130行代码，我们就有了一个简单的回声服务器。不算太坏，但是我们可以做得更好。

2. 将服务器移植到POE上
为了把IO::Socket服务器移植到POE上，需要使用到某些POE的底层特征。
​为了详细说明的需要，我们竟可能地不省略细节，而最终的程序也将保留其中的大部分代码。

​事实上，以上的IO::Socket服务器本身就是由事件驱动的，在其中包含了一个用于检测并分派之间的主循环，配以处理这些事件的相应事件句柄。
​从这一点上来说，与POE的原理和架构有异曲同工的意思。
新的服务器程序需要一个如下所示的POE空框架。用于具体功能实现的代码将被添加到这个框架之中。
​
#!/usr/bin/perl

use warnings;
use strict;

use POSIX;
use IO::Socket;
use POE;

POE::Session->create
  ( inline_states =>
      {
      }
  );

POE::Kernel->run();
exit;
​
在继续完成接下来的程序之前，为了勾勒出程序的大致框架结构，必须明确哪些事件的出现是必要的。
1)    服务器启动，完成初始化。
2)    服务器socket准备就绪，可以接收连接。
3)    客户socket处于可读取状态，服务器读取数据并对其进行处理。
4)    客户socket处于可写状态，服务器对其写入一些数据。
5)    客户socket发生错误，需要将其关闭。
一旦知道了需要做些什么，就可以建立这些事件的名称，并为这些事件编写相应的事件处理句柄，从而快速地完成POE::Session的构造。
​
POE::Session->create
  ( inline_states =>
      { _start => \&server_start,
        event_accept => \&server_accept,
        event_read   => \&client_read,
        event_write  => \&client_write,
        event_error  => \&client_error,
      }
  );
​
现在是真正将IO::Select代码移植过来的时候了！
​和IO::Select服务器相同，需要为客户socket提供输入和输出缓冲，
​而且由于这两个缓冲对socket句柄的重要性并且不存在冲突，它们将被保持为程序的全局变量。
​另外，在这里将不再使用%ready哈希表。
​
my %inbuffer  = ();
my %outbuffer = ();
​
紧接着是引入IO::Select的程序片段，因为每一段都是上面指定的事件所触发的，因此这些片段将被移植入相应事件的处理句柄中。
在_start事件的处理句柄中，需要建立一个服务器的监听socket，并用select_read为其分配一个事件发生器。
​句柄中用到的POE::Kernel模块中的select_read方法接收两个参数：
​第一个是需要监视的socket，
​第二个是当该socket处于可读状态时所触发的处理句柄。
sub server_start {
    my $server = IO::Socket::INET->new
      ( LocalPort => 12345,
        Listen => 10,
        Reuse  => "yes",
      ) or die "can't make server socket: $@\n";

    $_[KERNEL]->select_read( $server, "event_accept" );
}
​
注意一点，我们并没有保存服务器socket。
​因为POE::Kernel会对其进行跟踪，并将其作为一个参数传递给event_accept事件句柄。
​只有在需要特殊用途的情况下，我们才会保存一个该socket的拷贝。
​
再回顾POE::Session构造器，事件event_accept会激发server_accept事件句柄。
​该句柄接收一个新的客户socket，并对其分配一个监视器。
sub server_accept {
    my ( $kernel, $server ) = @_[ KERNEL, ARG0 ];

    my $new_client = $server->accept();
    $kernel->select_read( $new_client, "event_read" );
}
​
之后我们在client_read句柄中处理处理来自客户的数据。
​当新连接的客户socket处于可读状态时，句柄被触发。
​该句柄中的第一个客户参数即为所连接的客户socket，因此我们无需再为其保留一个拷贝。
​
在内容上，句柄client_read与IO::Select服务器中的handle_read几乎一样。
​而由于handle_read的accept部分的内容被移植到了server_accept句柄中，相应地就不再需要%ready哈希表了。
​
如果接收过程发生错误，客户socket通过POE::Kernel的yield方法将被传送到event_error句柄中。
​因为该yield方法是根据程序员的具体要求发送事件的，所以需要在yield中将发生错误的客户socket作为某个参数，
​而此socket在处理该event_error的事件句柄client_error中被赋值给$_[ARG0]。
​
接着，如果在client_read中发现输出缓存存在数据，
​我们将检测以保证当该客户socket处于可写状态时，及时触发事件处理句柄，将数据发送出去。
sub client_read {
    my ( $kernel, $client ) = @_[ KERNEL, ARG0 ];

    my $data = "";
    my $rv   = $client->recv( $data, POSIX::BUFSIZ, 0 );

    unless ( defined($rv) and length($data) ) {
        $kernel->yield( event_error => $client );
        return;
    }

    $inbuffer{$client} .= $data;
    while ( $inbuffer{$client} =~ s/(.*\n)// ) {
        $outbuffer{$client} .= $1;
    }

    if ( exists $outbuffer{$client} ) {
        $kernel->select_write( $client, "event_write" );
    }
}
​
在用于发送数据的事件句柄中，第一个客户参数依然是一个可用的socket。
​在该句柄中，如果输出缓存为空，则停止检测并迅速返回。
​否则，我们将试图将缓冲内的数据全部发出。如果所有数据均发送成功，该缓冲将被销毁。
​与client_read类似，client_write中也有相应的错误处理句柄。
sub client_write {
    my ( $kernel, $client ) = @_[ KERNEL, ARG0 ];

    unless ( exists $outbuffer{$client} ) {
        $kernel->select_write($client);
        return;
    }

    my $rv = $client->send( $outbuffer{$client}, 0 );
    unless ( defined $rv ) {
        warn "I was told I could write, but I can't.\n";
        return;
    }

    if ( $rv == length( $outbuffer{$client} ) or
        $! == POSIX::EWOULDBLOCK
      ) {
        substr( $outbuffer{$client}, 0, $rv ) = "";
        delete $outbuffer{$client} unless length $outbuffer{$client};
        return;
    }

    $kernel->yield( event_error => $client );
}
​
最后说明一下在以上两个句柄中被用到的错误处理句柄。
​我们首先删除了客户socket的输入输出缓存，再关闭建立在该socket上的所有监视，最后保证该socket被成功关闭。
​如此这般便有效地关闭了来自于客户的连接。
sub client_error {
    my ( $kernel, $client ) = @_[ KERNEL, ARG0 ];

    delete $inbuffer{$client};
    delete $outbuffer{$client};

    $kernel->select($client);
    close $client;
}

移植成功！

原文链接: http://www.cnitblog.com/gyn/archive/2008/05/09/43537.html