Twisted学习记录

Reactor：

这个利用循环体来等待事件发生，然后处理发生的事件的模型非常常见，而被设计成为一个模式：reactor模式。这个循环就是个”reactor“（反应堆），因为它等待事件的发生然对其作为相应的反应。正因为如此，它也被称作事件循环。

几个结论：

1.Twisted的reactor只有通过调用reactor.run()来启动。

2.reactor循环是在其开始的进程中运行，也就是运行在主进程中。

3.一旦启动，就会一直运行下去。reactor就会在程序的控制下（或者具体在一个启动它的线程的控制下）。

4.reactor循环并不会消耗任何CPU的资源。

5.并不需要显式的创建reactor，只需要引入就OK了。

有关回调的一些其它说明：

     Twisted并不是唯一使用回调的框架。

1.reactor模式是单线程的。

2.像Twisted这种交互式模型已经实现了reactor循环，意味无需我们亲自去实现它。

3.我们仍然需要框架来调用我们自己的代码来完成业务逻辑。

4.因为在单线程中运行，要想跑我们自己的代码，必须在reactor循环中调用它们。

5.reactor事先并不知道调用我们代码的哪个函数。

这样的话，回调并不仅仅是一个可选项，而是游戏规则的一部分。

图6说明了回调过程中发生的一切：

图6 reactor启用回调

    图6揭示了回调中的几个重要特性：

1.我们的代码与Twisted代码运行在同一个进程中。

2.当我们的代码运行时，Twisted代码是处于暂停状态的。

3.同样，当Twisted代码处于运行状态时，我们的代码处于暂停状态。

4.reactor事件循环会在我们的回调函数返回后恢复运行。




利用Twisted来搭建我们的诗歌服务器

Transports：


Transports抽象是通过Twisted中interfaces模块中ITransport接口定义的。一个Twisted的Transport代表一个可以收发字节的单条连接。





Protocols：


Twisted的Protocols抽象由interfaces模块中的IProtocol定义。也许你已经想到，Protocol对象实现协议内容。也就是说，一个具体的Twisted的Protocol的实现应该对应一个具体网络协议的实现，像FTP、IMAP或其它我们自己规定的协议。我们的诗歌下载协议，正如它表现的那样，就是在连接建立后将所有的诗歌内容全部发送出去并且在发送完毕后关闭连接。

严格意义上讲，每一个Twisted的Protocols类实例都为一个具体的连接提供协议解析。因此我们的程序每建立一条连接（对于服务方就是每接受一条连接），都需要一个协议实例。这就意味着，Protocol实例是存储协议状态与间断性（由于我们是通过异步I/O方式以任意大小来接收数据的）接收并累积数据的地方。

因此，Protocol实例如何得知它为哪条连接服务呢？如果你阅读IProtocol定义会发现一个makeConnection函数。这是一个回调函数，Twisted会在调用它时传递给其一个也是仅有的一个参数，即就是Transport实例。这个Transport实例就代表Protocol将要使用的连接。

Twisted包含很多内置可以实现很多通用协议的Protocol。你可以在twisted.protocols.basic中找到一些稍微简单点的。在你尝试写新Protocol时，最好是看看Twisted源码是不是已经有现成的存在。如果没有，那实现一个自己的协议是非常好的，正如我们为诗歌下载客户端做的那样。

Protocol Factories：

因此每个连接需要一个自己的Portocol，而且这个Protocol是我们自己定义类的实例。由于我们会将创建连接的工作交给Twisted来完成，Twisted需要一种方式来为一个新的连接制定一个合适的协议。制定协议就是Protocol Factories的 工作了。

也许你已经猜到了，Protocol Factory的API由IProtocolFactory来定义，同样在interfaces模块中。Protocol Factory就是Factory模式的一个具体实现。buildProtocol方法在每次被调用时返回一个新Protocol实例。它就是Twisted用来为新连接创建新Protocol实例的方法。