RMI Vs 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被额外传输。

 

实验的结果是：RMI与TCP based socket相比，传输相同的有效数据，RMI需要占用更多的网络带宽（protocol overhead）。从这里，我们可以得出一个一般性的结论：RMI主要是用于远程方法的”调用“（RMI是多么的名符其实:)），其技术内涵强调的是“调用”，基于此，我能想到的是：移动计算，和远程控制，当你的应用不需要在client与server之间传输大量的数据时，RMI是较好的选择，它简洁、易于开发。但是，一旦你的应用需要在client与server之间传输大量的数据，极端的，比如FTP应用，则RMI是不适合的，我们应该使用socket。