Ffrpc-C ++ inter-process (server, client) Communication Framework

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.ProgramIn the field of server programs, the system is distributed and each node needs to communicate asynchronously. My original intention is 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!

Example Code

# Include <stdio. h> # Include  "  Base/daemon_tool.h  "  # Include  "  Base/arg_helper.h  "  # Include  "  Base/strtool. h  "  # Include "  Base/smart_ptr.h  "  # Include  "  RPC/ffrpc. h  "  # Include  "  RPC/ffbroker. h  "  # Include  "  Base/log. h  "  Using   Namespace Ff;  //  ! Defines the message of the ECHO interface. in_t indicates the input message, and out_t indicates the result message.  //  ! It is a reminder that there is no definition of Shenma cmd for echo_t, and its name is not specified. ffmsg_t will automatically get the name of echo_t  Struct  Echo_t {  Struct In_t: Public Ffmsg_t <in_t> {  Void  Encode () {encoder () < Data ;} Void  Decode () {Decoder () > Data ;}  String  Data ;};  Struct Out_t: Public Ffmsg_t <out_t> {  Void  Encode () {encoder () < Data ;}  Void  Decode () {Decoder () > Data ;}  String  Data ;};};  Struct  Foo_t {  //  ! The echo interface returns the sent message ffreq_t of the request. Two template parameters are provided. The first one indicates the input message (sent by the requester)  //  ! The second template parameter indicates the type of the result message to be returned by this interface.      Void Echo (ffreq_t <echo_t: in_t, echo_t: out_t> & REQ _) {echo_t: out_t  Out  ; Out . Data = REQ _. Arg. Data; logdebug ((  "  Xx  " , "  Foo_t: ECHO: % s  "  , Req _. Arg. Data. c_str (); req _. Response (  Out  );}  //  ! Remote Call interface, you can specify the callback function (or leave it blank), use ffreq_t to specify the input message type, and use Lambda to bind Parameters      Void Echo_callback (ffreq_t <echo_t: out_t> & req _, Int  Index) {logdebug ((  "  Xx  " , "  % S % d  "  , _ FUNCTION __, req _. Arg. Data. c_str (), index ));}};  Int Main ( Int Argc, Char * Argv []) {  // ! Beautiful log component, shell output is a color drop !! Log. Start ( "  -Log_path./log-log_filename log-log_class XX, broker, ffrpc-log_print_screen true-log_print_file true-log_level 6  "  );  //  ! Start the broker and perform network-related operations, such as message forwarding, node registration, and reconnection.  Ffbroker_t ffbroker; ffbroker. Open (  "  App-l TCP: // 127.0.0.1: 10241  "  );  // ! The broker client can register with the broker, register services and interfaces, or remotely call interfaces of other nodes. Ffrpc_t ffrpc_service ( "  Echo  "  ); Foo_t Foo; ffrpc_service.reg ( & Foo_t: ECHO ,& Foo); ffrpc_service.open (  "  App-broker TCP: // 127.0.0.1: 10241  "  ); Ffrpc_t ffrpc_client; ffrpc_client.open (  "  App-broker TCP: // 127.0.0.1: 10241  " ); Echo_t: in_t  In  ;  In . Data = "  Helloworld  "  ;  //  ! You have not seen the get_type_name definition, but he is sure to exist. Printf ( "  Test to obtain Class Name: % s \ n  " , In . Get_type_name ()); // The output is: Test to obtain the Class Name: echo_t: in_t      For ( Int I = 0 ; I < 100 ; ++ I ){  //  ! As you may think, the echo interface is called, and then the echo_callback is called. This process is repeated every second. Ffrpc_client.call ( "  Echo  " , In , Ffrpc_ops_t: gen_callback (& foo_t: echo_callback ,& Foo, I); sleep ( 1  );} Sleep (  300  ); Ffbroker. Close ();  Return   0  ;} 

 

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