Rmi和Socket比較

RMI技術比較socket的網絡程式設計主要有以下幾個方面：

第一、RMI是面向對象的，而後者不是。

第二、RMI是與語言相綁定的。比如當你使用Java RMI技術的時候，用戶端與伺服器端都必須使用Java開發。而socket的網絡程式設計是使用獨立于開發語言的，甚至獨立于平台。基于socket的網絡程式設計，用戶端與伺服器端可以使用不同開發語言和不同的平台。

第三、從網絡協定棧的觀點來看，RMI與socket的網絡程式設計處于不同層次上。基于socket的網絡程式設計位于TCP協定之上，而RMI在TCP協定之上，又定義了自己的應用協定，其傳輸層采用的是Java遠端方法協定(JRMP)。可見，在網絡協定棧上，基于RMI的應用位置更高一些，這也決定了，與socket的網絡程式設計相比，RMI會喪失一些靈活性和可控性，但是好處是它帶給了應用開發者更多的簡潔，友善和易用。比如：如果你用的是RMI,你不需要關心消息是怎麼序列化的，你隻需要像本地方法調用一樣，使用RMI。代價是：應用開發者無法很好地控制消息的序列化機制。

第四、這是最後一點不同，我認為也是比較重要的一點，就是兩種方法的性能比較，其往往決定着你将使用那種技術來開發你的應用。

實驗的結果是：RMI與TCP based socket相比，傳輸相同的有效資料，RMI需要占用更多的網絡帶寬（protocol overhead）。從這裡，我們可以得出一個一般性的結論：RMI主要是用于遠端方法的”調用“（RMI是多麼的名符其實:)），其技術内涵強調的是 “調用”，基于此，我能想到的是：移動計算，和遠端控制，當你的應用不需要在client與server之間傳輸大量的資料時，RMI是較好的選擇，它簡潔、易于開發。但是，一旦你的應用需要在client與server之間傳輸大量的資料，極端的，比如FTP應用，則RMI是不适合的，我們應該使用 socket。

PS: RMI的效率還是很高的，一般情況下會比Hessian更高效，比Web Service更是高效很多；當然和socket這種東東相比，當然要低效一點了，socket更底層一些啊。RMI的具體實作，依然是依賴于底層的Socket程式設計。