原文鏈接：http://www.aosabook.org/en/twisted.html
翻譯連接：http://blog.csdn.net/hanhuili/article/details/9389433#t7
作者：Jessica McKellar
Twisted是用Python實現的基於事件驅動的網絡引擎框架。Twisted誕生於2000年初，在當時的網絡遊戲開發者看來，無論他們使用哪種語言，手中都鮮有可兼顧擴展性及跨平臺的網絡庫。Twisted的作者試圖在當時現有的環境下開發遊戲，這一步走的非常艱難，他們迫切地需要一個可擴展性高、基於事件驅動、跨平臺的網絡開發框架，爲此他們決定自己實現一個，並從那些之前的遊戲和網絡應用程序的開發者中學習，汲取他們的經驗教訓。
Twisted支持許多常見的傳輸及應用層協議，包括TCP、UDP、SSL/TLS、HTTP、IMAP、SSH、IRC以及FTP。就像Python一樣，Twisted也具有“內置電池”（batteries-included）的特點。Twisted對於其支持的所有協議都帶有客戶端和服務器實現，同時附帶有基於命令行的工具，使得配置和部署產品級的Twisted應用變得非常方便。
21.1 爲什麼需要Twisted
2000年時，Twisted的作者Glyph正在開發一個名爲Twisted Reality的基於文本方式的多人在線遊戲。這個遊戲採用Java開發，裏面盡是一堆線程——每個連接就有3個線程處理。處理輸入的線程會在讀操作上阻塞，處理輸出的線程將在一些寫操作上阻塞，還有一個“邏輯”線程將在等待定時器超時或者事件入隊列時休眠。隨着玩家們在虛擬世界中移動並交互時，線程出現死鎖，緩存被污染，程序中的加鎖邏輯幾乎從來就沒對過——採用多線程使得整個軟件變得複雜、漏洞百出而且極難擴展。
爲了尋求其他的解決方案，作者發現了Python，特別是Python中用於對流式對象比如socket和pipe進行多路I/O複用的select模塊（UNIX規範第3版（SUSv3）描述了select）。那時，Java並沒有提供操作系統的select接口或者任何其他的異步I/O API（針對非阻塞式I/O的包java.nio已經在J2SE 1.4中加入了，2002年發佈）。通過用Python中的select模塊快速搭建起遊戲的原型，這迅速降低了程序的複雜度，並且比多線程版本要更加可靠。
Glyph迅速轉向了Python、select以及基於事件驅動的編程。他使用Python的select模塊爲遊戲編寫了客戶端和服務器。但他想要的還不止於此。從根本上說，他希望能將網絡行爲轉變爲對遊戲中的對象的方法調用。如果你能在遊戲中收取郵件會怎樣，就像Nethack mailer這種守護進程一樣？如果遊戲中的每位玩家都擁有一個主頁呢？Glyph發現他需要優秀的IMAP以及HTTP客戶端和服務器的Python實現，而這些都要採用select。
他首先轉向了Medusa，這是一個在90年代中期開發的平臺，在這裏可以採用Python中的asyncore模塊來編寫網絡服務。asyncore是一個異步化處理socket的模塊，在操作系統的select API之上構建了一個調度器和回調接口。
這對於Glyph來說是個激動人心的發現，但Medusa有兩個缺點：
這個項目到2001年就不再維護了，那正是glyph開發Twisted Reality的時候。
asyncore只是對socket的一個薄封裝層，應用程序的編寫者仍然需要直接操作socket。這意味着程序可移植性的擔子仍然落在程序員自己身上。此外，那時asyncore對Windows的支持還有問題，Glyph希望能在Windows上運行一個帶有圖形用戶界面的客戶端。
Glyph需要自己實現一個網絡引擎平臺，而且他意識到Twisted Reality已經打開了問題的大門，這和他的遊戲一樣有趣。
隨着時間的推移，Twisted Reality這個遊戲就演化成了Twisted網絡引擎平臺。它可以做到當時Python中已有的網絡平臺所無法做到的事情：
使用基於事件驅動的編程模型，而不是多線程模型。
跨平臺：爲主流操作系統平臺暴露出的事件通知系統提供統一的接口。
“內置電池”的能力：提供流行的應用層協議實現，因此Twisted馬上就可爲開發人員所用。
符合RFC規範，已經通過健壯的測試套件證明了其一致性。
能很容易的配合多個網絡協議一起使用。
可擴展。
21.2 Twisted架構概覽
Twisted是一個事件驅動型的網絡引擎。由於事件驅動編程模型在Twisted的設計哲學中佔有重要的地位，因此這裏有必要花點時間來回顧一下究竟事件驅動意味着什麼。
事件驅動編程是一種編程範式，這裏程序的執行流由外部事件來決定。它的特點是包含一個事件循環，當外部事件發生時使用回調機制來觸發相應的處理。另外兩種常見的編程範式是（單線程）同步以及多線程編程。
讓我們用例子來比較和對比一下單線程、多線程以及事件驅動編程模型。圖21.1展示了隨着時間的推移，這三種模式下程序所做的工作。這個程序有3個任務需要完成，每個任務都在等待I/O操作時阻塞自身。阻塞在I/O操作上所花費的時間已經用灰色框標示出來了。
圖21.1 線程模型
在單線程同步模型中，任務按照順序執行。如果某個任務因爲I/O而阻塞，其他所有的任務都必須等待，直到它完成之後它們才能依次執行。這種明確的執行順序和串行化處理的行爲是很容易推斷得出的。如果任務之間並沒有互相依賴的關係，但仍然需要互相等待的話這就使得程序不必要的降低了運行速度。
在多線程版本中，這3個任務分別在獨立的線程中執行。這些線程由操作系統來管理，在多處理器系統上可以並行處理，或者在單處理器系統上交錯執行。這使得當某個線程阻塞在某個資源的同時其他線程得以繼續執行。與完成類似功能的同步程序相比，這種方式更有效率，但程序員必須寫代碼來保護共享資源，防止其被多個線程同時訪問。多線程程序更加難以推斷，因爲這類程序不得不通過線程同步機制如鎖、可重入函數、線程局部存儲或者其他機制來處理線程安全問題，如果實現不當就會導致出現微妙且令人痛不欲生的bug。
在事件驅動版本的程序中，3個任務交錯執行，但仍然在一個單獨的線程控制中。當處理I/O或者其他昂貴的操作時，註冊一個回調到事件循環中，然後當I/O操作完成時繼續執行。回調描述了該如何處理某個事件。事件循環輪詢所有的事件，當事件到來時將它們分配給等待處理事件的回調函數。這種方式讓程序儘可能的得以執行而不需要用到額外的線程。事件驅動型程序比多線程程序更容易推斷出行爲，因爲程序員不需要關心線程安全問題。
當我們面對如下的環境時，事件驅動模型通常是一個好的選擇：
程序中有許多任務，而且…
任務之間高度獨立（因此它們不需要互相通信，或者等待彼此）而且…
在等待事件到來時，某些任務會阻塞。
當應用程序需要在任務間共享可變的數據時，這也是一個不錯的選擇，因爲這裏不需要採用同步處理。
網絡應用程序通常都有上述這些特點，這使得它們能夠很好的契合事件驅動編程模型。
重用已有的應用
在Twisted創建之前就已經有了許多針對多種流行的網絡協議的客戶端和服務器實現了。爲什麼Glyph不直接用Apache、IRCd、BIND、OpenSSH或者任何其他已有的應用，而要爲Twisted從頭開始重新實現各個協議的客戶端和服務器呢？
問題在於所有這些已有的實現都存在有從頭寫起的網絡層代碼，通常都是C代碼。而應用層代碼直接同網絡層耦合在一起，這使得它們非常難以以庫的形式來複用。當要一起使用這些組件時，如果希望在多個協議中暴露相同的數據，則它們必須以黑盒的形式來看待，這使得開發者根本沒機會重用代碼。此外，服務器和客戶端的實現通常是分離的，彼此之間不共享代碼。要擴展這些應用，維護跨平臺的客戶端-服務器兼容性的難度本不至於這麼大。
Twisted中的客戶端和服務器是用Python開發的，採用了一致性的接口。這使得開發新的客戶端和服務器變得很容易實現，可以在客戶端和服務器之間共享代碼，在協議之間共享應用邏輯，以及對某個實現的代碼做測試。
Reactor模式
Twisted實現了設計模式中的反應堆（reactor）模式，這種模式在單線程環境中調度多個事件源產生的事件到它們各自的事件處理例程中去。
Twisted的核心就是reactor事件循環。Reactor可以感知網絡、文件系統以及定時器事件。它等待然後處理這些事件，從特定於平臺的行爲中抽象出來，並提供統一的接口，使得在網絡協議棧的任何位置對事件做出響應都變得簡單。
基本上reactor完成的任務就是：
while True: timeout = time_until_next_timed_event() events = wait_for_events(timeout) events += timed_events_until(now()) for event in events: event.process()
Twisted目前在所有平臺上的默認reactor都是基於poll API的（UNIX規範第3版（SUSv3）中描述）。此外，Twisted還支持一些特定於平臺的高容量多路複用API。這些reactor包括基於FreeBSD中kqueue機制的KQueue reactor，支持epoll接口的系統（目前是Linux 2.6）中的epoll reactor，以及基於Windows下的輸入輸出完成端口的IOCP reactor。
在實現輪詢的相關細節中，Twisted需要考慮的包括：
網絡和文件系統的限制
緩衝行爲
如何檢測連接丟失
出現錯誤時的返回值
Twisted的reactor實現同時也考慮了正確使用底層的非阻塞式API，並正確處理各種邊界情況。由於Python中沒有暴露出IOCP API，因此Twisted需要維護自己的實現。
管理回調鏈
回調是事件驅動編程模型中的基礎，也是reactor通知應用程序事件已經處理完成的方式。隨着程序規模不斷擴大，基於事件驅動的程序需要同時處理事件處理成功和出錯的情況，這使得程序變得越來越複雜。若沒有註冊一個合適的回調，程序就會阻塞，因爲這個事件處理的過程絕不會發生。出現錯誤時需要通過應用程序的不同層次從網絡棧向上傳遞迴調鏈。
下面是兩段Python僞碼，分別是同步和異步模式下獲取URL的玩具代碼。讓我們相互比較一下這兩個版本，看看基於事件驅動的程序有什麼缺陷：
以同步的方式獲取URL：
import getPagedef processPage(page): print pagedef logError(error): print errordef finishProcessing(value): print "Shutting down..." exit(0)url = "http://google.com"try: page = getPage(url) processPage(page)except Error, e: logError(error)finally: finishProcessing()
以異步的方式獲取URL：
from twisted.internet import reactorimport getPagedef processPage(page): print page finishProcessing()def logError(error): print error finishProcessing()def finishProcessing(value): print "Shutting down..." reactor.stop()url = "http://google.com"# getPage takes: url, # success callback, error callbackgetPage(url, processPage, logError)reactor.run()
在異步版的URL獲取器中，reactor.run()啓動reactor事件循環。在同步和異步版程序中，我們假定getPage函數處理獲取頁面的工作。如果獲取成功就調用processPage，如果嘗試獲取頁面時出現了Exception（異常），logError就得到調用。無論哪種情況，最後都要調用finishProcessing。
異步版中的logError回調正對應於同步版中的try/except塊。對processPage的回調對應於else塊，無條件回調的finishProcessing就對應於finally塊。
在同步版中，代碼結構直接顯示出有一個try/except塊，logError和processPage這兩者間只會取其一調用一次，而finishProcessing總是會被調用一次。在異步版中需要由程序員自己負責正確調用成功和失敗情況下的回調鏈。如果由於編程錯誤，在processPage或者logError的回調鏈之後沒有調用finishProcessing，reactor事件循環將永遠不會停止，程序就會卡住。
這個玩具式的例子告訴我們在開發Twisted的頭幾年裏這種複雜性令程序員感到非常沮喪。而Twisted應對這種複雜性的方式是新增一個稱爲Deferred（延遲）的對象。
Deferreds
Deferred對象以抽象化的方式表達了一種思想，即結果還尚不存在。它同樣能夠幫助管理產生這個結果所需要的回調鏈。當從函數中返回時，Deferred對象承諾在某個時刻函數將產生一個結果。返回的Deferred對象中包含所有註冊到事件上的回調引用，因此在函數間只需要傳遞這一個對象即可，跟蹤這個對象比單獨管理所有的回調要簡單的多。
Deferred對象包含一對回調鏈，一個是針對操作成功的回調，一個是針對操作失敗的回調。初始狀態下Deferred對象的兩條鏈都爲空。在事件處理的過程中，每個階段都爲其添加處理成功的回調和處理失敗的回調。當一個異步結果到來時，Deferred對象就被“激活”，那麼處理成功的回調和處理失敗的回調就可以以合適的方式按照它們添加進來的順序依次得到調用。
異步版URL獲取器採用Deferred對象後的代碼如下：
from twisted.internet import reactorimport getPagedef processPage(page): print pagedef logError(error): print errordef finishProcessing(value): print "Shutting down..." reactor.stop()url = "http://google.com"deferred = getPage(url) # getPage returns a Deferreddeferred.addCallbacks(success, failure)deferred.addBoth(stop)reactor.run()
在這個版本中調用的事件處理函數與之前相同，但它們都註冊到了一個單獨的Deferred對象上，而不是分散在代碼各處再以參數形式傳遞給getPage。
Deferred對象創建時包含兩個添加回調的階段。第一階段，addCallbacks將 processPage和logError添加到它們各自歸屬的回調鏈中。然後addBoth再將finishProcessing同時添加到這兩個回調鏈上。用圖解的方式來看，回調鏈應該如圖21.2所示：
圖21.2 回調鏈
Deferred對象只能被激活一次，如果試圖重複激活將引發一個異常。這使得Deferred對象的語義相當接近於同步版中的try/except塊。從而讓異步事件的處理能更容易推斷，避免由於針對單個事件的回調調用多了一個或少了一個而產生微妙的bug。
理解Deferred對象對於理解Twisted程序的執行流是非常重要的。然而當使用Twisted爲我們提供的針對網絡協議的高層抽象時，通常情況下我們完全不需要直接使用Deferred對象。
Deferred對象所包含的抽象概念是非常強大的，這種思想已經被許多其他的事件驅動平臺所借用，包括jQuery、Dojo和Mochikit。
Transports
Transports代表網絡中兩個通信結點之間的連接。Transports負責描述連接的細節，比如連接是面向流式的還是面向數據報的，流控以及可靠性。TCP、UDP和Unix套接字可作爲transports的例子。它們被設計爲“滿足最小功能單元，同時具有最大程度的可複用性”，而且從協議實現中分離出來，這讓許多協議可以採用相同類型的傳輸。Transports實現了ITransports接口，它包含如下的方法：
write 以非阻塞的方式按順序依次將數據寫到物理連接上writeSequence 將一個字符串列表寫到物理連接上loseConnection 將所有掛起的數據寫入，然後關閉連接getPeer 取得連接中對端的地址信息getHost 取得連接中本端的地址信息
將transports從協議中分離出來也使得對這兩個層次的測試變得更加簡單。可以通過簡單地寫入一個字符串來模擬傳輸，用這種方式來檢查。
Protocols
Protocols描述瞭如何以異步的方式處理網絡中的事件。HTTP、DNS以及IMAP是應用層協議中的例子。Protocols實現了IProtocol接口，它包含如下的方法：
makeConnection 在transport對象和服務器之間建立一條連接connectionMade 連接建立起來後調用dataReceived 接收數據時調用connectionLost 關閉連接時調用
我們最好以一個例子來說明reactor、protocols以及transports這三者之間的關係。以下是完整的echo服務器和客戶端的實現，首先來看看服務器部分：
from twisted.internet import protocol, reactorclass Echo(protocol.Protocol): def dataReceived(self, data): # As soon as any data is received, write it back self.transport.write(data)class EchoFactory(protocol.Factory): def buildProtocol(self, addr): return Echo()reactor.listenTCP(8000, EchoFactory())reactor.run()
接着是客戶端部分：
from twisted.internet import reactor, protocolclass EchoClient(protocol.Protocol):
def connectionMade(self):
self.transport.write("hello, world!")def dataReceived(self, data):
print "Server said:", data self.transport.loseConnection()def connectionLost(self, reason):
print "connection lost"class EchoFactory(protocol.ClientFactory):
def buildProtocol(self, addr):
return EchoClient()def clientConnectionFailed(self, connector, reason):
print "Connection failed - goodbye!"
reactor.stop()def clientConnectionLost(self, connector, reason):
print "Connection lost - goodbye!"
reactor.stop()reactor.connectTCP("localhost", 8000, EchoFactory())reactor.run()運行服務器端腳本將啓動一個TCP服務器，監聽端口8000上的連接。服務器採用的是Echo協議，數據經TCP transport對象寫出。運行客戶端腳本將對服務器發起一個TCP連接，回顯服務器端的迴應然後終止連接並停止reactor事件循環。這裏的Factory用來對連接的雙方生成protocol對象實例。兩端的通信是異步的，connectTCP負責註冊回調函數到reactor事件循環中，當socket上有數據可讀時通知回調處理。
Applications
Twisted是用來創建具有可擴展性、跨平臺的網絡服務器和客戶端的引擎。在生產環境中，以標準化的方式簡化部署這些應用的過程對於Twisted這種被廣泛採用的平臺來說是非常重要的一環。爲此，Twisted開發了一套應用程序基礎組件，採用可重用、可配置的方式來部署Twisted應用。這種方式使程序員避免堆砌千篇一律的代碼來將應用程序同已有的工具整合在一起，這包括精靈化進程（daemonization）、日誌處理、使用自定義的reactor循環、對代碼做性能剖析等。
應用程序基礎組件包含4個主要部分：服務（Service）、應用（Application）、配置管理（通過TAC文件和插件）以及twistd命令行程序。爲了說明這個基礎組件，我們將上一節的Echo服務器轉變成一個應用。
Service
Service就是IService接口下實現的可以啓動和停止的組件。Twisted自帶有TCP、FTP、HTTP、SSH、DNS等服務以及其他協議的實現。其中許多Service都可以註冊到單獨的應用中。IService接口的核心是：
startService 啓動服務。可能包含加載配置數據，設定數據庫連接或者監聽某個端口stopService 關閉服務。可能包含將狀態保存到磁盤，關閉數據庫連接或者停止監聽端口
我們的Echo服務使用TCP協議，因此我們可以使用Twisted中IService接口下默認的TCPServer實現。
Application
Application是處於最頂層的Service，代表了整個Twisted應用程序。Service需要將其自身同Application註冊，然後就可以用下面我們將介紹的部署工具twistd搜索並運行應用程序。我們將創建一個可以同Echo Service註冊的Echo應用。
TAC文件
當在一個普通的Python文件中管理Twisted應用程序時，需要由開發者負責編寫啓動和停止reactor事件循環以及配置應用程序的代碼。在Twisted的基礎組件中，協議的實現都是在一個模塊中完成的，需要使用到這些協議的Service可以註冊到一個Twisted應用程序配置文件中（TAC文件）去，這樣reactor事件循環和程序配置就可以由外部組件來進行管理。
要將我們的Echo服務器轉變成一個Echo應用，我們可以按照以下幾個簡單的步驟來完成：
將Echo服務器的Protocol部分移到它們自己所歸屬的模塊中去。
在TAC文件中：
創建一個Echo應用。
創建一個TCPServer的Service實例，它將使用我們的EchoFactory，然後同前面創建的應用完成註冊。
管理reactor事件循環的代碼將由twistd來負責，我們下面會對此進行討論。這樣，應用程序的代碼就變成這樣了：
echo.py文件：
from twisted.internet import protocol, reactorclass Echo(protocol.Protocol): def dataReceived(self, data): self.transport.write(data)class EchoFactory(protocol.Factory): def buildProtocol(self, addr): return Echo()
twistd
twistd（讀作“twist-dee”）是一個跨平臺的用來部署Twisted應用程序的工具。它執行TAC文件並負責處理啓動和停止應用程序。作爲Twisted在網絡編程中具有“內置電池”能力的一部分，twistd自帶有一些非常有用的配置標誌，包括將應用程序轉變爲守護進程、定義日誌文件的路徑、設定特權級別、在chroot下運行、使用非默認的reactor，甚至是在profiler下運行應用程序。
我們可以像這樣運行這個Echo服務應用：
$ twistd –y echo_server.tac
在這個簡單的例子裏，twistd將這個應用程序作爲守護進程來啓動，日誌記錄在twistd.log文件中。啓動和停止應用後，日誌文件內容如下：
2011-11-19 22:23:07-0500 [-] Log opened.2011-11-19 22:23:07-0500 [-] twistd 11.0.0 (/usr/bin/python 2.7.1) starting up.2011-11-19 22:23:07-0500 [-] reactor class: twisted.internet.selectreactor.SelectReactor.2011-11-19 22:23:07-0500 [-] echo.EchoFactory starting on 80002011-11-19 22:23:07-0500 [-] Starting factory <echo.EchoFactory instance at 0x12d8670>2011-11-19 22:23:20-0500 [-] Received SIGTERM, shutting down.2011-11-19 22:23:20-0500 [-] (TCP Port 8000 Closed)2011-11-19 22:23:20-0500 [-] Stopping factory <echo.EchoFactory instance at 0x12d8670>2011-11-19 22:23:20-0500 [-] Main loop terminated.2011-11-19 22:23:20-0500 [-] Server Shut Down.
通過使用Twisted框架中的基礎組件來運行服務，這麼做使得開發人員能夠不用再編寫類似守護進程和記錄日誌這樣的冗餘代碼了。這同樣也爲部署應用程序建立了一個標準的命令行接口。
Plugins
對於運行Twisted應用程序的方法，除了基於TAC文件外還有一種可選的方法，這就是插件系統。TAC系統可以很方便的將Twisted預定義的服務同應用程序配置文件註冊，而插件系統能夠方便的將用戶自定義的服務註冊爲twistd工具的子命令，然後擴展應用程序的命令行接口。
在使用插件系統時：
由於只有plugin API需要保持穩定，這使得第三方開發者能很容易地擴展軟件。
插件發現能力已經集成到系統中了。插件可以在程序首次運行時加載並保存，每次程序啓動時會重新觸發插件發現過程，或者也可以在程序運行期間反覆輪詢新插件，這使得在程序已經啓動後我們還可以判斷是否有新的插件安裝上了。
當使用Twisted插件系統來擴展軟件時，我們要做的就是創建IPlugin接口下實現的對象並將它們放到一個特定的位置中，這裏插件系統知道該如何去找到它們。
我們已經將Echo服務轉換爲一個Twisted應用程序了，而將其轉換爲一個Twisted插件也是非常簡單直接的。在我們之前的Echo模塊中，除了包含有Echo協議和EchoFactory的定義之外，現在我們還要添加一個名爲twistd的目錄，其中還包含着一個名爲plugins的子目錄，這裏正是我們需要定義echo插件的地方。通過這個插件，我們可以啓動一個echo服務，並將需要使用的端口號作爲參數指定給twistd工具。
from zope.interface import implementsfrom twisted.python import usagefrom twisted.plugin import IPluginfrom twisted.application.service import IServiceMakerfrom twisted.application import internetfrom echo import EchoFactoryclass Options(usage.Options): optParameters = [["port", "p", 8000, "The port number to listen on."]]class EchoServiceMaker(object): implements(IServiceMaker, IPlugin) tapname = "echo" description = "A TCP-based echo server." options = Optionsdef makeService(self, options): """ Construct a TCPServer from a factory defined in myproject. """ return internet.TCPServer(int(options["port"]), EchoFactory())serviceMaker = EchoServiceMaker()
現在，我們的Echo服務器將作爲一個服務選項出現在twistd –help的輸出中。運行twistd echo –port=1235將在端口1235上啓動一個Echo服務器。
Twisted還帶有一個可拔插的針對服務器端認證的模塊twisted.cred，插件系統常見的用途就是爲應用程序添加一個認證模式。我們可以使用twisted.cred中現成的AuthOptionMixin類來添加針對各種認證的命令行支持，或者是添加新的認證類型。比如，我們可以使用插件系統來添加基於本地Unix密碼數據庫或者是基於LDAP服務器的認證方式。
twistd工具中附帶有許多Twisted所支持的協議插件，只用一條單獨的命令就可以完成啓動服務器的工作了。這裏有一些通過twistd啓動服務器的例子：
twistd web –port 8080 –path .
這條命令將在8080端口啓動一個HTTP服務器，在當前目錄中負責處理靜態和動態頁面請求。
twistd dns –p 5553 –hosts-file=hosts
這條命令在端口5553上啓動一個DNS服務器，解析指定的文件hosts中的域名，這個文件的內容格式同/etc/hosts一樣。
sudo twistd conch –p tcp:2222
這條命令在端口2222上啓動一個SSH服務器。ssh的密鑰必須獨立設定。
twistd mail –E –H localhost –d localhost=emails
這條命令啓動一個ESMTP POP3服務器，爲本地主機接收郵件並保存到指定的emails目錄下。
我們可以方便的通過twistd來搭建一個用於測試客戶端功能的服務器，但它同樣是可裝載的、產品級的服務器實現。
在部署應用程序的方式上，Twisted通過TAC文件、插件以及命令行工具twistd的部署方式已經獲得了成功。但是有趣的是，對於大多數大型Twisted應用程序來說，部署它們仍然需要重寫一些這類管理和監控組件；Twisted的架構並沒有對系統管理員的需求呈現出太多的友好性。這也反映了一個事實，那就是對於系統管理員來說Twisted歷來就沒有太多架構可言，而這些系統管理員纔是部署和維護應用程序的專家。在這方面，Twisted在未來架構設計的決策上需要更積極的徵求這類專家級用戶的反饋意見。
21.3 反思與教訓
Twisted最近剛剛渡過了其10週年的誕辰。自項目成立以來，由於受2000年早期的網絡遊戲啓發，目前的Twisted已經在很大程度上實現了作爲一個可擴展、跨平臺、事件驅動的網絡引擎的目標。Twisted廣泛使用於生產環境中，從Google、盧卡斯電影到Justin.TV以及Launchpad軟件協作平臺都有在使用。Twisted中的服務器端實現是多個開源軟件的核心，包括BuildBot、BitTorrent以及TahoeLAFS。
Twisted從最初開發到現在，其架構已經經歷了幾次大的變動。Deferred對象作爲一個關鍵部分被增加了進來。如前文所述，這是用來管理延後的結果以及相應的回調鏈。
還有一個重要的部分被移除掉了，在目前的實現中已經幾乎看不到任何影子了，這就是Twisted應用持久化（Twisted Application Persistence）。
Twisted應用持久化
Twisted應用持久化（TAP）是指將應用程序的配置和狀態保存在一個pickle中。要運行採用了這種方案的應用需要兩個步驟：
使用mktap工具創建一個代表該應用的pickle（該工具現已廢棄不用）。
使用twistd命令行工具進行unpickle操作，然後運行該應用。
這個過程是受Smalltalk p_w_picpaths的啓發，因爲我們討厭那種臨時性的且難以使用的專用配置語言，不希望它們在項目中不斷擴散。我們更希望在Python中表示配置的細節。
很快，TAP文件就引入了不必要的複雜性。修改Twisted中的類並不會使pickle中這些類的實例得到改變。在pickle對象上使用新版本的類方法或屬性時可能會使整個應用崩潰。因此“升級版”的概念得以引入，即將pickle對象升級到新的API版本。但這就會出現升級版本的矩陣化現象，出現各種不同版本的pickle對象，因此單元測試時需要維護涵蓋所有可能的升級路徑。想全面地跟蹤所有的接口變化依然很難，而且容易出錯。
TAP以及相關的組件全部被廢除了，最終從Twisted中完全剔除掉。取而代之的是TAC文件和插件系統。TAP這個縮寫被重新定義爲Twisted Application Plugin（Twisted應用插件），如今已經很難在Twisted中找到pickle系統的蹤跡了。
我們從TAP的慘敗中得到的教訓是：如果可維護性要達到合理化的程度，則持久性數據就需要有一個明確的模式。更一般的是，我們學到了如何爲項目增加複雜度：爲了解決某個問題而需要引入一個新系統時，我們要正確理解這個方案的複雜性，並經過測試。新系統所帶來的價值應該明顯大於其複雜性。確保了這一點之後我們才能將方案付諸於項目中。
web2：重構的教訓
雖然這基本上不屬於架構設計上的決策，但從項目管理的角度來看，重寫Twisted的Web實現對於Twisted的外在形象以及維護者對代碼庫中其他部分做架構改善的能力卻有着長遠的影響，因此這裏值得我們簡單討論一下。
在2000年中期，Twisted的開發者決定完全重寫twisted.web API，在Twisted代碼庫中將其作爲一個單獨的項目實現，這就是web2。web2將包含許多針對原有twisted.web的改善和提升，包括完全支持HTTP1.1，以及對流式數據的API支持。
web2最初只是試驗性的項目，但最終被大型項目所採用，甚至意外的得以在Debian系統上打包發佈。twisted.web和web2的開發一直並行持續了多年，新用戶常常被這兩個並行的項目搞混，關於究竟應該使用哪種實現缺乏明確的提示，這使得新用戶很沮喪。轉換到web2的情況從未出現，終於在2011年開發者將其從代碼庫中移除，官方主頁上再也看不到它了。web2中做出的一些改進也被慢慢地移植回twisted.web中。
Twisted獲得了難以導航且結構混亂，容易使新開發者感到困惑的“惡名”，這個印象部分歸功於web2。以至於數年之後，Twisted社區仍然在同這種不和諧的名聲做鬥爭。
我們從web2中汲取的教訓是：從頭開始重構一個項目通常都是糟糕的主意。但如果必須這麼做，請確保開發者社區能夠懂得這麼做的長遠意義，而且在用戶社羣中要有明確的選擇該使用哪種實現。
如果Twisted能夠倒退回web2的時代，開發者們應該會對twisted.web做一系列向後兼容型的修改而不是去重構。
緊跟互聯網的浪潮
我們使用互聯網的方式還在持續演進中。把多種協議的實現作爲軟件核心的一部分，這個技術決策使得Twisted揹負了維護這些協議的沉重負擔。隨着標準的改變以及對新協議的採納，原有的實現必須跟着演進，同時需要嚴格的保證向後兼容性。
Twisted基本上是一個志願者驅動型的項目，項目發展的限制因素不是技術社區的熱情，而在於志願者的時間。比如說，1999年的RFC 2616中定義了HTTP 1.1規範，而在Twisted的HTTP協議實現中增加對HTTP 1.1的支持卻在2005年纔開始，等到完成時已經是2009年了。1998年RFC 2460中定義了對IPv6的支持，而Twisted對其的支持還在進行中，但是直到2011年都未能合並進去。
隨着所支持的操作系統的接口改變，實現也要跟着演進。比如，epoll事件通知機制是在2002年加入到Linux 2.5.44版中的，Twisted隨之也發展出基於epoll的reactor事件循環來利用這個新的系統接口。2007年時，蘋果公司發佈的OS 10.5 Leopard系統中，系統調用poll的實現居然不支持外設，對於蘋果公司來說這個問題足以讓他們在系統自帶的Python中屏蔽掉select.poll接口。Twisted不得不自行解決這個問題，並從那時起就對用戶提供文檔說明。
有時候，Twisted的開發並沒有緊跟網絡世界的變化，有一些改進被移到核心層之外的程序庫中去了。比如Wokkel project，這是對Twisted的Jabber/XMPP支持的改進合集，已經作爲“待合入”的獨立項目有幾年之久了，但還沒有看到合入的希望。在2009年也曾經嘗試過增加WebSocket到Twisted中，因爲瀏覽器已經開始採納對新協議的支持了。但開發計劃最終卻轉到其他外部項目中去了，因爲開發者們決定暫不包含新的協議，直到IETF把它從草案轉變成標準以後再說。
所有這一切都在說明，庫和附加組件的擴散有力的證明了Twisted的靈活性和可擴展性。通過採用嚴格的測試驅動開發策略以及文檔化和編碼規範標準，這樣做能夠幫助項目避免出現需要“回爐”的情況。在維護大量所支持的協議和平臺的同時保持向後兼容性。Twisted是一個成熟、穩定的項目，並繼續保持有非常活躍的開發狀態。
Twisted期待着在下一個十年裏成爲你遨遊互聯網的引擎。