第二部分:低效的詩歌服務器來啓發對Twisted機制的理解
現在我們可能要寫一些代碼。在開始之前，我們都做出一些必要的假設。
關於對你的假設
在展開討論前，我假設你已經有過用Python寫同步程序的經歷並且至少知道一點有關Python的Sockt編程的經驗。如果你從沒有寫過Socket程序，或許你可以去看看Socket模塊的文檔，尤其是後面的示例代碼。如果你沒有用過Python的話，那後面的描述對你來說可能比看周易還痛苦。
你所使用的計算機的情況（想的真周到，：））
我一般是在Linux上使用Twisted，這個系列的示例代碼也是在Linux下完成的。首先聲明的是我並沒有故意讓代碼失去平臺無關性，但我所講述的一些內容確實可能僅僅適應於Linux和其它的類Unix（比如MAC OSX或FreeBSD）。WIndows是個奇怪詭異的地方（？？爲什麼這麼評價Windows呢），如果你想嘗試在它上面學習這個系列，抱歉，如果出了問題，我無法提供任何幫助。
並且假設你已經安裝了近期版本的Python和Twisted。我所提供的示例示例代碼是基於Python2.5和Twisted8.2.0。
你可以在單機上運行所有的示例代碼，也可以在網絡系統上運行它們。但是爲了學習異步編程的機制，單機上學習是比較理想的。
獲取代碼的方法
使用git工具來獲取Dave的最新示例代碼。在shell或其它命令行上輸入以下命令（假設已經安裝git）：
git clone git://github.com/jdavisp3/twisted-intro.git
下載結束後，解壓並進入第一層文件夾（你可以看到有個README文件）。
低效的詩歌服務器
雖然CPU的處理速度遠遠快於網絡，但網絡的處理速度仍然比人腦快，至少比人類的眼睛快。因此，想通過網絡來獲得CPU的視角是很困難的，尤其是在單機的迴環模式中數據流全速傳輸時，更是困難重重。
我們所需要的是一個慢速低效詩歌服務器，其用人爲的可變延時來體現影響結果。畢竟服務器要提供點東西嗎，我們就提供詩歌好了。目錄下面有個子目錄專門存放詩歌用的。
最簡單的慢速詩歌服務器在blocking-server/slowpoetry.py中實現。你可用下面的方式來運行它。
python blocking-server/slowpoetry.py poetry/ecstasy.txt
上面這個命令將啓動一個阻塞的服務器，其提供“Ecstasy”這首詩。現在我們來看看它的源碼內容，正如你所見，這裏面並沒有使用任何Twisted的內容，只是最基本的Socket編程操作。它每次只發送一定字節數量的內容，而每次中間延時一段時間。默認的是每隔0.1秒發送10個比特，你可以通過-delay和
-num-bytes參數來設置。例如每隔5秒發送50比特：
python blocking-server/slowpoetry.py --num-bytes 50 –delay 5poetry/ecstasy.txt
當服務器啓動時，它會顯示其所監聽的端口號。默認情況下，端口號是在可用端口號池中隨機選擇的。你可能想使用固定的端口號，那麼無需更改代碼，只需要在啓動命令中作下修改就OK了，如下所示：
python blocking-server/slowpoetry.py --port 10000 poetry/ecstasy.txt
如果你裝有netcat工具，可以用如下命令來測試你的服務器（也可以用telnet）：
netcat localhost 10000
如果你的服務器正常工作，那麼你就可以看到詩歌在你的屏幕上慢慢的打印出來。對！你會注意到每次服務器都會發送過一行的內容過來。一旦詩歌傳送完畢，服務器就會關閉這條連接。
默認情況下，服務器只會監聽本地迴環的端口。如果你想連接另外一臺機子的服務器，你可以指定其IP地址內容，命令行參數是 -iface選項。
不僅是服務器在發送詩歌的速度慢，而且讀代碼可以發現，服務器在服務一個客戶端時其它連接進來的客戶端只能處於等待狀態而得不到服務。這的確是一個低效慢速的服務器，要不是爲了學習，估計沒有任何其它用處。
阻塞模式的客戶端
在示例代碼中有一個可以從多個服務器中順序（一個接一個）地下載詩歌的阻塞模式的客戶端。下面讓這個客戶端執行三個任務，正如第一個部分圖1描述的那樣。首先我們啓動三個服務器，提供三首不同的詩歌。在命令行中運行下面三條命令：
python blocking-server/slowpoetry.py --port 10000 poetry/ecstasy.txt --num-bytes 30 python blocking-server/slowpoetry.py --port 10001 poetry/fascination.txtpython blocking-server/slowpoetry.py --port 10002 poetry/science.txt
如果在你的系統中上面那些端口號有正在使用中，可以選擇其它沒有被使用的端口。注意，由於第一個服務器發送的詩歌是其它的三倍，這裏我讓第一個服務器使用每次發送30個字節而不是默認的10個字節，這樣一來就以3倍於其它服務器的速度發送詩歌，因此它們會在幾乎相同的時間內完成工作。
現在我們使用阻塞模式的客戶端來獲取詩歌，運行如下所示的命令：
python blocking-client/get-poetry.py 10000 10001 10002
如果你修改了上面服務口器的端口，你需要在這裏時行相應的修改以保持一致。由於這個客戶端採用的是阻塞模式，因此它會一首一首的下載，即只有在完成一首時纔會開始下載另外一首。這個客戶端會像下面這樣打印出提示信息而不是將詩歌打印出來：
Task 1: get poetry from: 127.0.0.1:10000
Task 1: got 3003 bytes of poetry from 127.0.0.1:10000 in 0:00:10.126361
Task 2: get poetry from: 127.0.0.1:10001
Task 2: got 623 bytes of poetry from 127.0.0.1:10001 in 0:00:06.321777
Task 3: get poetry from: 127.0.0.1:10002
Task 3: got 653 bytes of poetry from 127.0.0.1:10002 in 0:00:06.617523
Got 3 poems in 0:00:23.065661
這圖1最典型的文字版了，每個任務下載一首詩歌。你運行後可能顯示的時間會與上面有所差別，並且也會隨着你改變服務器的發送時間參數而改變。嘗試着更改一下參數來觀測一下效果。
異步模式的客戶端
現在，我們來看看不用Twisted構建的異步模式的客戶端。首先，我們先運行它試試。啓動使用前面的三個端口來啓動三個服務器。如果前面開啓的還沒有關閉，那就繼續用它們好了。接下來，我們通過下面這段命令來啓動我們的異步模式的客戶端：
python async-client/get-poetry.py 10000 10001 10002
你或許會得到類似於下面的輸出：
Task 1: got 30 bytes of poetry from 127.0.0.1:10000
Task 2: got 10 bytes of poetry from 127.0.0.1:10001
Task 3: got 10 bytes of poetry from 127.0.0.1:10002
Task 1: got 30 bytes of poetry from 127.0.0.1:10000
Task 2: got 10 bytes of poetry from 127.0.0.1:10001
...
Task 1: 3003 bytes of poetry
Task 2: 623 bytes of poetry
Task 3: 653 bytes of poetry
Got 3 poems in 0:00:10.133169
這次的輸出可能會比較長，這是由於在異步模式的客戶端中，每次接收到一段服務器發送來的數據都要打印一次提示信息，而服務器是將詩歌分成若干片段發送出去的。值得注意的是，這些任務相互交錯執行，正如第一部分圖3所示。
嘗試着修改服務器的設置（如將一個服務器的延時設置的長一點），來觀察一下異步模式的客戶端是如何針對變慢的服務器自動調節自身的下載來與較快的服務器保持一致。這正是異步模式在起作用。
還需要值得注意的是，根據上面的設置，異步模式的客戶端僅在10秒內完成工作，而同步模式的客戶端卻使用了23秒。現在回憶一下第一部分中圖3與圖4.通過減少阻塞時間，我們的異步模式的客戶端可以在更短的時間裏完成下載。誠然，我們的異步客戶端也有些阻塞發生，那是由於服務器太慢了。由於異步模式的客戶端可以在不同的服務器來回切換，它比同步模式的客戶產生的阻塞就少得多。
更近一步的觀察
現在讓我們來讀一下異步模式客戶端的代碼。注意其與同步模式客戶端的差別：
1.異步模式客戶端一次性與全部服務器完成連接，而不像同步模式那樣一次只連接一個。
2.用來進行通信的Socket方法是非阻塞模的，這是通過調用setblocking(0來實現的。
3.select模塊中的select方法是用來識別是其監視的socket是否有完成數據接收的，如果沒有它就處於阻塞狀態。
4.當從服務器中讀取數據時，會盡量多地從Sockt讀取數據直到它阻塞爲止，然後讀下一個Sockt接收的數據（如果有數據接收的話）。這意味着我們需要跟蹤記錄從不同服務器傳送過來詩歌的接收情況（因爲，一首詩的接收並不是連續完成，所以需要保證每個任務的可連續性，就得有冗餘的信息來完成這一工作）。異步模式中客戶端的核心就是最高層的循環體，即get_poetry函數。這個函數可以被拆分成兩個步驟：
1.使用select函數等待所有Socket，直到至少有一個socket有數據到來。
2.對每個有數據需要讀取的socket，從中讀取數據。但僅僅只是讀取有效數據，不能爲了等待還沒來到的數據而發生阻塞。
3.重複前兩步，直到所有的socket被關閉。
可以看出，同步模式客戶端也有個循環體（在main函數內），但是這個循環體的每個迭代都是完成一首詩的下載工作。而在異步模式客戶端的每次迭代過程中，我們可以完成所有詩歌的下載或者是它們中的一些。我們並不知道在一個迭代過程中，在下載那首詩，或者一次迭代中我們下載了多少數據。這些都依賴於服務器的發送速度與網絡環境。我們只需要select函數告訴我們那個socket有數據需要接收，然後在保證不阻塞程序的前提下從其讀取儘量多的數據。
如果在服務器端口固定的條件下，同步模式的客戶端並不需要循環體，只需要順序羅列三個get_poetry就可以了。但是我們的異步模式的客戶端必須要有一個循環體來保證我們能夠同時監視所有的socket端。這樣我們就能在一次循環體中處理儘可能多的數據。這個利用循環體來等待事件發生，然後處理髮生的事件的模型非常常見，而被設計成爲一個模式：reactor模式。其圖形化表示如圖5所示：
這個循環就是個”reactor“（反應堆），因爲它等待事件的發生然對其作爲相應的反應。正因爲如此，它也被稱作事件循環。由於交互式系統都要進行I/O操作，因此這種循環也有時被稱作select loop,這是由於select調用被用來等待I/O操作。因此，在本程序中的select循環中，一個事件的發生意味着一個socket端處有數據來到。值得注意的是，select並不是唯一的等待I/O操作的函數，它僅僅是一個比較古老的函數而已（因此才被用的如此廣泛）。現在有一些新API可以完成select的工作而且性能更優，它們已經在不同的系統上實現了。不考慮性能上的因素，它們都完成同樣的工作：監視一系列sockets（文件描述符）並阻塞程序，直到至少有一個準備好時行I/O操作。
嚴格意義上來說，我們的異步模式客戶端中的循環並不是reactor模式，因爲這個循環體並沒有獨立於業務處理（在此是接收具體個服務器傳送來的詩歌）之外。它們被混合在一起。一個真正reactor模式的實現是需要實現循環獨立抽象出來並具有如下的功能：
1.監視一系列與你I/O操作相關的文件描述符（description)
2.不停地向你彙報那些準備好I/O操作的文件描述符
一個設計優秀的reactor模式實現需要做到：
1.處理所有不同系統會出現的I/O事件
2.提供優雅的抽象來幫助你在使用reactor時少花些心思去考慮它的存在
3.提供你可以在抽象層外（treactor實現）使用的公共協議實現。
好了，我們上面所說的其實就是Twisted—健壯、跨平臺實現了reactor模式並含有很多附加功能。在第三部分中，實現Twisted版的下載詩歌服務時，我們將開始寫一些簡單的Twisted程序。