Based on the three-dimensional ultrasonic field model radiated by the ultrasonic probe, a visualization window program was developed using MATLAB to display the three-dimensional simulation results, and the man-machine interactively changed the parameters affecting the sound field. It is conducive to visually and intuitively understanding the sound field, and provides reference for the analysis and study of the radiated sound field of the ultrasonic probe in scientific research and engineering practice, the selection of various parameters of the probe, the transmission and reception of detection signals, and the ultrasonic detection and evaluation of various materials.
File: n459.com/file/25127180-479487569
The following are irrelevant:
-------------------------------------------Dividing line----- ----------------------------------------
The method call in the stand-alone application is very simple, just call it directly, like this
Because the caller and the callee are in the same process
With the development of business, single-machine applications will become more and more inadequate. Distributed applications will inevitably be introduced to solve the single-machine problem. So how can the caller call a method on another machine?
This involves distributed communication methods, from single machine to distributed, a lot of communication methods have been produced
And RPC is one of the ways to implement remote method calls; saying that RPC is not a protocol, many friends may be unbelievable, thinking I'm lying to you
Looking at your tendons, how dare I lie to you; as long as you finish reading the following, if you lie to you, you have the final say
The evolution process of RPC
Let me explain first, although the examples below are implemented in Java code, the principles are general, and the focus is to understand the principles.
In the first version
of the interaction between the two machines, it must be inseparable from the network communication protocol, and TCP/IP has become an inevitable point. So the method that the ancestors first thought of was to realize the remote method through TCP/IP transfer
The operating system does not directly expose the TCP/IP interface, but abstracts the TCP/IP interface through Socket, so we can implement the original remote method call through Socket
Complete sample code: rpc-01, the core code is as follows
Server：
View Code
Client：
The View Code
code is very simple, it is a simple Socket communication; if you don’t understand it, you need to supplement the knowledge of Socket and IO
The test results are as follows
It can be seen that communication between Client and Server is possible; however, this method is very troublesome and has too many shortcomings. The most obvious one is
Client side business code and network transmission code are mixed together, there is no clear module division
If there are multiple developers doing Client development at the same time, they all need to know about Socket, IO
The second edition
addresses the shortcomings of the first edition, and evolved this edition, introducing Stub (early name, don’t need to go into it, understand it as an agent) to realize the encapsulation of client-side network transmission code
Complete sample code: rpc-02, the changes are as follows
Stub：
View Code
Client：
View Code
Client no longer pays attention to network data transmission, just concentrate on business code
A small partner may be on the bar: Isn't this just moving the network transmission code a bit, this is also an improvement?
Iterative development is a process of gradual improvement, and this is also an improvement
But this version still has many shortcomings, the most obvious one is
Stub can only proxy one method getUserById of IUserService, which is too limited and not universal enough
If you want to add a new method to IUserService: getUserByName, then you need to add a corresponding method in the Stub, and the Server side needs to be modified to support
The third edition
The Stub proxy function in the second edition is too weak. Is there any way to enhance the Stub proxy function?
The previous Stub is equivalent to a static proxy, so the function is limited, what is the enhanced version of the static proxy, yes, it is: dynamic proxy
Small partners who are not familiar with dynamic agents must first understand dynamic agents: the agent of the design pattern, the manual realization of the dynamic agent, the realization of the secret principle
JDK has a dynamic proxy API, we will use it to achieve
Complete sample code: rpc-03, compared with the second edition, the changes are relatively large, you need to look carefully
Server：
View Code
Stub：
View Code
Client：
View Code
let's take a look at the effect
At this point, the methods of the IUserService interface can be proxied, even if it adds an interface, the stub can be proxied without any modification
In addition, the response value on the Server side is changed to an object instead of a single attribute being returned one by one. Then no matter whether the User adds or deletes attributes, Client and Server will not be affected.
The improvement of this version is a very big improvement; but there are still obvious shortcomings
Only supports IUserService, versatility is still not perfect
What if a new IPersonService is introduced?
Fourth edition The
third edition is equivalent to the agreement between Client and Server, and only interacts with User service, so services other than User cannot communicate on both sides
If you need to interact with other services, then the Client needs to pass the requested service name as a parameter to the Server, telling the Server which service I need to interact with
Therefore, both Client and Server need to be modified
Complete sample code: rpc-04, compared with the third edition, the changes are relatively small, I believe everyone can understand
Server：
View Code
Stub：
View Code
Client：
This version of View Code is more abstract, shielding the underlying details, and supports any method of any service. It is a relatively perfect version.
So far, a basic RPC has been implemented
However, there are still a lot of details that can be improved, serialization and deserialization is one of them
Data transmission in the network is binary, so request parameters need to be serialized into binary, and response parameters need to be deserialized into objects
The serialization and deserialization that JDK comes with have disadvantages such as language limitations, slow efficiency, and too long serialization length.
There are many serialization and deserialization protocols, the common ones are
Which of these protocols is good or bad, this article will not elaborate too much, but I just want to tell you: serialization and deserialization protocols are an important part of RPC
Summary
1. The evolution of RPC
2. The components of RPC
Three elements: dynamic proxy, serialization and deserialization protocol, network communication protocol
The network communication protocol can be TCP, UDP, HTTP 1.x, HTTP 2, and even capable of being a custom protocol
3. RPC framework
RPC is not equivalent to the RPC framework. RPC is a concept and a distributed communication method
Many RPC frameworks have been generated based on RPC: Dubbo, Netty, gRPC, BRPC, Thrift, JSON-RPC, etc.
The RPC framework enriches RPC functions, including: service registration, service discovery, service governance, service monitoring, service load balancing and other functions