Comparison and analysis of RMI and Socket

Generally speaking, there are many kinds of development techniques based on CS (client-server) software architecture. More commonly used are: socket based network programming, RPC, Java-based technology RMI (of course, C # also have similar technology), CORBA and so on. In this case, we only compare the network programming with RMI, and help us to understand their respective areas of application, helping us to choose the right technology in the face of a specific problem. In addition, the discussion in this article can be thought of as being out of the language, just a discussion of the technology itself, no matter whether you are developing in C + +, C #, or Java.

First, RMI technology introduction
This article takes Java as an example, briefly introduces RMI technology.
Starting with Java1.1, remote method calls are one of the Java core APIs (in java.rmi.* packages) as Java distributed Object technology. The introduction of RMI makes it possible to implement flexible, extensible distributed communication between Java programs. RMI allows Java objects to exist in a number of different address spaces, distributed across different Java virtual machines. Each address space can be on the same host or on a different computer on the network. Because remote method calls span different virtual machine boundaries to different specified address spaces, there is no object-shared global variable, which requires the object serialization (serialization) API, which enables Java objects to be passed between different JVMs. Object serialization is specifically designed for Java objects, which means that objects in Java programs can be accessed as Object parameters (the serializable object must implement the Serializable interface). Combining the RMI and object serialization mechanisms, you can access objects and data that cross the boundaries of a local Java virtual machine. RMI allows you to invoke remote methods of remote objects, and the Java object serialization mechanism enables objects to be passed to them.
The most basic Java model does not provide the ability to treat Java objects on a remote host as part of the local Java program address space, and RMI has made up for this deficiency. In addition, because the Java and hardware platform-independent features, whether the homogeneous system or heterogeneous system, RMI can run without porting.
RMI provides a simple and straightforward model for distributed computing in the Java platform. Because Java's RMI technology is based on the Java platform, it brings the benefits of Java Platform Security and portability to distributed computing. RMI greatly expands the network computing power of Java, which provides a powerful platform support for the development of enterprise-class internet/intranet applications based on distributed object technology.
The Java RMI architecture is shown in the following illustration:

Second, the network programming based on socket
When you use socket for network application development, the general idea is "message-driven logic", that is, such software systems generally have the following characteristics:
(1) The client and server rely on messages for communication.
(2) The client or server side needs a message dispatch to deliver the message to the specific massage handler
(3) The client or server side uses massage handler for logical transaction processing
See figure below:

The software system developed using socket has the following characteristics from the nature of technology:
(1) Communication based on TCP protocol
(2) The application itself needs to provide serialization processing of the message (the so-called serialization refers to the output of the message to the network stream)
(3) The client and server need to negotiate the communication protocol between them, that is, the message format of their interaction
(4) because it is a message-driven logic, it is inherently difficult to object to this programming pattern.
Iii. RMI Vs. Socket
RMI Technology Compare the network programming of the socket mainly has the following several aspects:
First. RMI is object oriented, and the latter is not.
Second. RMI is bound to language. For example, when you use Java RMI Technology, both the client and server side must use Java development. and socket network programming is to use independent development language, and even independent of the platform. Socket based network programming, client and server can use different development languages and different platforms.
Third, from the network protocol stack point of view, RMI and socket network programming at different levels. Socket based network programming is located on the TCP protocol, and RMI on the TCP protocol, but also defines its own application protocol, its transport layer is the Java Remote Method Protocol (JRMP). Visible, on the network protocol stack, based on RMI application location higher, which also determines that the network programming with the socket, RMI will lose some flexibility and controllability, but the advantage is that it brings the application developers more concise, convenient and easy to use. For example: If you are using RMI, you don't need to care about how messages are serialized, you just need to use RMI like local method calls. The cost is that the application developer cannot control the serialization mechanism of the message well.
Four, this is the last point of difference, I think it is also a more important point, is the performance of the two methods of comparison, it often determines that you will use that technology to develop your application. The following reference to a comparison of TCP and RMI in network-programming with RMI is made by Adrian Reber, which is primarily an experiment in comparing the bandwidth of the two over the network: transmitting 2 byte of valid data on the network, for TCP, A total of 478 byte is added to the transmission, while for RMI, 1645byte is transported extra.

The following are trace results for both:
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

The result of the experiment is that RMI transmits the same valid data compared to the TCP based socket, and RMI needs to consume more network bandwidth (protocol overhead). From here, we can draw a general conclusion: RMI is mainly used for remote methods of "call" (RMI is so true:), the technical connotation of the emphasis is "call", based on this, I can think of: mobile computing, and remote control, RMI is a good choice when your app doesn't need to transfer a lot of data between client and server, it's simple and easy to develop. However, once your application needs to transmit a large amount of data between client and server, extreme, such as FTP applications, RMI is not appropriate and we should use sockets.