xml-rpc 實(shí)現(xiàn)的文件共享

這個項(xiàng)目取材與http://www.the5fire.com/python-project8-xml-rpc.html 。是python基礎(chǔ)教程中的十個例子中的第八個。主要的實(shí)現(xiàn)原理如下：

每一個客戶端都是一個節(jié)點(diǎn)。每一個節(jié)點(diǎn)，都啟動一個 xml-rpc服務(wù)器。在 xml-rpc服務(wù)器中，維護(hù)著一個所有節(jié)點(diǎn)的集合。原文的例子，功能太少，只能下載。后來我加了一個ls 命令，可以查看包括自己的和所有節(jié)點(diǎn)的文件。原項(xiàng)目中的節(jié)點(diǎn)列表，必須是手動給出的，相當(dāng)麻煩，是通過一個叫urlfile的文件來維護(hù)的。在我的這個項(xiàng) 目中，維護(hù) 節(jié)點(diǎn)的信息是通過程序自己學(xué)習(xí)到的。每當(dāng)一個節(jié)點(diǎn)啟動的時候，該節(jié)點(diǎn)就會把自己的xml-rpc服務(wù)器的訪問url，通過udp廣播的方式，廣播給某一個 端口。同時每一個節(jié)點(diǎn)，只要它啟動后，會監(jiān)聽某一個端口上的，有關(guān)xml-rpc服務(wù)器的訪問url的監(jiān)聽。只要收到信息，就把它寫入到節(jié)點(diǎn)列表中。通過 fetch下載文件時，如果發(fā)現(xiàn)了異常，則從節(jié)點(diǎn)列表中刪除它。

現(xiàn)在假如有兩個節(jié)點(diǎn)（啟動了client.py文件的機(jī)器） a和b，a中的節(jié)點(diǎn)列表中有b，同樣b中也有，當(dāng)a嘗試著fetch 一個文件時，如果沒有在a中查找到的話，則會去找b,但是b中的節(jié)點(diǎn)列表是a,b會去找a。。。。。這樣就形成了阻塞。原項(xiàng)目中，是通過一個url列表來 維護(hù)的。但是這個項(xiàng)目中，a機(jī)器對于自己的url是localhost,b也是localhost，但是對于a來講b就不是localhost。所以我的 項(xiàng)目中，是通過維護(hù)一個secret列表來判斷，下一個要查找的節(jié)點(diǎn)是不是已經(jīng)被查過了。但是同時得先知道下一個節(jié)點(diǎn)的secret值，但是如果下一節(jié)點(diǎn) 就是上一個節(jié)點(diǎn)的話，還是會有阻塞，所以把xml-rpc做成多線程就很必要了。新構(gòu)建一個類class ThreadRPC(ThreadingMixIn, SimpleXMLRPCServer) 。這樣ThreadRPC就變成了多線程的SimpleXMLRPCServer。

本來文件的傳輸是使用了xml-rpc。后來我把它獨(dú)立出來了。單獨(dú)作為一個文件傳輸服務(wù)，TranServer。這個文件傳輸，不使用xml- rpc，而是直接用socket。用了SocketServer框架。本來是想用asynchat的。但是后來發(fā)現(xiàn)，這個異步框架，有點(diǎn)蛋疼。比如說它的 push方法。是會把數(shù)據(jù)放到叫producer_fifo的fifo數(shù)據(jù)結(jié)構(gòu)中。這個做會出現(xiàn)一個大問題。我讀本地的文件速度遠(yuǎn)遠(yuǎn)快于發(fā)送的數(shù)度，當(dāng)體 積大的時候，更是如此。所以使用push傳輸，會發(fā)現(xiàn)內(nèi)存占用越來越大，越來越大。。。如果不使用push,而是使用send，會發(fā)現(xiàn)數(shù)據(jù)不同步.鑒于這 些問題，所以我沒有采用異步，而是使用了多線程的SocketServer, ThreadingMixIn

配置文件

[global]

# 監(jiān)聽節(jié)點(diǎn)的端口

listen_port = 1111

# 數(shù)據(jù)傳送的端口

data_port = 1234

# 要共享的目錄

share_dir = /tmp/a

使用方法

啟動節(jié)點(diǎn) : python client.py

獲取文件列表: ls

下載文件: fetch xxx

查看文件內(nèi)容: cat xxx [要查看的前n位]