Communication Principles between RPC, RMI, and mom and Multicast

Turn: http://blog.csdn.net/you12345678901234567/article/details/7625797

Remote Procedure Call (RPC ):

That is, the process of the remote site machine is called. When a process on site machine a calls the process on another site machine, the call process on Site A is suspended, the call process on Site B is executed, and the result is returned to the call process, make the invocation process continue to execute [the parameters and execution results of the called process on B are implemented between the called process and the called process through message transmission, showing the relationship between C/S]

To implement RPC on different sites, all call and called processes need to keep a running stack for storing process parameters and execution results, called the client and server stubs respectively, it provides support for running in different address spaces.

Implementation steps [transparent externally ]:

1. Call the client stub and fill in the parameter.

2. The client uses the client operating system to package parameter messages.

3. The client operating system sends a message to the remote server operating system, and the client process waits for the returned result.

4. The server operating system receives parameter messages and sends them to the server stub.

5. The server stub unpacks the parameter message and starts the server process.

6. After the server process is executed, enter the result to the server stub.

7. The server stub package the result message and call the server operating system.

8. The server operating system sends a result message to the client operating system.

9. The client operating system receives the result message and sends it to the client process.

10. The result message is returned to the customer process.

Process method call (RMI ):

It can be viewed as the Java version of RPC. However, traditional RPC cannot be well applied to distributed object systems. Java RMI supports communication between Program-level objects stored in different address spaces to achieve seamless remote calls between remote objects. To access a remote object, you must first bind the object. The object reference contains sufficient information to bind the object, the binding result is to generate an object proxy in the process address. The interface of the object proxy is exactly the same as that of the object itself. [In most cases, this binding is automatically completed by the system and transparent to users]

Working principle: the method call is passed down from the client object through the placeholder Program (stub), remote reference layer (Remote Reference layer), and transport layer (Transport Layer) to the host, then, the data transmission layer goes up through the Remote Call layer and the backbone network (skeleton) to reach the server object. The placeholder program acts as the proxy of the remote server object so that the object can be activated by the customer. The remote reference layer processes semantics, manages communication between single or multiple objects, and determines whether a call should be sent to one server or multiple objects. The Transport Layer manages the actual connections and traces remote objects that can receive method calls. The server-side Backbone Network calls the actual method of the server object and obtains the return value. The returned values are transmitted back to the client through the remote reference layer and the transmission layer on the server side, and then back to the transmission layer and remote call layer. Finally, the placeholder program obtains the returned value. [Before a customer process accesses a distributed object, it must first generate a proxy for the object in the local address space of the process. The object proxy can be used as a local object of the customer process, the function is similar to the client stub in rpc. You can package the client's access requests and parameters into messages and send them to the server. The server then unpacks the messages and calls the corresponding method]Serialization and deserialization

Steps:

1. Generate a remote interface

2. implement remote objects (server programs)

3. Generate placeholder program and backbone network (server program)

4. Write server programs

5. Write customer programs

6. Register a remote object

7. Start a remote object

Disadvantage: Both RPC and RMI require that the processes of the caller and the called side be in the running state. If the called process or the site of the object is in the stopped or faulty state, RMI or RPC call fails.

Message-oriented communication:

To overcome the preceding shortcomings of RMI and RPCPersistent Communication ModeWhen the sender sends a message, the receiver process is not required to be running; when the receiver process receives the message, the sender process is not required to be working. Application A needs to send a message to another application B located on different sites. First, call the Message Queue interface to send the message to the connected Communication Server and put it into Message Queue, then, the queue manager sends the cited message to the communication server connected to the receiver's site machine through the underlying network and puts it into Message Queue B. At the receiver, application B calls the Message Queue interface to retrieve messages from the local queue B.

Message-oriented middleware: Mom refers to the use of an efficient and reliable message transmission mechanism [Message Queue] For platform-independent data exchange. It is a persistent asynchronous communication system, it also integrates distributed systems based on data communication. By providing message transmission and Message Queuing Models, it can expand inter-process communication in a distributed environment and support multi-communication protocols, languages, applications, hardware, and software platforms. Currently, popular mom middleware Products include IBM MQSeries, Bea messageq, and Apache activemq.

Message-oriented middleware generally has two transmission models: point-to-point (PTP) and publish-subscribe (pub/Sub ).
1. Point-to-Point model (P2P)
The point-to-point model is used for point-to-point communication between message producers and consumers. The message producer initiates a message to a specific consumer identified by a name. This name actually corresponds to a queue in the message service. It is stored in this queue before the message is sent to the consumer. The queue can be persistent to ensure that messages are still transmitted when the message service fails.
2. Publish-subscribe model (pub/Sub) [multicast-based communication mode]
The publishing-subscription model uses a content hierarchy called a topic to replace the unique destination in the PTP model and send applications to publish their own messages, it indicates that the message describes a topic in the layered structure. Applications that want to receive these messages subscribe to this topic. Subscribe to a topic in the subtopic hierarchy. subscriber can receive all messages of the topic and its subtopic.

Multicast Communication:
[Broadcast] A process sends messages to all processes in the system [multicast] A process sends messages to each member of a process group at the same time.

Multicast Communication advantages: the sender only needs to send a message multicast once, rather than requiring the sender to send messages repeatedly. Processes in a process group can be fixed or dynamically organized. A process group can dynamically join a new process or delete a process group member.

Application scenarios of Multicast: multicast is a requirement for collaborative work of distributed system processes.

1. for fault tolerance purposes, a group of distributed system servers provide the same service. When a customer requests a service, the system broadcasts the service request to each member of these server groups, and perform the same service operation. [Even if one or more servers in the server group are invalid, the customer's request can still produce satisfactory results]

2. Based on the security of data storage, data backup is the most frequently used method, that is, the same group of data is stored on several different servers at the same time. To ensure data consistency in data backup, when the data stored on one server changes, it is necessary to group the changed information to other servers to timely update the data.

3. In a distributed system that provides the event mechanism, when an event occurs, it is necessary to broadcast the event notification to all the processes related to the event, to stimulate and execute corresponding actions.

IP multicast is the simplest way to implement multicast. It can only be obtained through UDP. Like IP-based P2P data communication, it cannot ensure that all multicast messages can reach each process in the Group accurately.

The publishing/subscription system (pub/Sub) is event-based collaboration. Before using the event, the user must register the process as the event provider or user. The process uses these two roles to participate in event communication. The provider and the user transmit the event through the Event Server. The event provider sends the event to the Event Server. before using the event, the event user must register its subscription conditions on the event server to indicate that he is interested in some events in the system, the Event Server ensures that the published events are broadcast to all event users who are interested in the event in a timely manner. In the publishing/subscription system, the provider of an event is called publisher, the user of an event is called subscriber, and the publisher and subscriber are collectively referred to as customers, the Event Server is called event broker EB and is responsible for connecting and sending events among customers. All customers can connect to the Event Agent as event publishers or event subscribers.

The publishing/subscription system (pub/Sub) supports two cooperative working modes: push and pull. In push mode, event publishers generate events, actively push events to event proxies, and then event proxies push events to event subscribers.

In PULL mode, the event subscriber actively requests the publisher to generate an event. The event proxy waits for the subscriber's event request to arrive, and then requests the event publisher to generate an event and publish it to the event proxy.

[Difference between the two modes: The Event subscribers in the push mode passively wait for the event to arrive, while the subscribers in the PULL mode actively request the event .]

See [network distributed computing and software engineering second edition, such as Feng Yulin]

Communication Principles between RPC, RMI, and mom and Multicast