socket vs rmi載）

一般來說，基於CS（client-server)軟體架構的開發技術有很多種。比較常用的有：基於socket的網路編程、RPC、基於Java技術的RMI（當然C#也有類似技術）、CORBA等。在這裡我們只是對基於socket的網路編程與RMI作個對比，有助於我們瞭解它們各自的應用領域，協助我們在面對一個具體問題的時候選用適合的技術。另外，本文所做的討論可以認為是脫離了語言層面的東西，只是對技術的本身做一個討論，無關乎你是用C++、C#或Java 在開發。
一、RMI技術簡介
        本文就以Java為例，簡單介紹一下RMI技術。
        從Java1.1開始，遠程方法調用作為Java分布式對象技術成為Java核心的API之一(在java.rmi.* 包)。RMI的引入，使得Java程式之間能夠實現靈活的，可擴充的分布式通訊。RMI允許Java對象存在於多個不同的地址空間，分布在不同的Java虛擬機器上。每一個地址空間可以在同一台主機上或者網路上不同的電腦上。由於遠程方法調用跨越不同的虛擬機器邊界到不同的指定的地址空間，所以沒有對象共用的全域變數，這就需要對象序列化(Object Serialization)API，它使得Java對象能夠在不同的JVM之間傳遞。對象序列化是特別為Java的對象設計的，這就意味著Java程式中的對象可以作為對象參數存取（可序列化的對象必須實現Serializable介面）。結合RMI和對象序列化機制，就可以訪問越過本地Java虛擬機器邊界的對象以及資料。通過RMI，可以調用遠程對象的遠程方法，而通過Java對象序列化機制可以將對象傳遞給這些方法。
        最基本的Java模型並沒有提供將遠程主機上的Java對象看作本地Java程式地址空間一部分的能力，而RMI禰補了這一不足。另外，由於Java與硬體平台無關的特性，無論是同構的系統還是異構的系統，RMI不需移植就可以順利運行。
       RMI為Java平台的分散式運算提供了一個簡單而直接的模型。因為Java的RMI技術是基於Java平台的，所以它將Java平台的安全性和可移植性等優點帶到了分散式運算中。RMI大大擴充Java的網路計算能力，它為編寫基於分布式對象技術的企業級Internet/Intranet應用提供了強大的系統平台支援。
      Java RMI體繫結構如：

二、基於socket的網路編程
        當你使用socket進行網路應用開發的時候，一般的思路是“訊息驅動邏輯”，即這樣的軟體系統一般具有以下特點：
       (1) 用戶端與伺服器端依靠訊息進行通訊。
       (2) 用戶端或者伺服器端都需要一個訊息派遣器，將訊息投遞給具體的massage handler
       (3) 用戶端或者伺服器端利用massage handler進行邏輯交易處理
 見：

        使用socket開發的軟體系統，從技術的本質上來講，有以下幾個特點：
        (1) 基於TCP協議的通訊
        (2) 應用程式本身需要提供對訊息的序列化處理（所謂的序列化指的是將訊息輸出到網路流中)
        (3) 用戶端與伺服器端需要事先商議好它們之間的通訊協議即它們互動的訊息格式
        (4) 由於是訊息驅動邏輯，從本質上決定了這樣的編程模式很難物件導向化
三、RMI Vs Sochet
        RMI技術比較socket的網路編程主要有以下幾個方面：
        第一、.RMI是物件導向的，而後者不是。
        第二、.RMI是與語言相綁定的。比如當你使用Java RMI技術的時候，用戶端與伺服器端都必須使用Java開發。而socket的網路編程是使用獨立於開發語言的，甚至獨立於平台。基於socket的網路編程，用戶端與伺服器端可以使用不同開發語言和不同的平台。
       第三、從網路通訊協定棧的觀點來看，RMI與socket的網路編程處於不同層次上。基於socket的網路編程位於TCP協議之上，而RMI在TCP協議之上，又定義了自己的應用協議，其傳輸層採用的是Java遠程方法協議(JRMP)。可見，在網路通訊協定棧上，基於RMI的應用位置更高一些，這也決定了，與socket的網路編程相比，RMI會喪失一些靈活性和可控性，但是好處是它帶給了應用開發人員更多的簡潔，方便和易用。比如：如果你用的是RMI,你不需要關心訊息是怎麼序列化的，你只需要像本地方法調用一樣，使用RMI。代價是：應用開發人員無法很好地控制訊息的序列化機制。
      第四、這是最後一點不同，我認為也是比較重要的一點，就是兩種方法的效能比較，其往往決定著你將使用那種技術來開發你的應用。以下引用Adrian Reber在Network-programming with RMI文中對TCP和RMI所做的一個比較，其做的實驗主要是對兩者在網路傳輸的頻寬上作的對比： 在網路上傳輸2 byte的有效資料，對於TCP而言，總共有478 byte被額外傳輸，而對於RMI, 1645byte被額外傳輸。
以下是兩者的trace結果：
TCP:
46037 > 12345 [SYN] Seq=801611567 Ack=0 Win=5840 Len=0
12345 > 46037 [SYN, ACK] Seq=266515894 Ack=801611568 Win=10136 Len=0
46037 > 12345 [ACK] Seq=801611568 Ack=266515895 Win=5840 Len=0
12345 > 46037 [PSH, ACK] Seq=266515895 Ack=801611568 Win=10136 Len=1
46037 > 12345 [ACK] Seq=801611568 Ack=266515896 Win=5840 Len=0
12345 > 46037 [FIN, PSH, ACK] Seq=266515896 Ack=801611568 Win=10136 Len=1
46037 > 12345 [RST, ACK] Seq=801611568 Ack=266515898 Win=5840 Len=0
RMI:
42749 > rmiregistry [SYN, ECN, CWR]
Seq=3740552479 Ack=0 Win=32767 Len=0
rmiregistry > 42749 [SYN, ACK, ECN]
Seq=3749262223 Ack=3740552480 Win=32767 Len=0
42749 > rmiregistry [ACK] Seq=3740552480 Ack=3749262224 Win=32767 Len=0
JRMI, Version: 2, StreamProtocol
rmiregistry > 42749 [ACK] Seq=3749262224 Ack=3740552487 Win=32767 Len=0
JRMI, ProtocolAck
42749 > rmiregistry [ACK] Seq=3740552487 Ack=3749262240 Win=32767 Len=0
Continuation
rmiregistry > 42749 [ACK] Seq=3749262240 Ack=3740552506 Win=32767 Len=0
JRMI, Call
rmiregistry > 42749 [ACK] Seq=3749262240 Ack=3740552556 Win=32767 Len=0
JRMI, ReturnData
42749 > rmiregistry [ACK] Seq=3740552556 Ack=3749262442 Win=32767 Len=0
JRMI, Ping
JRMI, PingAck
42749 > rmiregistry [ACK] Seq=3740552557 Ack=3749262443 Win=32767 Len=0
JRMI, DgcAck
42749 > rmiregistry [FIN, ACK]
Seq=3740552572 Ack=3749262443 Win=32767 Len=0
rmiregistry > 42749 [FIN, ACK]
Seq=3749262443 Ack=3740552573 Win=32767 Len=0
42749 > rmiregistry [ACK] Seq=3740552573 Ack=3749262444 Win=32767 Len=0
        實驗的結果是：RMI與TCP based socket相比，傳輸相同的有效資料，RMI需要佔用更多的網路頻寬（protocol overhead）。從這裡，我們可以得出一個一般性的結論：RMI主要是用於遠程方法的”調用“（RMI是多麼的名符其實:)），其技術內涵強調的是“調用”，基於此，我能想到的是：移動計算，和遠端控制，當你的應用不需要在client與server之間傳輸大量的資料時，RMI是較好的選擇，它簡潔、易於開發。但是，一旦你的應用需要在client與server之間傳輸大量的資料，極端的，比如FTP應用，則RMI是不適合的，我們應該使用socket。

四、參考資料：
Network-programming with RMI， by Adrian Reber, URL:
http://42.fht-esslingen.de/~adrian/master/rmi.pdf

 

 

http://www.cppblog.com/sherrylso/archive/2007/07/28/28906.html