原文連結：http://www.aosabook.org/en/twisted.html
作者：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 getPage
def processPage(page):
print page
def logError(error):
print error
def 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 reactor
import getPage
def 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 callback
getPage(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 reactor
import getPage
def processPage(page):
print page
def logError(error):
print error
def finishProcessing(value):
print "Shutting down..."
reactor.stop()
url = "http://google.com"
deferred = getPage(url) # getPage returns a Deferred
deferred.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, reactor
class 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, protocol
class 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, reactor
class 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 [-] Logopened.
2011-11-19 22:23:07-0500 [-]twistd11.0.0 (/usr/bin/python2.7.1)startingup.
2011-11-19 22:23:07-0500 [-]reactor class:twisted.internet.selectreactor.SelectReactor.
2011-11-19 22:23:07-0500 [-]echo.EchoFactorystartingon8000
2011-11-19 22:23:07-0500 [-] Startingfactory<echo.EchoFactoryinstanceat0x12d8670>
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 implements
from twisted.python import usage
from twisted.plugin import IPlugin
from twisted.application.service import IServiceMaker
from twisted.application import internet
from echo import EchoFactory
class 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 = Options
def 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啟動伺服器的例子：
twistdweb–port 8080 –path .
這條指令将在8080端口啟動一個HTTP伺服器，在目前目錄中負責處理靜态和動态頁面請求。
twistd dns –p 5553 –hosts-file=hosts
這條指令在端口5553上啟動一個DNS伺服器，解析指定的檔案hosts中的域名，這個檔案的内容格式同/etc/hosts一樣。
sudo twistd conch –ptcp:2222
這條指令在端口2222上啟動一個SSH伺服器。ssh的密鑰必須獨立設定。
twistdmail –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 images的啟發，因為我們讨厭那種臨時性的且難以使用的專用配置語言，不希望它們在項目中不斷擴散。我們更希望在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期待着在下一個十年裡成為你遨遊網際網路的引擎。