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。