A Twisted Poetry Server

既然我們已經學了這么多twisted client 的編寫,現在讓我們來用twisted來重新實現一下我們的poetry server 吧.我們要多謝謝twisted 抽象的普遍性,貌似我們已經學了twisted 的我們需要知道的大部分東西了.看下我們的twisted poetry server twisted-server-1/fastpoetry.py,它被叫做fastpoetry 應為這個server可以盡可能快的發送一首詩.它的代碼要比cilent 中的代碼要少.

讓我們一次分析一小段的代碼,首先,PoetryProtocol:

class PoetryProtocol(Protocol):

????def connectionMade(self):
????????self.transport.write(self.factory.poem)
????????self.transport.loseConnection()

就像client 一樣,server 用了一個單獨的protocol 實例來管理每一個不同的連接.這里的protocol 是我們server端的poetry protocol.因為我的protocol 是嚴格的單向的(one-way不知道怎么翻譯),server protocol 實例僅僅需要關心發送數據.我們的protocol 需要在連接建立之后立即開始傳送數據,所以我們實現了connectionMade 方法,它是一個callback,在一個protocol 實例連接上一個transport之后觸發.

我們的connectionMade方法讓transport 去做兩件事:發送整首詩的內容(self.transport.write)和關閉連接(self.transport.loseConnection).當然,這兩個操作都是異步的.所以write方法的調用意味著”最后我會把所有的數據都送出去”,close方法的調用意味著”一但我讓你送的數據都送完了再關閉這個連接”.

正如你看到的,protocol 從factory那里接受整首詩歌的內容,就像下面的代碼所描述的:

class PoetryFactory(ServerFactory):

????protocol = PoetryProtocol

????def __init__(self, poem):
????????self.poem = poem

我們的factory 真正干的工作除了創建PoetryProtocol 的實例以外,也保存了PoetryProtocol 需要的poem 的內容.
注意我們這里實現的是ServerFactory而不是ClientFactory.因為我們的server 是被動的監聽連接,我們不需要ClientFactory提供的額外的方法.我們是怎么確定要用 ServerFactory的呢?因為我們要用reactor 的listenTCP 方法,手冊中講到那個方法的factory 參數需要是一個ServerFactory 的實例.

下面是main 函數:

def main():
????options, poetry_file = parse_args()

????poem = open(poetry_file).read()

????factory = PoetryFactory(poem)

????from twisted.internet import reactor

????port = reactor.listenTCP(options.port or 0, factory,
?????????????????????????????interface=options.iface)

????print 'Serving %s on %s.' % (poetry_file, port.getHost())

????reactor.run()

它已經做了三件事情:

????讀取我們將要服務的詩的內容
????創建一個PoetryFactory
????用listenTCP去告訴twsited 在一個端口上監聽連接,并用我們的factory為每一個連接 創建protocol 的實例

?

做完這些之后,剩下的要做的事情就是告訴reactor 開始循環.你可以用以前咱們寫的client 測試一下.

Discussion

回想一下在五部分的圖片八和圖片九.這些圖片描述了一個新的protocol 實例是怎樣在twisted 創建一個新的連接之后被創建和初始化的.在server 端twisted 接受一個新來的連接也是采用了同樣的原理.那就是為什么 connectTCP 和 listenTCP都需要一個factory 的參數.

在圖片九中我們沒有描述的是connectionMade callback 會在Protocal 初始化的時候被調用,不管什么情況下都會發生的,但是我們在client 用不到它.我們在client 中用到的一些protocol 方法在server 的protocol 中也不會用到.如果我們想折騰的話,我們可以寫一個統一的protocol,又可以用在客戶端又可用在服務端,在twisted 中的一些protocol 也確實是這么做的.例如,NetstringReceiver protocol 既可以用來從Transport中讀也可以向Transport 中寫.

我們暫時就不寫一個low-level 的poetry server了,但是我們要想明白這個twisted server到底做了什么.首先,調用listenTCP 讓twisted 創建一個監聽的socket并把它加入到事件循環里面.這個socket 上的事件并不是告訴你有數據可讀了,而是告訴你有一個client 在等待要連上來.

twisted 會自動的接收傳過來的連接請求,并創建一個client socket 連接server 和 client.這個client socket也被加入事件循環,然后twisted 創建一個新的transport 和 一個PoetryProtocol 的實例來為這個client socket 服務. 所以Protocol 實例是一直和client socket 連著的,而不是負責監聽的socket.

圖片二十六描述了這個過程:

圖片二十六

在這張圖片中有三個client 連接著poetry server.每一個Transport 代表了一個client socket,listening socket 總共創建了四個文件描述符并讓select loop 來監測.當一個client 斷開跟它關聯的Transport,PoetryProtocol 會被間接引用被被垃圾回收器回收.同時PoetryFactory會繼續存在只要我們還在監聽新的連接到來.

client sockets 和他們關聯的python 對象不會活太久如果我們要處理的詩很短的話.但是如果有成千上百的并發的client 的話,我們的poetry server 會垮掉.twisted 本身對同時能處理的連接數量并沒有內置的限制.當然,隨著你不斷增加server 的負載,你會發現你的server最后會撐不住,或者達到了操作系統內部的限制.對于高負載的系統來說,認真的抗壓測試是非常重要的.

twisted 對我們能監聽的端口的數量也沒有限制.實際上,一個twisted 的進程可以監聽n多的端口并在不同的端口提供不同的服務.

我們的server 還少很多東西.首先,它沒有記錄任何的可以幫助我們進行dedug 或者分析網絡流浪的日志.在一個是,這個server 不是以守護進程來運行的,這就讓它很容易掛掉,比如不小心按了Ctrl-C,或者登出了.我們在將來都會修復這些問題.在第十二部分,我們將會寫令一個可以變換詩的server.

總結

以上是生活随笔為你收集整理的twisted系列教程十一 — 一个twisted 的服务端的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。