Code Analysis of EQ: Server/EQ: node in Equalizer

In equalizer, server, as an independent process, manages and schedules the entire parallel rendering system. Its main tasks include loading configuration scripts, listening, and establishing connections with nodes, responds to messages from other nodes. Since EQ: Server is a subclass of EQ: node, it is similar to the latter in many aspects. 1. Load the configuration scriptIn the initialization phase of EQ: Server, EQ: SERVER: loader and its multiple overload functions can be obtained from the strings or script files in the command line (*. CFG) load the application configuration and create the EQ: Server and EQ: config objects accordingly. Both the configuration methods are loaded as strings and parsed by functions in server/parser. cpp. This process is automatically generated using bison-flex. In fact, EQ: config is the configuration parameter to be sent to other application nodes after receiving the connection request. 2. Network CommunicationEQ: Server inherits from EQ: Net: node. The parent class is used for initialization. The key is to start the listening function. The default listener uses the TCP/IP protocol to listen on the specified port. You can also enter the network protocol and listening port specified by the -- eq-listener parameter in the command line parameter, available protocols include TCP/IP, SDP, and pipe. During the initialization of EQ: Net: node, you can enter "-- eq-client" in the command line parameters and specify the client command to be run in the subsequent parameters, create a Node object as a client, that is, the so-called "alone" running mode.

The member object _ connect is used to send and receive data in eq: Net: node. This object is an object pointer of EQ: Net: connection. It is instantiated as a socketconnectionwin32 object under Win32. It uses the overlapped model of WinSock to send and receive data. The essence is to implement asynchronous data transmission in a multi-threaded blocking mode. At the same time, the connection class also provides a direct interface for data caching and transmission of packet struct, thus simplifying its application in eq: Net: node.

In EQ: Net: connection, send/Recv is an advanced interface called by an application object, such as EQ: Net: node, and read/write is the underlying interface, it is used to directly process socket operations for data transmission. The high-level interface performs network operations through the underlying interface, and its interface has nothing to do with the underlying operation. Therefore, it is directly implemented by the EQ: Net: Connection class. The underlying read/write interfaces are related to the running platform. For example, if Winsock is used in windows, the shared cache mode is used in some environments. Therefore, different sub-classes implement the function, for example.

 

 

3. Message response

EQ: Net: The Node starts two threads after the listener is initialized, which are used to receive the listening data and to process the commands in the data. All the data is processed in the form of messages. _ Receiverthread is used to put received messages into the node message queue, while _ commandthread obtains messages from the message queue in sequence and performs operations based on the messages. EQ: After the server completes initialization, it enters the message processing cycle and continuously obtains and processes new messages from the message queue.

EQ: Net: node uses EQ: Net: connectionset to Implement Asynchronous Network Communication, and responds to received messages in a simple manner. Note that the messages received asynchronously are not valid application messages. In addition to necessary exception messages, event_data is the most important message. This message also includes the connector that receives the message and the corresponding data size. In the _ receivethread thread, the EQ: Net: connectionset is first queried. When an event_data message is displayed, the data synchronized Based on the message parameters receives truly valid message data. (In this way, a simple asynchronous message is used to avoid the continuous active query port in the receiving thread. Then, the port is read only when valid data arrives, and the efficiency is relatively high.)