首先是，這個(gè)客戶端竟然有創(chuàng)建網(wǎng)絡(luò)端口并接收端口處的數(shù)據(jù)這樣枯燥的代碼。Twisted理應(yīng)為我們實(shí)現(xiàn)這些例程性功能，省得我們每次寫一個(gè)新的程序時(shí)都要自己去實(shí)現(xiàn)。這樣做特別有用，可以將我們從異步I/O涉及的一些棘手的異常處理中解放出來(lái)(參看前面的客戶端) , 如果要跨平臺(tái)就涉及到更多更加棘手的細(xì)節(jié)。如果你哪天下午有空，可以翻翻Twisted的WIN32實(shí)現(xiàn)源代碼，看看里面有多少小針線是來(lái)處理跨平臺(tái)的。

另一問(wèn)題是與錯(cuò)誤處理有關(guān)。當(dāng)運(yùn)行版本1的Twisted客戶端從并沒(méi)有提供服務(wù)的端口上下載詩(shī)歌時(shí)，它就會(huì)崩潰。當(dāng)然我們是可以修正這個(gè)錯(cuò)誤，但通過(guò)下面我們要介紹Twisted的APIs來(lái)處理這些類型的錯(cuò)誤會(huì)更簡(jiǎn)單。

最后，那個(gè)客戶端也不能復(fù)用。如果有另一個(gè)模塊需要通過(guò)我們的客戶端下載詩(shī)歌呢？人家怎么知道你的詩(shī)歌已經(jīng)下載完畢？我們不能用一個(gè)方法簡(jiǎn)單地將一首詩(shī)下載完成后再傳給人家，而在之前讓人家處于等待狀態(tài)。這確實(shí)是一個(gè)問(wèn)題，但我們不準(zhǔn)備在這個(gè)部分解決這個(gè)問(wèn)題—在未來(lái)的部分中一定會(huì)解決這個(gè)問(wèn)題。

我們將會(huì)使用一些高層次的APIs和接口來(lái)解決第一、二個(gè)問(wèn)題。Twisted框架是由眾多抽象層松散地組合起來(lái)的。因此，學(xué)習(xí)Twisted也就意味著需要學(xué)習(xí)這些層都提供什么功能，例如每層都有哪些APIs，接口和實(shí)例可供使用。接下來(lái)我們會(huì)通過(guò)剖析Twisted最最重要的部分來(lái)更好地感受一下Twisted都是怎么組織的。一旦你對(duì)Twisted的整個(gè)結(jié)構(gòu)熟悉了，學(xué)習(xí)新的部分會(huì)簡(jiǎn)單多了。

一般來(lái)說(shuō)，每個(gè)Twisted的抽象都只與一個(gè)特定的概念相關(guān)。例如，第四部分中的客戶端使用的IReadDescriptor，它就是"一個(gè)可以讀取字節(jié)的文件描述符"的抽象。一個(gè)抽象往往會(huì)通過(guò)定義接口來(lái)指定那些想實(shí)現(xiàn)這個(gè)抽象（也就是實(shí)現(xiàn)這個(gè)接口）的對(duì)象的形為。在學(xué)習(xí)新的Twisted抽象概念時(shí)，最需要謹(jǐn)記的就是：

多數(shù)高層次抽象都是在低層次抽象的基礎(chǔ)上建立的，很少有另立門戶的。

因此，你在學(xué)習(xí)新的Twisted抽象概念時(shí)，始終要記住它做什么和不做什么。特別是，如果一個(gè)早期的抽象A實(shí)現(xiàn)了F特性，那么F特性不太可能再由其它任何抽象來(lái)實(shí)現(xiàn)。另外，如果另外一個(gè)抽象需要F特性，那么它會(huì)使用A而不是自己再去實(shí)現(xiàn)F。（通常的做法，B可能會(huì)通過(guò)繼承A或獲得一個(gè)指向A實(shí)例的引用）

網(wǎng)絡(luò)非常的復(fù)雜，因此Twisted包含很多抽象的概念。通過(guò)從低層的抽象講起，我們希望能更清楚起看到在一個(gè)Twisted程序中各個(gè)部分是怎么組織起來(lái)的。

核心的循環(huán)體

第一個(gè)我們要學(xué)習(xí)的抽象，也是Twisted中最重要的，就是reactor。在每個(gè)通過(guò)Twisted搭建起來(lái)的程序中心處，不管你這個(gè)程序有多少層，總會(huì)有一個(gè)reactor循環(huán)在不停止地驅(qū)動(dòng)程序的運(yùn)行。再也沒(méi)有比reactor提供更加基礎(chǔ)的支持了。實(shí)際上，Twisted的其它部分（即除了reactor循環(huán)體）可以這樣理解：它們都是來(lái)輔助X來(lái)更好地使用reactor，這里的X可以是提供Web網(wǎng)頁(yè)、處理一個(gè)數(shù)據(jù)庫(kù)查詢請(qǐng)求或其它更加具體的內(nèi)容。盡管堅(jiān)持像上一個(gè)客戶端一樣使用低層APIs是可能的，但如果我們執(zhí)意那樣做，那么我們必需自己來(lái)實(shí)現(xiàn)非常多的內(nèi)容。而在更高的層次上，意味著我們可以少寫很多代碼。

但是當(dāng)在外層思考與處理問(wèn)題時(shí), 很容易就忘記了reactor的存在了。在任何一個(gè)常見(jiàn)大小的Twisted程序中，確實(shí)很少會(huì)有直接與reactor的APIs交互。低層的抽象也是一樣（即我們很少會(huì)直接與其交互）。我們?cè)谏弦粋€(gè)客戶端中用到的文件描述符抽象，就被更高層的抽象更好的歸納以至于我們很少會(huì)在真正的Twisted程序中遇到。（他們?cè)趦?nèi)部依然在被使用，只是我們看不到而已）

至于文件描述符抽象的消息，這并不是一個(gè)問(wèn)題。讓Twisted掌舵異步I/O處理，這樣我們就可以更加關(guān)注我們實(shí)際要解決的問(wèn)題。但對(duì)于reactor不一樣，它永遠(yuǎn)都不會(huì)消失。當(dāng)你選擇使用Twisted，也就意味著你選擇使用Reactor模式，并且意味著你需要使用回調(diào)與多任務(wù)合作的"交互式"編程方式。如果你想正確地使用Twisted，你必須牢記reactor的存在。我們將在第六部分更加詳細(xì)的講解部分內(nèi)容。但是現(xiàn)在要強(qiáng)調(diào)的是：

圖5與圖6是這個(gè)系列中最最重要的圖

我們還將用圖來(lái)描述新的概念，但這兩個(gè)圖是需要你牢記在腦海中的。可以這樣說(shuō)，我在寫Twisted程序時(shí)一直想著這兩張圖。

在我們付諸于代碼前，有三個(gè)新的概念需要闡述清楚：Transports, Protocols, Protocol Factories

Transports

Transports抽象是通過(guò)Twisted中interfaces模塊中ITransport接口定義的。一個(gè)Twisted的Transport代表一個(gè)可以收發(fā)字節(jié)的單條連接。對(duì)于我們的詩(shī)歌下載客戶端而言，就是對(duì)一條TCP連接的抽象。但是Twisted也支持諸如Unix中管道和UDP。Transport抽象可以代表任何這樣的連接并為其代表的連接處理具體的異步I/O操作細(xì)節(jié)。

如果你瀏覽一下ITransport中的方法，可能找不到任何接收數(shù)據(jù)的方法。這是因?yàn)門ransports總是在低層完成從連接中異步讀取數(shù)據(jù)的許多細(xì)節(jié)工作，然后通過(guò)回調(diào)將數(shù)據(jù)發(fā)給我們。相似的原理，Transport對(duì)象的寫相關(guān)的方法為避免阻塞也不會(huì)選擇立即寫我們要發(fā)送的數(shù)據(jù)。告訴一個(gè)Transport要發(fā)送數(shù)據(jù)，只是意味著：盡快將這些數(shù)據(jù)發(fā)送出去，別產(chǎn)生阻塞就行。當(dāng)然，數(shù)據(jù)會(huì)按照我們提交的順序發(fā)送。

通常我們不會(huì)自己實(shí)現(xiàn)一個(gè)Transport。我們會(huì)去使用Twisted提供的實(shí)現(xiàn)類，即在傳遞給reactor時(shí)會(huì)為我們創(chuàng)建一個(gè)對(duì)象實(shí)例。

Protocols

Twisted的Protocols抽象由interfaces模塊中的IProtocol定義。也許你已經(jīng)想到，Protocol對(duì)象實(shí)現(xiàn)協(xié)議內(nèi)容。也就是說(shuō)，一個(gè)具體的Twisted的Protocol的實(shí)現(xiàn)應(yīng)該對(duì)應(yīng)一個(gè)具體網(wǎng)絡(luò)協(xié)議的實(shí)現(xiàn)，像FTP、IMAP或其它我們自己制定的協(xié)議。我們的詩(shī)歌下載協(xié)議，正如它表現(xiàn)的那樣，就是在連接建立后將所有的詩(shī)歌內(nèi)容全部發(fā)送出去并且在發(fā)送完畢后關(guān)閉連接。

嚴(yán)格意義上講，每一個(gè)Twisted的Protocols類實(shí)例都為一個(gè)具體的連接提供協(xié)議解析。因此我們的程序每建立一條連接（對(duì)于服務(wù)方就是每接受一條連接），都需要一個(gè)協(xié)議實(shí)例。這就意味著，Protocol實(shí)例是存儲(chǔ)協(xié)議狀態(tài)與間斷性（由于我們是通過(guò)異步I/O方式以任意大小來(lái)接收數(shù)據(jù)的）接收并累積數(shù)據(jù)的地方。

因此，Protocol實(shí)例如何得知它為哪條連接服務(wù)呢？如果你閱讀IProtocol定義會(huì)發(fā)現(xiàn)一個(gè)makeConnection函數(shù)。這是一個(gè)回調(diào)函數(shù)，Twisted會(huì)在調(diào)用它時(shí)傳遞給其一個(gè)也是僅有的一個(gè)參數(shù)，即Transport實(shí)例。這個(gè)Transport實(shí)例就代表Protocol將要使用的連接。

Twisted內(nèi)置了很多實(shí)現(xiàn)了通用協(xié)議的Protocol。你可以在twisted.protocols.basic中找到一些稍微簡(jiǎn)單點(diǎn)的。在你嘗試寫新Protocol時(shí)，最好是看看Twisted源碼是不是已經(jīng)有現(xiàn)成的存在。如果沒(méi)有，那實(shí)現(xiàn)一個(gè)自己的協(xié)議是非常好的，正如我們?yōu)樵?shī)歌下載客戶端做的那樣。

Protocol Factories

因此每個(gè)連接需要一個(gè)自己的Protocol，而且這個(gè)Protocol是我們自己定義的類的實(shí)例。由于我們會(huì)將創(chuàng)建連接的工作交給Twisted來(lái)完成，Twisted需要一種方式來(lái)為一個(gè)新的連接創(chuàng)建一個(gè)合適的協(xié)議。創(chuàng)建協(xié)議就是Protocol Factories的工作了。

也許你已經(jīng)猜到了，Protocol Factory的API由IProtocolFactory來(lái)定義，同樣在interfaces模塊中。Protocol Factory就是Factory模式的一個(gè)具體實(shí)現(xiàn)。buildProtocol方法在每次被調(diào)用時(shí)返回一個(gè)新Protocol實(shí)例，它就是Twisted用來(lái)為新連接創(chuàng)建新Protocol實(shí)例的方法。

詩(shī)歌下載客戶端2.0：第一滴心血

好吧，讓我們來(lái)看看由Twisted支持的詩(shī)歌下載客戶端2.0。源碼可以在這里twisted-client-2/get-poetry.py。你可以像前面一樣運(yùn)行它，并得到相同的輸出。這也是最后一個(gè)在接收到數(shù)據(jù)時(shí)打印其任務(wù)的客戶端版本了。到現(xiàn)在為止，對(duì)于所有Twisted程序都是交替執(zhí)行任務(wù)并處理相對(duì)較少數(shù)量數(shù)據(jù)的，應(yīng)該很清晰了。我們依然通過(guò)print函數(shù)來(lái)展示在關(guān)鍵時(shí)刻在進(jìn)行什么內(nèi)容，但將來(lái)客戶端不會(huì)在這樣繁鎖。

在第二個(gè)版本中，sockets不會(huì)再出現(xiàn)了。我們甚至不需要引入socket模塊也不用引用socket對(duì)象和文件描述符。取而代之的是，我們告訴reactor來(lái)創(chuàng)建到詩(shī)歌服務(wù)器的連接，代碼如下面所示：

factory = PoetryClientFactory(len(addresses))

from twisted.internet import reactor

for address in addresses:
    host, port = address
    reactor.connectTCP(host, port, factory)

我們需要關(guān)注的是connectTCP這個(gè)函數(shù)。前兩個(gè)參數(shù)的含義很明顯，不解釋了。第三個(gè)參數(shù)是我們自定義的PoetryClientFactory類的實(shí)例對(duì)象。這是一個(gè)專門針對(duì)詩(shī)歌下載客戶端的Protocol Factory，將它傳遞給reactor可以讓Twisted為我們創(chuàng)建一個(gè)PoetryProtocol實(shí)例。

值得注意的是，從一開(kāi)始我們既沒(méi)有實(shí)現(xiàn)Factory也沒(méi)有去實(shí)現(xiàn)Protocol，不像在前面那個(gè)客戶端中我們?nèi)?shí)例化我們PoetrySocket類。我們只是繼承了Twisted在twisted.internet.protocol 中提供的基類。Factory的基類是twisted.internet.protocol.Factory，但我們使用客戶端專用（即不像服務(wù)器端那樣監(jiān)聽(tīng)一個(gè)連接，而是主動(dòng)創(chuàng)建一個(gè)連接）的ClientFactory子類來(lái)繼承。

我們同樣利用了Twisted的Factory已經(jīng)實(shí)現(xiàn)了buildProtocol方法這一優(yōu)勢(shì)來(lái)為我們所用。我們要在子類中調(diào)用基類中的實(shí)現(xiàn)：

def buildProtocol(self, address):
    proto = ClientFactory.buildProtocol(self, address)
    proto.task_num = self.task_num
    self.task_num += 1
    return proto

基類怎么會(huì)知道我們要?jiǎng)?chuàng)建什么樣的Protocol呢？注意，我們的PoetryClientFactory中有一個(gè)protocol類變量：

class PoetryClientFactory(ClientFactory):

    task_num = 1

    protocol = PoetryProtocol # tell base class what proto to build

基類Factory實(shí)現(xiàn)buildProtocol的過(guò)程是：安裝（創(chuàng)建一個(gè)實(shí)例）我們?cè)O(shè)置在protocol變量上的Protocol類與在這個(gè)實(shí)例（此處即PoetryProtocol的實(shí)例）的factory屬性上設(shè)置一個(gè)產(chǎn)生它的Factory的引用（此處即實(shí)例化PoetryProtocol的PoetryClientFactory）。這個(gè)過(guò)程如圖8所示：

http://wiki.jikexueyuan.com/project/twisted-intro/images/p05_protocols-1.png" alt="" />

正如我們提到的那樣，位于Protocol對(duì)象內(nèi)的factory屬性字段允許在都由同一個(gè)factory產(chǎn)生的Protocol之間共享數(shù)據(jù)。由于Factories都是由用戶代碼來(lái)創(chuàng)建的（即在用戶的控制中），因此這個(gè)屬性也可以實(shí)現(xiàn)Protocol對(duì)象將數(shù)據(jù)傳遞回一開(kāi)始初始化請(qǐng)求的代碼中來(lái)，這將在第六部分看到。

值得注意的是，雖然在Protocol中有一個(gè)屬性指向生成其的Protocol Factory，在Factory中也有一個(gè)變量指向一個(gè)Protocol類，但通常來(lái)說(shuō)，一個(gè)Factory可以生成多個(gè)Protocol。

在Protocol創(chuàng)立的第二步便是通過(guò)makeConnection與一個(gè)Transport聯(lián)系起來(lái)。我們無(wú)需自己來(lái)實(shí)現(xiàn)這個(gè)函數(shù)而使用Twisted提供的默認(rèn)實(shí)現(xiàn)。默認(rèn)情況是，makeConnection將Transport的一個(gè)引用賦給（Protocol的）transport屬性，同時(shí)置（同樣是Protocol的）connected屬性為True，正如圖9描述的一樣：

http://wiki.jikexueyuan.com/project/twisted-intro/images/p05_protocols-2.png" alt="" />

一旦初始化到這一步后，Protocol開(kāi)始其真正的工作—將低層的數(shù)據(jù)流翻譯成高層的協(xié)議規(guī)定格式的消息。處理接收到數(shù)據(jù)的主要方法是dataReceived，我們的客戶端是這樣實(shí)現(xiàn)的：

def dataReceived(self, data):
    self.poem += data
    msg = 'Task %d: got %d bytes of poetry from %s'
    print  msg % (self.task_num, len(data), self.transport.getHost())

每次dateReceved被調(diào)用就意味著我們得到一個(gè)新字符串。由于與異步I/O交互，我們不知道能接收到多少數(shù)據(jù)，因此將接收到的數(shù)據(jù)緩存下來(lái)直到完成一個(gè)完整的協(xié)議規(guī)定格式的消息。在我們的例子中，詩(shī)歌只有在連接關(guān)閉時(shí)才下載完畢，因此我們只是不斷地將接收到的數(shù)據(jù)添加到我們的.poem屬性字段中。

注意我們使用了Transport的getHost方法來(lái)取得數(shù)據(jù)來(lái)自的服務(wù)器信息。我們這樣做只是與前面的客戶端保持一致。相反，我們的代碼沒(méi)有必要這樣做，因?yàn)槲覀儧](méi)有向服務(wù)器發(fā)送任何消息，也就沒(méi)有必要知道服務(wù)器的信息了。

我們來(lái)看一下dataReceved運(yùn)行時(shí)的快照。在2.0版本相同的目錄下有一個(gè)twisted-client-2/get-poetry-stack.py。它與2.0版本的不同之處只在于：

def dataReceived(self, data):
    traceback.print_stack()
    os._exit(0)

這樣一改，我們就能打印出跟蹤堆棧的信息，然后離開(kāi)程序，可以用下面的命令來(lái)運(yùn)行它：

python twisted-client-2/get-poetry-stack.py 10000

你會(huì)得到內(nèi)容如下的跟蹤堆棧：

File "twisted-client-2/get-poetry-stack.py", line 125, in
    poetry_main()

... # I removed a bunch of lines here

File ".../twisted/internet/tcp.py", line 463, in doRead  # Note the doRead callback
    return self.protocol.dataReceived(data)
File "twisted-client-2/get-poetry-stack.py", line 58, in dataReceived
    traceback.print_stack()

看見(jiàn)沒(méi)，有我們?cè)?.0版本客戶端的doRead回調(diào)函數(shù)。我們前面也提到過(guò)，Twisted在建立新抽象層會(huì)使用已有的實(shí)現(xiàn)而不是另起爐灶。因此必然會(huì)有一個(gè)IReadDescriptor的實(shí)例在辛苦的工作，它是由Twisted代碼而非我們自己的代碼來(lái)實(shí)現(xiàn)。如果你表示懷疑，那么就看看twisted.internet.tcp中的實(shí)現(xiàn)吧。如果你瀏覽代碼會(huì)發(fā)現(xiàn)，由同一個(gè)類實(shí)現(xiàn)了IWriteDescriptor與ITransport。因此 IReadDescriptor實(shí)際上就是變相的Transport類?？梢杂脠D10來(lái)形象地說(shuō)明dateReceived的回調(diào)過(guò)程：

http://wiki.jikexueyuan.com/project/twisted-intro/images/p05_reactor-data-received.png" alt="" />

一旦詩(shī)歌下載完成，PoetryProtocol就會(huì)通知它的PooetryClientFactory：

def connectionLost(self, reason):     
  self.poemReceived(self.poem) 
def poemReceived(self, poem):    
  self.factory.poem_finished(self.task_num, poem)

當(dāng)transport的連接關(guān)閉時(shí)，conncetionLost回調(diào)會(huì)被激活。reason參數(shù)是一個(gè)twisted.python.failure.Failure的實(shí)例對(duì)象，其攜帶的信息能夠說(shuō)明連接是被安全的關(guān)閉還是由于出錯(cuò)被關(guān)閉的。我們的客戶端因認(rèn)為總是能完整地下載完詩(shī)歌而忽略了這一參數(shù)。

工廠會(huì)在所有的詩(shī)歌都下載完畢后關(guān)閉reactor。再次重申：我們代碼的工作就是用來(lái)下載詩(shī)歌-這意味我們的PoetryClientFactory缺少?gòu)?fù)用性。我們將在下一部分修正這一缺陷。值得注意的是，poem_finish回調(diào)函數(shù)是如何通過(guò)跟蹤剩余詩(shī)歌數(shù)的：

    ...
    self.poetry_count -= 1

    if self.poetry_count == 0:
    ...

如果我們采用多線程以讓每個(gè)線程分別下載詩(shī)歌，這樣我們就必須使用一把鎖來(lái)管理這段代碼以免多個(gè)線程在同一時(shí)間調(diào)用poem_finish。但是在交互式體系下就不必?fù)?dān)心了。由于reactor只能一次啟用一個(gè)回調(diào)。

新的客戶端實(shí)現(xiàn)在處理錯(cuò)誤上也比先前的優(yōu)雅的多，下面是PoetryClientFactory處理錯(cuò)誤連接的回調(diào)實(shí)現(xiàn)代碼：

def clientConnectionFailed(self, connector, reason):
    print 'Failed to connect to:', connector.getDestination()
    self.poem_finished()

注意，回調(diào)是在工廠內(nèi)部而不是協(xié)議內(nèi)部實(shí)現(xiàn)。由于協(xié)議是在連接建立后才創(chuàng)建的，而工廠能夠在連接未能成功建立時(shí)捕獲消息。

結(jié)束語(yǔ)

版本2的客戶端使用的抽象對(duì)于那些Twisted高手應(yīng)該非常熟悉。如果僅僅是為在命令行上打印出下載的詩(shī)歌這個(gè)功能，那么我們已經(jīng)完成了。但如果想使我們的代碼能夠復(fù)用，能夠被內(nèi)嵌在一些包含詩(shī)歌下載功能并可以做其它事情的大軟件中，我們還有許多工作要做，我們將在第六部分講解相關(guān)內(nèi)容。

參考

本部分原作參見(jiàn): dave @ http://krondo.com/?p=1522

本部分翻譯內(nèi)容參見(jiàn)楊曉偉的博客 http://blog.sina.com.cn/s/blog_704b6af70100q2ac.html

上一篇：使用Deferred的詩(shī)歌下載客戶端下一篇：構(gòu)造"回調(diào)"的另一種方法