FFRPC
Github address https://github.com/fanchy/FFRPC
FFRPC has been developed for one year. On October 10, June 6, I finally completed a satisfactory version, which is called V0.2. FFRPC implements a C ++ version of asynchronous inter-process communication library. I am a game server program. In the server program field, the system is distributed and each node needs to communicate asynchronously, my original intention was to develop an easy-to-use and easy-to-test inter-process socket communication component. In fact, FFRPC is already a framework.
MAIN FEATURES OF FFRPC
- FFRPC adopts the Epoll Edge Trigger mode. Here we mention that ET is used in asynchronous mode. The ET mode is the simplest and most efficient way for epoll to write many posts on the Internet, the essence of ET is not understood. If you want to explore the mysteries of ET from ffrpc, remind readers that Epoll should be regarded as a state machine! FFRPC adopts the Broker mode. Scalability !! Developers in the game field must be familiar with the concept of Master/Gateway/Logic Server. In fact, the Master actually plays the role of Broker master, while the gateway plays the role of Broker slave, broker Slave is responsible for forwarding client requests to Logic Service. Although providing a forwarding layer increases latency, the system becomes scalable, greatly improving throughput. This is Scalability !! The Broker master is responsible for managing all the Master server Load balancer instances. Different clients allocate different Broker SLave instances.
- FFRPC is based on the above ideas and has the following four key concepts:
- 1. The broker master is responsible for load balancing and synchronizing information of all nodes. All slave brokers and rpc service/rpc cleint must be connected to the broker master.
- Ii. slave broker is responsible for forwarding messages between the service and client. If the service, client, and broker are in the same process, messages are directly delivered between the memory. This is v0. 2 important optimization, v0. 1. There was no such function. Many netizens responded to this problem. It seems that everyone is too sensitive to optimization! Another innovation is ffmsg_t, which encapsulates message serialization and deserialization. I'm tired of protobuff, if you have also studied defining cmd for each message and writing a switch for cmd (some people may have used the register callback function, but it is more useful ). In fact, when a message struct is defined, a message itself is unique. So why should we define a cmd for the message? For example, if the message struct echo_t {int a;} is defined, the echo_t name itself is unique. Otherwise, the compiler will report an error. Why not use the echo_t name as cmd directly? In FFRPC, you can use TYPE_NAME (echo_t) to obtain the message body name string. Dropping TYPE_NAME is an interesting implementation. No keyword in c ++ can be used to obtain the name of a class, however, all compilers actually provide this function! For details, see the source code. Some readers may struggle to use the name of the message body structure to execute cmd, Which is easy but a waste of traffic! The 32-bit cmd always saves traffic than the string. Yes, although I do not like this conclusion (I am always lazy to optimize it, unless it is... forced), it is right! Ffrpc solves this problem. When each node is initialized, it must be registered to the broker master. At this time, all messages will be allocated a unique msg id in the master, in this way, we can use integer 1 to represent the echo_t structure. Since every node knows the ing from echo_t to 1, the programmer no longer needs to manually define cmd. The broker is dynamically defined during unique initialization.
- 3. ffrpc service: the module that provides the interface, that is, the server. The interface registered through the ffrpc class is based on the asynchronous mode. The recommended mode is that each message returns a result message.
- 4. The ffrpc client is the module of the ffrpc service called. Based on the asynchronous mode, remember to determine an interface with the unique service name and message name, this c ++ class has the same concept as the class interface. You can specify a callback function when calling a remote interface. In addition, the callback function supports lambda parameter binding!
- To quickly witness the charm of the ffrpc library, let's look at the following example. If you have a linux system, you can test this example within one minute. ffrpc has no other dependencies, the log component of FFRPC is colored!
Sample Code
#include <stdio.h> in_t: ffmsg_t<in_t><<>> out_t: ffmsg_t<out_t><<>> echo(ffreq_t<echo_t::in_t, echo_t::out_t>&.data =, echo_callback(ffreq_t<echo_t::out_t>& req_, , main( argc, * LOG.start( ffrpc_t ffrpc_service(&foo_t::echo, &.data = printf(, .get_type_name()); ( i = ; i < ; ++ ffrpc_client.call(, , ffrpc_ops_t::gen_callback(&foo_t::echo_callback, &
Summary
- In ffrpc, brokers, clients, and services can be started in different processes. If they are in the same process, messages are delivered directly between memories.
- Each ffrpc instance starts a separate thread and task queue to ensure that service and client operations are orderly and thread-safe.
- If you have studied libraries/frameworks such as protobuff, thrift, zeromq, and ice, try ffrpc.
- Github address https://github.com/fanchy/FFRPC
