RMI RPC socket

 

  1.RPC

       RPC（Remote Procedure Call Protocol）遠程過程調用協議，它是一種經過網絡從遠程計算機程序上請求服務，而不須要了解底層網絡技術的協議。RPC不依賴於具體的網絡傳輸協議，tcp、udp等均可以。因爲存在各式各樣的變換和細節差別，相應的rpc也派生出了各式遠程過程通訊協議。RPC是跨語言的通訊標準，SUN和微軟都有其實現，好比RMI能夠被看做SUN對RPC的Java版本( 實現)，而微軟的DCOM就是創建在ORPC協議之上。一言以蔽之，RPC是協議，而不管是SUN的RMI仍是微軟的DCOM都是對該協議的不一樣實現，兩者都爲編程人員提供了應用PRC技術的程序接口（API）。

        我的總結：RPC協議的實現框架好比RMI等 應該 是經過Socket接口裏來使用TCP/IP協議來實現網絡通訊的。其餘經常使用應用層協議包括FTP、HTTP、TELNET、SMTP等也是經過Socket這個門面接口來使用TCP/IP協議來實現網絡通訊的。

      Socket是應用層與TCP/IP協議族通訊的中間軟件抽象層，它是一組接口。在設計模式中，Socket其實就是一個門面模式（Facade），它把複雜的TCP/IP協議族隱藏在Socket接口後面，對用戶來講，一組簡單的接口就是所有，讓Socket去組織數據，以符合指定的協議。

      有關Socket的更多內容，詳見：http://blog.csdn.net/zolalad/article/details/45599199

2. J2EE項目-使用JDK自帶的RPC實現——RMI

       RMI是Java的一組擁護開發分佈式應用程序的API。RMI使用Java語言接口定義了遠程對象，它集合了Java序列化和Java遠程方法協議(Java Remote Method Protocol)。簡單地說，這樣使原先的程序在同一操做系統的方法調用，變成了不一樣操做系統之間程序的方法調用，因爲J2EE是分佈式程序平臺，它以RMI機制實現程序組件在不一樣操做系統之間的通訊。好比，一個EJB能夠經過RMI調用Web上另外一臺機器上的EJB遠程方法。
        RMI（Remote Method Invocation，遠程方法調用）是用Java在JDK1.1中實現的，它大大加強了Java開發分佈式應用的能力。Java做爲一種風靡一時的網絡開發語言，其巨大的威力就體如今它強大的開發分佈式網絡應用的能力上，而RMI就是開發百分之百純Java的網絡分佈式應用系統的核心解決方案之一。其實RMI能夠被看做是RPC的Java版本( 實現)。可是傳統RPC並不能很好地應用於分佈式對象系統,而Java RMI 則支持存儲於不一樣地址空間的程序級對象之間彼此進行通訊，實現遠程對象之間的無縫遠程調用。

       RMI目前使用Java遠程消息交換協議JRMP（Java Remote Messaging Protocol）進行通訊。JRMP是專爲Java的遠程對象制定的協議。所以，Java RMI具備Java的「Write Once，Run Anywhere」的優勢，是分佈式應用系統的百分之百純Java解決方案。用Java RMI開發的應用系統能夠部署在任何支持JRE（Java Run Environment Java，運行環境）的平臺上。但因爲JRMP是專爲Java對象制定的，所以，RMI對於用非Java語言開發的應用系統的支持不足。不能與用非Java語言書寫的對象進行通訊。

3. Hadoop中自定義的RPC實現原理
        Hadoop做爲一個存儲與服務的基礎性平臺，同時它的內部有采用了master/slave架構，那麼其內部通訊和與客戶端的交互就是必不可少的了。Hadoop在實現時拋棄了JDK自帶的一個RPC實現——RMI，而本身基於IPC模型實現了一個更高效的輕量級RPC。

SOCKET使用時能夠指定協議TCP,UDP等；

RIM使用JRMP協議，JRMP又是基於TCP/IP；

RPC底層使用SOCKET接口，定義了一套遠程調用方法；

HTTP是創建在TCP上，不是使用SOCKET接口，須要鏈接方主動發數據給服務器，服務器沒法主動發數據個客戶端；

能夠用socket實現HTTP；

其實符合HTTP規範的就是HTTP協議，無論用什麼技術。

轉自：http://blog.csdn.net/a19881029/article/details/9465663

RMI:遠程方法調用(Remote Method Invocation)。可以讓在某個Java虛擬機上的對象像調用本地對象同樣調用另外一個java 虛擬機中的對象上的方法。

RMI遠程調用步驟：

1，客戶對象調用客戶端輔助對象上的方法

2，客戶端輔助對象打包調用信息（變量，方法名），經過網絡發送給服務端輔助對象

3，服務端輔助對象將客戶端輔助對象發送來的信息解包，找出真正被調用的方法以及該方法所在對象

4，調用真正服務對象上的真正方法，並將結果返回給服務端輔助對象

5，服務端輔助對象將結果打包，發送給客戶端輔助對象

6，客戶端輔助對象將返回值解包，返回給客戶對象

7，客戶對象得到返回值

對於客戶對象來講，步驟2-6是徹底透明的

 

Java RMI的缺點：

1，從代碼中也能夠看到，代碼依賴於ip與端口

2，RMI依賴於Java遠程消息交換協議JRMP（java Remote Messaging Protocol），該協議爲java定製，要求服務端與客戶端都爲java編寫

轉自：http://www.cnblogs.com/dongguacai/p/5617698.html

RMI的定義

RPC (Remote Procedure Call):遠程方法調用，用於一個進程調用另外一個進程中的過程，從而提供了過程的分佈能力。

RMI（Remote Method Invocation):遠程方法調用，即在RPC的基礎上有向前邁進了一步，提供分佈式對象間的通信。容許運行在一個java 虛擬機的對象調用運行在另外一個java虛擬機上對象的方法。這兩個虛擬機能夠是運行在相同計算機上的不一樣進程中，也能夠是運行在網絡上的不一樣計算機中。

RMI的全稱宗旨就是儘可能簡化遠程接口對象的調用。

RMI大大加強了java開發分佈式應用的能力，例如能夠將計算方法複雜的程序放在其餘的服務器上，主服務器只須要去調用，而真正的運算是在其餘服務器上進行，最後將運算結果返回給主服務器，這樣就減輕了主服務器的負擔，提升了效率（可是也有其餘的開銷）。

RMI網絡模型

在設計初始階段，咱們真正想要的是這樣一種機制，客戶端程序員以常規方式進行方法調用，而無需操心將數據發送到網絡上或者解析響應之類的問題。因此纔有了以下的網絡模型：在客戶端爲遠程對象安裝一個代理。代理是位於客戶端虛擬機中的一個對象，它對於客戶端程序來講，就像是要訪問的遠程對象同樣。客戶端調用此代理時，只需進行常規的方法調用。而客戶端代理則負責使用網絡協議與服務器進行聯繫。

 

如今的問題在於代理之間是如何進行通訊的？一般有三種方法：

一、CORBA：經過對象請求代理架構，支持任何編程語言編寫的對象之間的方法調用。

二、SOAP

三、RMI：JAVA的遠程方法調用技術，支持java的分佈式對象之間的方法調用。

其中CORBA與SOAP都是徹底獨立於言語的，可使用C、C++、JAVA來編寫，而RMI只適用於JAVA。

轉自：http://blog.csdn.net/liuxuezong/article/details/6256549

RMI與Socket

   通常來講，基於CS（client-server)軟件架構的開發技術有不少種。比較經常使用的有：基於 socket的網絡編程、RPC、基於Java技術的RMI（固然C#也有相似技術）、CORBA等。在這裏咱們只是對基於socket的網絡編程與 RMI做個對比，有助於咱們瞭解它們各自的應用領域，幫助咱們在面對一個具體問題的時候選用適合的技術。另外，本文所作的討論能夠認爲是脫離了語言層面的 東西，只是對技術的自己作一個討論，無關乎你是用C++、C#或Java 在開發。
1、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 體系結構以下圖：

2、基於socket的網絡編程 
        當你使用socket進行網絡應用開發的時候，通常的思路是「消息驅動邏輯」，即這樣的軟件系統通常具備如下特色：
       (1) 客戶端與服務器端依靠消息進行通信。
       (2) 客戶端或者服務器端都須要一個消息派遣器，將消息投遞給具體的massage handler 
       (3) 客戶端或者服務器端利用massage handler進行邏輯事務處理
 見下圖：
 
        使用socket開發的軟件系統，從技術的本質上來說，有如下幾個特色：
        (1) 基於TCP協議的通信
        (2) 應用程序自己須要提供對消息的序列化處理（所謂的序列化指的是將消息輸出到網絡流中)
        (3) 客戶端與服務器端須要事先商議好它們之間的通信協議即它們交互的消息格式
        (4) 因爲是消息驅動邏輯，從本質上決定了這樣的編程模式很難面向對象化
3、RMI Vs Sochet
        RMI技術比較socket的網絡編程主要有如下幾個方面：
        第1、.RMI是面向對象的，然後者不是。
        第2、.RMI是與語言相綁定的。好比當你使用Java RMI技術的時候，客戶端與服務器端都必須使用Java開發。而socket的網絡編程是使用獨立於開發語言的，甚至獨立於平臺。基於socket的網絡 編程，客戶端與服務器端可使用不一樣開發語言和不一樣的平臺。
       第3、從網絡協議棧的觀點來看，RMI與socket的網絡編程處於不一樣層次上。基於socket的網絡編程位於TCP協議之上，而RMI在TCP協議之 上，又定義了本身的應用協議，其傳輸層採用的是Java遠程方法協議(JRMP)。可見，在網絡協議棧上，基於RMI的應用位置更高一些，這也決定了，與 socket的網絡編程相比，RMI會喪失一些靈活性和可控性，可是好處是它帶給了應用開發者更多的簡潔，方便和易用。好比：若是你用的是RMI,你不需 要關心消息是怎麼序列化的，你只須要像本地方法調用同樣，使用RMI。代價是：應用開發者沒法很好地控制消息的序列化機制。
      第4、這是最後一點不一樣，我認爲也是比較重要的一點，就是兩種方法的性能比較，其每每決定着你將使用那種技術來開發你的應用。如下引用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=012345 > 46037 [SYN, ACK] Seq=266515894 Ack=801611568 Win=10136 Len=046037 > 12345 [ACK] Seq=801611568 Ack=266515895 Win=5840 Len=012345 > 46037 [PSH, ACK] Seq=266515895 Ack=801611568 Win=10136 Len=146037 > 12345 [ACK] Seq=801611568 Ack=266515896 Win=5840 Len=012345 > 46037 [FIN, PSH, ACK] Seq=266515896 Ack=801611568 Win=10136 Len=146037 > 12345 [RST, ACK] Seq=801611568 Ack=266515898 Win=5840 Len=0RMI:42749 > rmiregistry [SYN, ECN, CWR]Seq=3740552479 Ack=0 Win=32767 Len=0rmiregistry > 42749 [SYN, ACK, ECN]Seq=3749262223 Ack=3740552480 Win=32767 Len=042749 > rmiregistry [ACK] Seq=3740552480 Ack=3749262224 Win=32767 Len=0JRMI, Version: 2, StreamProtocolrmiregistry > 42749 [ACK] Seq=3749262224 Ack=3740552487 Win=32767 Len=0JRMI, ProtocolAck42749 > rmiregistry [ACK] Seq=3740552487 Ack=3749262240 Win=32767 Len=0Continuationrmiregistry > 42749 [ACK] Seq=3749262240 Ack=3740552506 Win=32767 Len=0JRMI, Callrmiregistry > 42749 [ACK] Seq=3749262240 Ack=3740552556 Win=32767 Len=0JRMI, ReturnData42749 > rmiregistry [ACK] Seq=3740552556 Ack=3749262442 Win=32767 Len=0JRMI, PingJRMI, PingAck42749 > rmiregistry [ACK] Seq=3740552557 Ack=3749262443 Win=32767 Len=0JRMI, DgcAck42749 > rmiregistry [FIN, ACK]Seq=3740552572 Ack=3749262443 Win=32767 Len=0rmiregistry > 42749 [FIN, ACK]Seq=3749262443 Ack=3740552573 Win=32767 Len=042749 > 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。