WO2012159305A1 - 一种分布式多进程通信方法和装置 - Google Patents

一种分布式多进程通信方法和装置 Download PDF

Info

Publication number
WO2012159305A1
WO2012159305A1 PCT/CN2011/076529 CN2011076529W WO2012159305A1 WO 2012159305 A1 WO2012159305 A1 WO 2012159305A1 CN 2011076529 W CN2011076529 W CN 2011076529W WO 2012159305 A1 WO2012159305 A1 WO 2012159305A1
Authority
WO
WIPO (PCT)
Prior art keywords
packet
message
kernel
target
source
Prior art date
Application number
PCT/CN2011/076529
Other languages
English (en)
French (fr)
Inventor
王志刚
Original Assignee
华为技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 华为技术有限公司 filed Critical 华为技术有限公司
Priority to PCT/CN2011/076529 priority Critical patent/WO2012159305A1/zh
Priority to CN201180001507.3A priority patent/CN102971723B/zh
Publication of WO2012159305A1 publication Critical patent/WO2012159305A1/zh

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/60—Router architectures

Definitions

  • the present invention relates to the field of processor systems, and in particular, to a distributed multi-process communication method and apparatus. Background technique
  • Multicore chips refer to the integration of two or more complete computing engines (cores) in a single chip.
  • cores complete computing engines
  • the biggest feature of multi-core operating systems is the sharing of memory, input and output (10) peripheral resources for multiple cores.
  • the Linux operating system based on the Symmetrical Multi-Processing (SMP) kernel is a widely used multi-core operating system.
  • the Linux operating system based on the SMP kernel is also more and more widely used in communication systems.
  • the affinity of the Linux operating system is usually used to bind the process to a specific hardware core.
  • the user access space of the Linux process is independent, the two processes cannot access each other's user space, and there is a problem that processes communicate with each other.
  • the Linux system between a user process and other processes the user Linux system board of a board, a Linux system users and other processes other operating Veneer
  • inter-process communication between systems such as real-time operating system vxworks, etc.
  • inter-process communication mechanism is simple to use, and it is not suitable for multi-parameter communication between multiple processes. It is only applicable to communication between different processes in a Linux SMP system, and cannot be implemented on different operating systems of different boards. Interprocess communication.
  • the user process maps the entire physical memory of the packet to the user process space, and uses the shared queue between the network card driver and the user process to implement zero-copy of the packet interaction, and captures all the packets received by the network card to the user process.
  • a forwarding process is run on the user mode to identify packets sent to different user processes, and then communicate with each user process through a shared queue located in the user state. When the user wants to send a message, it will first report The text is sent to the forwarding process, and is sent by the forwarding process to the network card driver and finally the outgoing network card hardware.
  • This technology uses the NIC to drive the underlying packet capture method, and all the packets are received into the forwarding process.
  • the packets transmitted by the Transmission Control Protocol (TCP) need to be processed by the Linux kernel protocol stack. This needs to be forwarded by the forwarding process and then sent to the Linux protocol stack. After the Linux protocol stack is processed, it is then handed over to the user state process by the kernel protocol stack.
  • This approach is difficult and inefficient. Since there is no SOCKET programming interface, it brings a lot of portability problems to the application.
  • the kernel mode NIC driver receives the packets from the NIC through the interrupt mode. Frequent interrupts and soft interrupts seriously affect the performance of the Linux kernel.
  • the processing of the interrupt needs to be bound to one core, which wastes a limited central processing unit (CPU) resource, making it difficult to upgrade and update the network card driver in the kernel state. Summary of the invention
  • a technical problem to be solved by embodiments of the present invention is to provide a distributed multi-process communication method and apparatus. Efficient communication between various processes is possible.
  • an embodiment of the present invention provides a distributed multi-process communication method, including:
  • the programmable hardware component receives the packet from the source process, where the packet includes a source process address and a target process address;
  • the programmable hardware component writes the packet to a target shared queue corresponding to the target process according to the source process address, the target process address, and the locally stored route distribution information in the text, so that the target process is according to the target process.
  • the target shared queue obtains the message.
  • the embodiment of the invention further provides a distributed multi-process communication method, including:
  • the programmable hardware component obtains a packet from the source shared queue, where the packet is a source process that writes a packet of a source shared queue corresponding to the source process, and the template includes a source process address and a target process address.
  • the programmable hardware component forwards the packet according to the source process address, the target process address, and the locally stored route distribution information in the packet.
  • an embodiment of the present invention further provides an apparatus for distributed multi-process communication, including a programmable hardware component, where the programmable hardware component includes:
  • a receiving module configured to receive a packet from a source process, where the packet includes a source process address and a target process address; a writing module, configured to write the packet to a target shared queue corresponding to the target process according to the source process address, the target process address, and the locally stored route distribution information in the packet, so that the target process is according to the The target shared queue obtains the message.
  • an embodiment of the present invention further includes an apparatus for distributed multi-process communication, including a programmable hardware component, the programmable hardware component comprising:
  • An obtaining module configured to obtain a packet from the source shared queue, where the source file is a source shared queue corresponding to the source process, and the source includes a source process address and a target process address.
  • a forwarding module configured to forward the packet according to the source process address, the target process address, and the locally stored route distribution information in the packet.
  • the embodiment of the invention further provides a communication device, which can perform distributed multi-process communication, and the device includes:
  • a programmable hardware component configured to receive a packet from the source process, and write the ⁇ 3 ⁇ 4 text to a target corresponding to the target process according to the source process address, the target process address, and the locally stored route distribution information in the packet a shared queue, where the ⁇ includes a source process address and a target process address;
  • At least one process component configured to acquire the packet according to the target shared queue.
  • the embodiment of the invention further provides a communication device, which can perform distributed multi-process communication, and the device includes:
  • At least one process component configured to write a message to a source shared queue corresponding to the process component, where the packet includes a source process address and a target process address;
  • the programmable hardware component is configured to obtain the packet from the source shared queue, and forward the packet according to the source process address, the target process address, and the locally stored route distribution information in the packet.
  • a programmable hardware component is newly set up, which forwards the inter-process message according to the local route distribution information, and can flexibly configure the route distribution information to implement receiving and shielding the specific process message.
  • the garbage message uses the target shared queue to exchange messages, which realizes zero copy of the memory, reduces system calls, and reduces the CPU occupancy.
  • FIG. 1 is a schematic diagram of a specific process of a distributed multi-process communication method according to an embodiment of the present invention
  • FIG. 2 is a schematic diagram of a specific format of three types of packets in the embodiment of the present invention
  • FIG. 3 is a schematic diagram of another specific process of the distributed multi-process communication method in the embodiment of the present invention.
  • FIG. 4 is a schematic diagram of contents of route forwarding information stored in a programmable hardware component;
  • FIG. 5 is a schematic diagram of a specific processing flow of a packet sending direction according to an embodiment of the present invention
  • FIG. 6 is a schematic diagram of a specific processing flow of a kernel side in a receiving direction according to an embodiment of the present invention
  • FIG. 8 is a schematic diagram of the active/standby process switching in the embodiment of the present invention.
  • FIG. 9 is a schematic diagram of a specific composition of a distributed multi-process communication device in an embodiment of the present invention.
  • FIG. 10 is a schematic diagram of a specific configuration of a programmable hardware component in an embodiment of the present invention;
  • FIG. 11 is a distribution in an embodiment of the present invention;
  • FIG. 12 is a block diagram showing another specific composition of the distributed multi-process communication apparatus in the embodiment of the present invention. detailed description
  • the message can be distributed and processed, and the operating system can be implemented without increasing the extremely low hardware cost. Interprocess communication.
  • the user state driver can be used to receive the User Data Protocol (UIP) message from the FPGA, and the kernel state virtual network card driver receives the TCP message from the FPGA to implement the user message.
  • UIP User Data Protocol
  • the kernel state virtual network card driver receives the TCP message from the FPGA to implement the user message.
  • the embodiment of the present invention can be applied to the Linux operating system, but is not limited to the Linux operating system, and can also be applied to an operating system such as windows/vxworks or a bare core application without an operating system.
  • FIG. 1 it is a specific flow diagram of a distributed multi-process communication method according to an embodiment of the present invention.
  • a programmable hardware component performs 4 ⁇ text reception and then distributes 4 ⁇ text to
  • the method includes the following steps.
  • the programmable hardware component receives a packet from a source process, where the packet includes a source process address and a target process address.
  • the programmable hardware component can be a programmable logic circuit, such as FPGA logic running outside of the operating system, as long as the logic circuit can implement the required programming functions.
  • the programmable hardware component receives Ethernet packets from other boards through a communication interface, such as an X Ethernet Attachment Unit Interface (XAUI) interface, an SPi4 interface, a serdes interface, or an Rgmii interface, or A packet sent by a process in the board to other processes in the board is obtained through the shared queue.
  • XAUI X Ethernet Attachment Unit Interface
  • SPi4 SPi4 interface
  • serdes serdes
  • Rgmii interface an Rgmii interface
  • a packet sent by a process in the board to other processes in the board is obtained through the shared queue.
  • the source process described herein can be a process running on the same board as the programmable hardware component, or a process running on another board.
  • the above-mentioned distributed multi-process interaction packets are generally of the following types: TCP packets that implement reliable communication with the server board, and inter-process communication that implements peer-to-peer communication between processes (Inter-Process Communication, ⁇
  • the UIP packet, the ARP packet, the ICMP packet, and the ping packet are used to implement the service data transmission between the processes.
  • the ARP protocol and the ICMP protocol are commonly used TCP/IP underlying protocols. The most commonly used protocol for diagnosis.
  • ARP is responsible for parsing an IP address into a corresponding Media Access Control (MAC) address.
  • ICMP packets provide error diagnosis, congestion control, path control and query for the network layer. Serving four major functions
  • the Ping command verifies the connection to a remote computer or local computer by sending an ICMP echo message to the computer and listening for the return of the response message.
  • the physical transmission of the packet is encapsulated by the Ethernet data frame, and the packet starts with the MAC address of the target process and the source process.
  • FIG. 2 it is a specific format diagram of the three types of packets in the embodiment of the present invention.
  • the source process address, target process address, packet type, and corresponding communication packets are included in the text.
  • the process global unique address is the identification number that uniquely identifies the process in the entire system. In this example, only 2 bytes are used, and the content of the process address is associated with the MAC address. Thus, the upper 2 bytes of the process address are fixed, and the same high 4 bytes of the MAC address are fixed.
  • the reliable communication packet with the server board is carried on the TCP, the configuration data for the download process, the topology relationship between the process nodes, and the multicast group that the process needs to join to receive the multicast message.
  • the message consists of a MAC header, an IP header, a TCP header, and a static payload. This type of packet data is less.
  • the packet consists of a MAC header and a static payload. This type of packet has a large number of packets.
  • the service data UIP packet is carried on the IP packet and uses a customized IP protocol number.
  • the communication message includes a unicast service data message between two processes and a multicast service data message between a pair of processes.
  • the packet consists of a MAC header, an IP header, and a static payload. This type of packet has the largest number of packets.
  • the programmable hardware component writes the packet to a target shared queue corresponding to the target process according to the source process address, the target process address, and the locally stored route distribution information in the packet, so that the target process is according to the
  • the target shared queue obtains the message.
  • a target process has its own target shared queue, which can get 4 messages from the queue. Of course, other messages that are not configured with route forwarding information will be discarded by the programmable hardware component.
  • the message can be separately processed by the user mode and the kernel mode according to the specific type. Of course, it can be processed by the kernel mode without distinction.
  • the packets are divided into two types: user state type and kernel state type, and the target shared queue is divided into user-driven shared queues (or user-process shared queues) and kernel-mode drivers.
  • Shared queues or kernel shared queues.
  • the step may specifically include: the programmable hardware component identifying the packet type; the programmable hardware component distributing information according to a source process address, a target process address, and a locally stored route in the packet.
  • the user mode type message is written to the user process shared queue corresponding to the target process
  • the kernel state type message is written to the kernel shared queue corresponding to the kernel mode driver component.
  • the user mode type message may include an interprocess communication message and/or a user data message, and a kernel mode type report.
  • the file includes one or more of a TCP (Transmission Control) packet, an ARP packet, and an ICMP packet.
  • TCP Transmission Control
  • the program may include: the programmable hardware component according to the source process address and the target process in the packet.
  • the address and the locally stored route distribution information write the message to a kernel shared queue corresponding to the kernel mode driver component; the kernel mode driver component obtains the packet of the kernel shared queue, and sends the message to the a Linux protocol stack; the Linux protocol stack writes a message to the SOCKET receive buffer, so that the target process obtains the message from the SOCKET receive buffer.
  • the process of obtaining the packet from the target process side, the corresponding processing manner of the different packets, so that the target process obtains the packet according to the target shared queue may include: enabling the user in the target process
  • the state drive component obtains the user mode type packet from the user process sharing queue and forwards the packet to the user state type packet processing module in the target process to perform packet parsing processing;
  • the shared queue obtains the kernel mode type message, and sends the kernel state type message to the target process (for example, for a kernel mode driver component composed of a kernel mode virtual network card driver, the kernel mode virtual network card may be used.
  • the driver forwards the message to the kernel protocol stack and then passes it to the target process through the SOCKET interface, so that the kernel state type message processing module in the target process receives and performs the "3 ⁇ 4 text parsing process.
  • the processing process after the programmable hardware component receives the message is mainly described, and correspondingly, the programmable hardware component can also send the message.
  • a single board has a programmable hardware component (of course, there may be multiple programmable hardware components, each of which is responsible for communication of some processes in the board), if the messages are the same
  • the programmable hardware component that processes the message and the programmable hardware component that receives the message can be the same object. If the message is sent by the process in another board, When a process is in the board, the programmable hardware component sent by the message and the programmable hardware component that receives the message are different objects.
  • FIG. 3 is a schematic diagram of another specific process of the distributed multi-process communication method in the embodiment of the present invention.
  • the sending process of the source process message is performed by using a programmable hardware component as an example.
  • the method includes the following steps.
  • the programmable hardware component obtains a packet from a source shared queue, where the packet is a source process that writes a packet of a source shared queue corresponding to the source process, and the packet includes a source process address and a target process. address.
  • the programmable hardware component forwards the packet according to the source process address, the target process address, and the locally stored route distribution information in the file.
  • the specific forwarding is different according to the location of the destination process of the packet. If the destination process is on the same board as the source process, and the programmable hardware components of the packet forwarding are the same object, the forwarding described in this step is performed. , means to write the message to the corresponding In the target shared queue; if the destination process is on a different board than the source process, the forwarding here means that the programmable hardware component sends the message to the corresponding interface, for example, the aforementioned XAUI interface, SPi4 interface, serdes interface. Or the Rgmii interface, etc., is forwarded to the target board through these interfaces, and the corresponding programmable hardware group on the target board adopts the manner described in the foregoing FIG. 1 to perform packet processing.
  • the packet type in this example may also include multiple types.
  • the packet type includes a user mode type and a kernel mode type
  • the method further includes: the source process reports the user mode type. And sending, by the source process, a kernel state type packet to a kernel state driving component corresponding to the source process, where the kernel state driving component reports the kernel state type
  • the text is written to the kernel shared queue corresponding to the source process.
  • the packet in the foregoing embodiments may also include a unicast packet, a multicast packet, and a broadcast packet, where the destination routing information of the unicast packet and the multicast packet are stored in the corresponding routing distribution information.
  • Purpose process information When receiving a packet and sending a packet, you need to distinguish whether the packet is a unicast packet, a multicast packet, or a broadcast packet.
  • Unicast is the process of forwarding communications from the source to the destination in the network. There is only one sender, and one recipient, such as point-to-point communication; multicast is the communication between a single sender and multiple recipients on a network. Multicast technology wants to listen to or listen to many recipients at the same time.
  • Seeing the same source is used to reduce network communication by delivering a single stream of information to many recipients; "broadcasting" can be understood as a person speaking to the entire audience through a broadcast horn, which has the advantage of high call efficiency, information The child can be passed to the whole.
  • the following describes the format of multicast messages and unicast messages, and the contents of the corresponding route forwarding information.
  • the last two bytes of the MAC frame header address of the unicast communication are set to the last two bytes of the process address, and the rest of the remaining bytes are fixed to 00-eO-fc-fc;
  • the last two bytes of the MAC frame header address are set to the last two bytes of the process address, and the highest 4 bytes are fixed to the multicast address 01-00-5e-58-58.
  • the multicast address is divided into 256 according to the last byte. For a multicast group, the process joining each multicast group can receive the multicast message of the address.
  • the content of the routing information stored in the programmable hardware component (in this example, stored in the form of a routing forwarding table).
  • the unicast address must have at least one column, and the other column should be the process number (which queue is identified).
  • the multicast matching bitmap is a column, and each process occupies one bit. If it is 1, it needs to be copied into the process queue, so it is not copied. This defines a maximum of 32 processes. In fact, you can extend more than 32 processes. of course,
  • the table can also include the target process address, source process address, message protocol type, mask match, and so on.
  • the FPGA performs forwarding table masking and matching, and if it matches successfully, it is written into the specified process.
  • the figure consists of a unicast MAC address matching table and a multicast group matching bit chart.
  • the number of unicast MAC address matching tables is determined by the number of processes that the board is to run. It needs to be larger than the latter.
  • the matching of multicast MAC addresses is in the form of a bitmap, and the multicast MAC address of the communication is divided into 256 by the last byte.
  • Multicast group each group sets a matching bitmap long word.
  • each process to be run corresponds to one bit in the bitmap long word, and a setting of 1 indicates that the process is to receive the multicast message, and vice versa.
  • Multicast communication messages are one-to-many, so that matching the bits of a long word indicates whether the corresponding process is to be received.
  • the packet needs to be copied according to the situation when the packet is forwarded, that is, the hardware logic component identifies the packet as a multicast message, and according to the multiple destination process information of the multicast packet
  • the multicast message is copied; and the plurality of the multicast messages obtained by the copy are placed in a corresponding target shared queue.
  • the hardware logic component corresponding to the source process. If the packet is sent to a different board, the hardware logic component identifies the packet as a multicast packet. The plurality of destination process information of the broadcast message is copied to the multicast message, and the plurality of the multicast packets obtained by the copy are correspondingly forwarded through the interface.
  • the system used in this example is a Linux system.
  • 501 When a Linux user process sends IPC and UIP packets, the IPC and UIP packet processing modules in the process write the packets to the process sending queue of the user process shared queue.
  • the FPGA logic periodically queries the queue. If a packet is found to be sent, the target MAC address of the packet is checked. For the unicast message, the process proceeds to step 502, otherwise the multicast message is transferred to step 503 for processing.
  • Figure 5 only the flow diagram of the execution of the FPGA logic component when the Linux user process sends IPC and UIP messages is illustrated.
  • the TCP packet processing module in the process is sent to the Linux protocol stack of the Linux system kernel through the created SOCKET for processing.
  • the kernel state driver is used (for example, the network card driver is invoked).
  • Send function Send the processed message to the FPGA logic component (ie FPGA chip) for processing.
  • the Linux protocol stack uses SKB memory management, and the hardware shared memory used by the network card driver is different, here is a report by the network card driver. Copy of the text. (not shown)
  • For a unicast packet extract the target MAC address and the unicast routing sub-publishing and perform matching. If the matching succeeds, the packet is written into the receiving sharing queue of the receiving process of the routing sub-publishing indication, and if the matching fails, If the target process is a process on the other board, the packet is sent to the XAUI interface.
  • the multicast message For the multicast message, extract the target MAC address to obtain the multicast group number, and obtain the multicast component sending bitmap in the route distribution table. If the multicast component sends a bitmap to zero, the packet is sent to the XAUI interface. Otherwise, the loop processing writes the packet to the receiving shared queue of the receiving process indicated by the multicast group bitmap in turn, and the packet reference count is incremented by one. After the processing is complete, the packet needs to be sent to the XAUI interface. Because the multicast receiver process may also exist in another board.
  • the processing flow diagram of the kernel side ie, the FPGA logic component and other kernel drivers of the message receiving direction in the embodiment of the present invention is shown.
  • the system used in this example is still a Linux system. It is assumed that the packet is from another board.
  • the logic component of the FPGA After receiving the packet from the XAUI interface, the logic component of the FPGA first analyzes the packet type field of the MAC header. If the packet is an IPC packet, the process proceeds to step 602. Otherwise, the device continues to check whether the packet is a UIP packet. The text proceeds to step 602 to continue processing, and other types of messages are transferred to step 603 for processing.
  • the process is similar to the process of the user process for sending the message.
  • the FPGA logic first checks the destination MAC address of the message. If it is a unicast type message, the process proceeds to step 604 to perform route distribution processing; otherwise, the multicast type message is transferred to step 605 to continue processing.
  • the FPGA logic writes to the network card receiving queue.
  • the kernel card driver in the kernel mode periodically queries the network card receiving queue, and then sends the message to the Linux protocol stack after the message is found. Since the Linux protocol stack uses SKB memory management, and the hardware shared memory of the FPGA logic is different, a copy of the message is required here. After the TCP protocol is processed in the Linux protocol stack, the packet is written to the SOCKET receive buffer, and the user process obtains the communication packet from the receive buffer of the SOCKET connection.
  • the unicast type packet For the unicast type packet, extract the target MAC address and the unicast route sub-publishing to match, and if the matching succeeds, write the packet into the receiving shared queue of the receiving process of the routing sub-publishing indication. Otherwise, the text will be discarded.
  • For a multicast type packet extract a target MAC address, obtain a multicast group number, and obtain a route.
  • Multicast distribution bitmap in the publication If the multicast distribution bitmap is zero, the message is discarded; otherwise, the loop processing sequentially writes the message into the receiving shared queue of the receiving thread indicated by the multicast bitmap, and the message reference count is incremented by one.
  • FIG. 7 a process flow of the user side in the packet receiving direction in the embodiment of the present invention is shown. This example corresponds to the processing on the user side after the kernel side processing in Fig. 6.
  • Linux user mode driver component (program) Timely querying its own message receiving shared queue.
  • the process includes an active process and a standby process.
  • the active/standby process is switched, the primary process address in the route distribution information is mapped to the standby process address, or the standby process address is associated with the primary process address.
  • FIG. 8 is a schematic diagram of the active/standby process switching in the embodiment of the present invention.
  • the service processing board HI runs the process A H11 and the process B H12
  • the service processing board H3 runs the process C H31 and the process D H32.
  • Process B H12 and process D H32 are the active/standby configuration relationship.
  • Process B H12 is the master and process D H32 is the standby.
  • the active process processes the service data packets, and the standby process does not process the data, and the data is synchronized between the active and standby processes.
  • H2 is a board that exchanges packets between multiple service boards, similar to a common Ethernet switch/Hub.
  • a link between the board and the board maintenance board H4 is established through the TCP connection, and the topology table of the process communication relationship is downloaded.
  • Each process is configured in the routing forwarding table of the card according to the downloaded topology relationship table.
  • the configured content includes the communication MAC address of the process, the multicast group bitmap to be added, and so on.
  • the operation and maintenance board H4 issues a switching command to the active process B H12.
  • the active process modifies the routing forwarding table H13, and changes the communication MAC address of the process to the MAC address of the standby process, and completes the operation of the primary process to the standby process. .
  • the packet is discarded because the FPGA logic queries the route forwarding table H13, so that the process B H12 will not receive the service data packet.
  • the operation and maintenance board H4 issues a switching command to the standby process D H32, and the standby process D H32 modifies the routing forwarding table H33, and modifies the communication MAC address of the local machine to the MAC address of the active process.
  • the standby process is upgraded to the main process operation.
  • the message is forwarded because the FPGA logic queries the route forwarding table H33, so that the process D H32 can receive the service data packet, which is visible, without the participation of the sending process, switching
  • the process is relatively simple, just modify the routing forwarding table.
  • the embodiment of the present invention further provides a communication device, which can perform distributed multi-process communication.
  • the communication device is used for receiving a message, and the device includes: a programmable hardware component 80 And receiving the packet from the source process, and writing the packet to the target shared queue corresponding to the target process according to the source process address, the target process address, and the locally stored route distribution information in the packet, where The packet includes a source process address and a target process address.
  • the at least one process component 82 is configured to acquire the packet according to the target shared queue.
  • multiple process components are included accordingly.
  • the device (not shown) includes: at least one process component, configured to write the message to a source sharing queue corresponding to the process component, the message The source process address and the target process address are included; the programmable hardware component is configured to obtain the information from the source shared queue, and according to the source process address, the target process address, and the locally stored route in the message The distribution information forwards the message.
  • the apparatus for distributed multi-process communication may include a programmable hardware component 80, where the programmable hardware component 80 may include: a receiving module 800, configured to receive from a source process, where the source includes a source process address and a target process address; the write module 802 is configured to distribute information according to the source process address, the target process address, and the locally stored route in the packet. And writing the packet to the target shared queue corresponding to the target process, so that the target process acquires the packet according to the target shared queue.
  • a receiving module 800 configured to receive from a source process, where the source includes a source process address and a target process address
  • the write module 802 is configured to distribute information according to the source process address, the target process address, and the locally stored route in the packet. And writing the packet to the target shared queue corresponding to the target process, so that the target process acquires the packet according to the target shared queue.
  • the programmable hardware component 80 can further include (shown in phantom in FIG. 10): an identification module 804, configured to identify the message type,
  • the "3" type includes a user mode type and a kernel mode type; correspondingly, the writing module 802 is further configured to distribute the information according to the source process address, the target process address, and the locally stored route distribution information in the packet.
  • the user mode type message is written to the user process shared queue corresponding to the target process
  • the kernel state type message is written to the kernel shared queue corresponding to the kernel mode driver component.
  • the route distribution message The destination process information of the unicast message and the multiple destination process information of the multicast message are stored in the information; the identification module 804 is further configured to identify that the message is a multicast message; The 802 is further configured to: replicate the multicast packet according to the multiple destination process information of the multicast packet, and put the plurality of the multicast packets obtained by the replication into the corresponding target shared queue.
  • the programmable hardware component included therein may include an obtaining module, configured to acquire a message from the source shared queue, The message is that the source process writes the source shared queue corresponding to the source process, and the packet includes the source process address and the target process address, and the forwarding module is configured to use the source process address and the target process in the packet.
  • the address and the locally stored route distribution information forward the message.
  • the user component driver 82 is configured to obtain a user mode type message from the user process sharing queue, as shown in FIG. And the user state type message processing module 822 is configured to receive the user state type message and perform message parsing processing; the kernel state type message processing module 824 is configured to The receive kernel state driver component 84 obtains the kernel state type message sent from the kernel shared queue, and performs packet parsing processing.
  • the apparatus 8 further includes a kernel state driving component 84, configured to send the kernel state type packet obtained from the kernel sharing queue, and send the kernel state type packet to the kernel state packet Processing module.
  • a kernel state driving component 84 configured to send the kernel state type packet obtained from the kernel sharing queue, and send the kernel state type packet to the kernel state packet Processing module.
  • the user state driving component 82 is further configured to write the user mode type to the user process sharing queue shared by the programmable hardware component.
  • the kernel state type message processing module 824 is further configured to send a kernel state type message to the kernel state driving component; the kernel state driving component 84 is further configured to acquire and write the kernel state type message Entering a kernel shared queue shared with the programmable hardware component; the programmable hardware component 80 is further configured to obtain a corresponding packet from the user process shared queue and the kernel shared queue, and distribute the route according to the locally stored route The information is forwarded to the message.
  • FIG. 12 is a schematic diagram of another specific composition of a communication device in an embodiment of the present invention.
  • the device uses the Linux operating system, and the FPGA logic component sends and receives Ethernet packets through the XAUI interface.
  • the device is powered by the kernel state driver component G11 located in the Linux kernel state and is located in the Linux user mode.
  • the user state drive component G15, the Linux operating system protocol stack G12 and the FPGA logic component G20 are composed.
  • the process running on the Linux system processes the IPC and UIP packets through its user-mode driver component and processes the TCP packets through the Linux protocol stack.
  • Each process manages its own software shared memory area G18 in the user mode, and the FPGA logic manages its own hardware shared memory G22. In this way, the hardware FPGA uses the memory managed by itself after receiving the message.
  • the user process sends the message, it can use its own memory to manage its own memory.
  • Each of its own memory has the advantages of simplicity, less interaction, and high efficiency.
  • the user mode driver component G15 and the PGA logic component G20 receive and send messages through the user process sharing queue G16.
  • the processing steps in this example are as follows.
  • the Linux operating system After the Linux operating system starts, it loads the kernel-mode driver component (that is, the virtual network card driver) G11, and maps the user process shared queue G16, software shared memory G18, and hardware shared memory G22. At the same time, the register address of the FPGA operation is mapped to the user mode, and the program environment of the user state driving component G15 is established.
  • the kernel-mode driver component that is, the virtual network card driver
  • a user process needs a queue to read a message from the FPGA.
  • the queue stores the address of the message as not the content. That is, the address of the shared queue G16 needs to be mapped into the process's own virtual address space.
  • the G18, G22 memory used to store the message content.
  • it is divided into two physical memory areas. It should be noted here that all Linux processes map the virtual addresses of the two spaces to be the same, so that communication between processes does not cause access exceptions.
  • the FPGA uses the physical address, and the user state process uses the virtual address. This work is driven by the user mode.
  • A12 After the user process starts, initialize the address space of the mapped user process shared queue, software shared memory area and hardware shared memory area. The user process connects to the operation and maintenance center through the TCP communication module G13, and downloads the process node configuration relationship. Finally, the address information of the process is written into the routing sub-post G21.
  • A13 The Ethernet packet from the XAUI port is received and processed by the FPGA logic component G20, and the received Ethernet packet is analyzed according to the information distributed in the G21. If it is an IPC or UIP message, it is written into the user process sharing queue G16, received by the user state driving component G15, and finally delivered to the UIP processing module G14 and the IPC processing module G17. For other types of messages written to the NIC receive queue (ie kernel shared queue) G19, the NIC driver G11 query and then handed over to the Linux protocol stack G12 The processing is then received by the TCP communication module G13 that is handed over to the process through the SOCKET interface.
  • the NIC receive queue ie kernel shared queue
  • A14 User mode process UIP processing module G14 and IPC processing module
  • G17 needs to send a message, it requests space from the shared memory G18, and the user mode drives G15 to write the process to send queue G16.
  • the FPGA logic component G20 obtains the packet from the process sending queue G16 and sends it to the XAUI interface after querying the user process packet.
  • the SOCKET interface established by the TCP communication module G13 is sent to the Linux kernel protocol stack G12, and the transmission function of the kernel state driver component G11 is called to write the network card transmission queue (ie, the kernel shared queue) G19, and finally by the FPGA logic component. After the G20 query is sent to the XAUI interface.
  • the PGA logic component G20 needs to receive the memory from the hardware shared memory area G22 when receiving the message from the XAUI interface; when the FPGA logic component G20 releases the memory, the memory is returned to the hardware shared memory area.
  • User state process component G15 needs to allocate memory from the software shared memory area G18 when the message is sent; user state process G15 releases the memory to the software shared memory area when the memory is released.
  • a message release message is constructed and written into the user process sharing queue G16.
  • the user mode driver component G15 queries the release message, the message memory is released to the software memory sharing area G18.
  • a message release message is constructed and written to the user process send queue G16.
  • the FPGA logic queries the release message, the message memory is released into the hardware shared memory area G22.
  • the slave network cache queue When the kernel mode needs to apply for the hardware memory of the FPGA logic, the slave network cache queue.
  • the kernel state driver G11 needs to release the hardware memory of the FPGA logic, a message release message is constructed and written to the network card transmission queue G16.
  • the FPGA logic queries the release message, the message memory is released into the hardware shared memory area G22.
  • the programmable hardware component is configured to forward the inter-process packet according to the local routing distribution information, and the routing information can be flexibly configured to receive the packet of the specific process and block the unwanted garbage packet.
  • the target shared queue is used to exchange messages, which realizes zero copy of the memory, reduces system calls, and reduces the CPU occupation rate.
  • the message is divided into user mode processing and kernel mode processing, which effectively utilizes the advantage that the user state driver is easy to perform online upgrade and easy management.
  • the storage medium may be a magnetic disk, an optical disk, a read-only memory (ROM), or a random access memory (RAM).

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本发明实施例公开了一种分布式多进程通信方法和装置，该方法包括：可编程硬件组件接收来自源进程的报文，所述报文中包括源进程地址和目标进程地址；所述可编程硬件组件根据所述报文中的源进程地址、目标进程地址和本地存储的路由分发信息将所述报文写入目标进程对应的目标共享队列，使所述目标进程根据所述目标共享队列获取所述报文。采用本发明，可高效的实现各种进程之间的通信。

Description

一种分布式多进程通信方法和装置 技术领域
本发明涉及处理器系统领域， 尤其涉及一种分布式多进程通信方法和装置。 背景技术
多内核 （ multicore chips ), 或称多核芯片是指在一枚处理器 （ chip ) 中集成 两个或多个完整的计算引擎（内核）。 对应用多核芯片的计算机， 其对计算机操 作系统的要求也与传统系统不同。 多核操作系统最大的特点是将内存、 输入输 出 （Input Output, 10 ) 外设资源共享给多个内核使用。 如基于对称多处理 ( Symmetrical Multi-Processing , SMP ) 内核的 Linux操作系统是一种目前广泛 使用的多核操作系统。
基于 SMP内核的 Linux操作系统也越来越广泛地应用于通信系统中， 在通 信系统中通常利用 Linux操作系统亲和性将进程绑定到特定的硬件核上。但由于 Linux进程的用户访问空间是独立的， 两个进程互相不能访问对方的用户空间， 这就存在进程之间互相通信的问题。例如，在一个 Linux操作系统内的多个用户 进程之间、一个单板的 Linux系统用户进程和其他单板的 Linux系统用户进程之 间、一个单板的 Linux系统用户进程和其他单板其他操作系统（如实时操作系统 vxworks等）之间都存在进程间通信的需要求，这也是分布式多进程通信的情况。
在现有的 Linux操作系统中， 为进程之间的通信提供了包括管道、先进先出 ( First In First Out, FIFO )、消息队列、信号量、共享内存、信号、套接字（ SOCKET ) 机制等方式。
总的来说上述的进程间通信机制使用简单， 不适使用多进程之间多参数的 通信， 只适用于一个 Linux SMP系统中的不同进程之间的通信， 无法实现位于 不同单板不同操作系统之间进程间通信。
而基于 Linux网卡驱动的零拷贝技术也存在诸多问题。在该技术中，用户进 程将整个报文物理内存映射到用户进程空间， 使用网卡驱动和用户进程之间的 共享队列实现报文交互的零拷贝， 将网卡接收到所有报文捕获到用户进程。 在 用户态上运行一个转发进程， 用于识别送往各个不同用户进程的报文， 再通过 位于用户态的共享队列和各个用户进程通信。 当用户要发送报文时候， 先将报 文发送到转发进程， 由转发进程发送到网卡驱动最后出网卡硬件。
该技术采用网卡驱动底层报文捕获方法， 将所有报文接收到转发进程， 由 于传输控制协议（ Transmission Control Protocol , TCP )通信的报文需要使用 Linux 的内核协议栈进行处理。这样需要转发进程识别后再下送到 Linux协议栈， Linux 协议栈处理完成后再由内核协议栈交给用户态进程处理。 这种方式实现困难而 且效率较低。 由于没有 SOCKET编程接口， 给应用程序带来很多移植性问题。 同时， 内核态的网卡驱动通过中断方式接收来自网卡的报文， 频繁的中断和软 中断严重影响了 Linux内核性能。 另外中断的处理需要绑定到一个核上， 浪费了 有限的中央处理器（Central Processing Unit, CPU ) 资源， 使得位于内核态的网 卡驱动升级更新困难。 发明内容
本发明实施例所要解决的技术问题在于， 提供一种用分布式多进程通信方 法和装置。 可高效的实现各种进程之间的通信。
为了解决上述技术问题， 本发明实施例提供了一种分布式多进程通信方法， 包括：
可编程硬件组件接收来自源进程的报文 , 所述报文中包括源进程地址和目 标进程地址；
所述可编程硬件组件根据所述> ^文中的源进程地址、 目标进程地址和本地 存储的路由分发信息将所述报文写入目标进程对应的目标共享队列， 使所述目 标进程根据所述目标共享队列获取所述报文。
本发明实施例还提供了一种分布式多进程通信方法， 包括：
可编程硬件组件从源共享队列中获取报文， 所述报文是源进程写入与所述 源进程对应的源共享队列的报文， 且所述 · ^文包括源进程地址和目标进程地址； 可编程硬件组件根据所述报文中的源进程地址、 目标进程地址和本地存储 的路由分发信息对所述报文进行转发。
相应的， 本发明实施例还提供了一种用于分布式多进程通信的装置， 包含 可编程硬件组件， 该可编程硬件组件包括：
接收模块， 用于接收来自源进程的报文， 其中， 所述报文中包括源进程地 址和目标进程地址； 写入模块， 用于根据所述报文中的源进程地址、 目标进程地址和本地存储 的路由分发信息将所述报文写入目标进程对应的目标共享队列， 使所述目标进 程根据所述目标共享队列获取所述报文。
相应的， 本发明实施例还包括一种用于分布式多进程通信的装置， 包含可 编程硬件组件， 该可编程硬件组件包括：
获取模块， 用于从所述源共享队列中获取报文， 所述报文是源进程写入与 所述源进程对应的源共享队列， 且所述 ·艮文包括源进程地址和目标进程地址； 转发模块， 用于根据所述报文中的源进程地址、 目标进程地址和本地存储 的路由分发信息对所述报文进行转发。
本发明实施例还提供了一种通信装置， 可进行分布式多进程通信， 所述装 置包括：
可编程硬件组件， 用于接收来自源进程的报文， 并根据所述报文中的源进 程地址、 目标进程地址和本地存储的路由分发信息将所述 ~¾文写入目标进程对 应的目标共享队列， 其中， 所述^ 中包括源进程地址和目标进程地址；
至少一个进程组件， 用于根据所述目标共享队列获取所述报文。
相应的， 本发明实施例还提供了一种通信装置， 可进行分布式多进程通信， 该装置包括：
至少一个进程组件， 用于将报文写入与所述进程组件对应的源共享队列， 所述报文包括源进程地址和目标进程地址；
可编程硬件组件， 用于从所述源共享队列中获取所述报文， 并根据所述报 文中的源进程地址、 目标进程地址和本地存储的路由分发信息对所述报文进行 转发。
在本发明实施例中， 新设置一可编程硬件组件， 其根据本地路由分发信息 进行进程间报文的转发， 可以通过灵活的配置路由分发信息来实现对特定进程 报文的接收、 屏蔽不想要的垃圾报文， 同时采用目标共享队列交互报文， 实现 了内存零拷贝， 减少了系统调用， 减少了 CPU的占有率。 附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案， 下面将对实施 例或现有技术描述中所需要使用的附图作筒单地介绍， 显而易见地， 下面描述 中的附图仅仅是本发明的一些实施例， 对于本领域普通技术人员来讲， 在不付 出创造性劳动性的前提下， 还可以根据这些附图获得其他的附图。
图 1是本发明实施例中的分布式多进程通信方法的一个具体流程示意图； 图 2是本发明实施例中的三种报文的一个具体格式示意图；
图 3是本发明实施例中的分布式多进程通信方法的另一个具体流程示意图； 图 4是存储在可编程硬件组件中的路由转发信息的内容示意图；
图 5是本发明实施例中的报文发送方向的一个具体处理流程的示意图； 图 6是本发明实施例中的接收方向的内核侧一个具体处理流程的示意图； 图 7是本发明实施例中的报文接收方向的用户侧的一个具体处理流程示意 图；
图 8是本发明实施例中的主备进程倒换时的示意图；
图 9是本发明实施例中的分布式多进程通信装置的一个具体组成示意图； 图 10是本发明实施例中的可编程硬件组件的一个具体组成示意图； 图 11 是本发明实施例中的分布式多进程通信装置的另一个具体组成示意 图；
图 12 是本发明实施例中的分布式多进程通信装置的另一个具体组成示意 图。 具体实施方式
下面将结合本发明实施例中的附图， 对本发明实施例中的技术方案进行清 楚、 完整地描述， 显然， 所描述的实施例仅仅是本发明一部分实施例， 而不是 全部的实施例。 基于本发明中的实施例， 本领域普通技术人员在没有作出创造 性劳动前提下所获得的所有其他实施例， 都属于本发明保护的范围。
在本发明实施例中通过设置运行在操作系统之外的可编程硬件组件， 如 FPGA逻辑组件）来对报文进行分发处理， 可以在增加极低的硬件成本的基础上 实现不依赖于操作系统的进程间通讯。 同时， 为进一步提高效率， 可采用用户 态驱动接收来自 FPGA的用户数据报文（User Internet Protocol, UIP )报文， 内 核态虚拟网卡驱动接收来自 FPGA的 TCP报文等， 以实现用户报文的零拷贝， 且充分利用用户态驱动， 具有调试方便， 容易升级修改， 不易导致内核挂死等 优点。 同时由内核协议栈进行处理后再交给用户态进程处理， 充分发挥操作系 统中内核丰富的网络协议栈功能。
同时， 本发明实施例可运用在 Linux操作系统中， 但不限于 Linux操作系 统，也可以应用于 windows/vxworks等操作系统， 或者是无操作系统的裸核应用 中。
如图 1 所示， 为本发明实施例中的分布式多进程通信方法的一个具体流程 示意图， 在该实施例中， 以可编程硬件组件进行 4艮文接收后对 4艮文进行分发处 理为例进行说明， 该方法包括如下步驟。
101、 可编程硬件组件接收来自源进程的报文， 所述报文中包括源进程地址 和目标进程地址。 所述可编程硬件组件可以是可进行编程的逻辑电路， 如， 运 行在操作系统之外的 FPGA逻辑等 , 只要该逻辑电路可以实现所需的编程功能。
可编程硬件组件通过通讯接口 , 如每秒万兆以太网连接单元 （ X Ethernet Attachment Unit Interface, XAUI )接口、 SPi4接口、 serdes接口或者 Rgmii接 口等， 接收来自其他单板的以太网报文， 或是通过共享队列获得单板内的某一 进程发送给单板内的其他进程的报文。 因而， 此处描述的源进程可以是与可编 程硬件组件运行在同一单板上的进程， 也可以是另一单板运行的进程。
上述分布式多进程交互的报文通常有如下几种类型： 实现和服务器单板的 可靠通信的 TCP 报文、 实现进程之间点对点的通信的进程间通信 ( Inter-Process Communication, ΙΡθ · ^文、 实现进程之间业务数据传递的 UIP 报文、 还有 ARP报文、 ICMP报文、 Ping报文等。 其中， ARP协议和 ICMP协 议是常用的 TCP/IP底层协议， 是在对网络故障进行诊断的时候最常用的协议。 ARP协议负责将某个 IP地址解析成对应的媒体访问控制（ Media Access Control, MAC )地址。 ICMP 报文提供针对网络层的错误诊断、 拥塞控制、 路径控制和 查询服务四项大的功能。 Ping 命令通过向计算机发送 ICMP 回应报文并且监听 回应报文的返回， 以校验与远程计算机或本地计算机的连接。
报文的物理传输采用以太网数据帧封装， 报文开头为目标进程和源进程的 MAC地址，如图 2所示，为本发明实施例中的三种报文的一个具体格式示意图， 在报文中包括源进程地址、 目标进程地址、 报文类型和相应通信报文。 其中进 程全局唯一地址是整个系统中唯一标识进程的标识号。 本例中只用了 2个字节 , 将进程地址的内容和 MAC地址对应起来。这样进程地址的高 2字节就固定不变 , 同样 MAC地址的高 4字节固定不变。 其中和服务器单板的可靠通信报文是承载在 TCP之上的， 用于下载进程的 配置数据、 进程节点之间的拓朴关系、 以及进程接收多播报文需要加入的多播 组。 该报文由 MAC头、 IP头、 TCP头以及静荷组成， 这种类型报文数据较少。
进程之间点对点的通信 IPC报文， 采用自定义一种以太网帧， MAC头中的 帧类型设置为私有类型。 该通信报文用于两个进程之间可靠滑动窗口、 确认重 发方式的通信。 该报文由 MAC头以及静荷组成， 这种类型报文数量较多。
进程之间业务数据 UIP报文， 承载在 IP报文之上， 采用一种自定义的 IP 协议号。 该通信报文包括用于两个进程之间的单播业务数据报文和一对多个进 程之间的多播业务数据报文。 该报文由 MAC头、 IP头以及静荷组成， 这种类型 报文数量最多。
102、 可编程硬件组件根据所述报文中的源进程地址、 目标进程地址和本地 存储的路由分发信息将所述报文写入目标进程对应的目标共享队列， 使所述目 标进程根据所述目标共享队列获取所述报文。 一般， 一个目标进程对应有自己 的目标共享队列， 其可以从该队列中获取4艮文。 当然， 对于其他未配置路由转 发表信息的报文将被可编程硬件组件丟弃。
在本步骤中， 由于用户态驱动具有容易在线升级等优点， 可将报文根据具 体类型由用户态驱动和内核态驱动分别处理， 当然， 也可以不做区分而全部由 内核态处理。
若采用分别处理的方案， 则将报文分为两种类型： 用户态类型和内核态类 型， 目标共享队列则分为与用户态驱动共享队列 （或称用户进程共享队列） 和 与内核态驱动共享队列 （或称内核共享队列）。 这样一来， 本步骤具体可包括： 所述可编程硬件组件识别所述报文类型； 所述可编程硬件组件根据所述报文中 的源进程地址、 目标进程地址和本地存储的路由分发信息将用户态类型报文写 入与所述目标进程对应的用户进程共享队列， 将内核态类型报文写入与内核态 驱动组件对应的内核共享队列。
在区别哪些报文由用户态驱动处理， 哪些报文由内核态驱动处理时， 可按 如下方式， 即用户态类型报文包括进程间通讯报文和 /或用户数据报文， 内核态 类型报文包括 TCP (传输控制）报文、 ARP报文、 ICMP报文中的一种或多种。
同时， 在本例中， 在将报文写入内核共享队列， 由内核态驱动进行报文传 递时， 可包括： 所述可编程硬件组件根据所述报文中的源进程地址、 目标进程 地址和本地存储的路由分发信息将所述报文写入与内核态驱动组件对应的内核 共享队列； 所述内核态驱动组件获取所述内核共享队列的报文， 并将所述报文 发送至 Linux协议栈； 所述 Linux协议栈将4艮文写入 SOCKET接收緩冲区， 以 便所述目标进程从所述 SOCKET接收緩冲区中获得所述报文。
那么从目标进程侧获取报文的过程来看， 相应上述的不同报文的区别处理 方式， 使目标进程根据所述目标共享队列获取所述报文则可包括： 使所述目标 进程中的用户态驱动组件从所述用户进程共享队列获取所述用户态类型报文并 转发给所述目标进程中的用户态类型报文处理模块进行报文解析处理； 所述内 核态驱动组件从所述内核共享队列获取所述内核态类型报文， 并将所述内核态 类型报文发送给所述目标进程 （如， 对于由内核态虚拟网卡驱动组成的内核态 驱动组件来说， 可由内核态虚拟网卡驱动将报文转发内核协议栈处理， 再通过 SOCKET接口交给目标进程 ),使所述目标进程中的内核态类型报文处理模块接 收并进行"¾文解析处理。
上述步骤中， 主要描述了可编程硬件组件接收报文后的处理过程， 相应的 , 可编程硬件组件也可进行报文发送。 那么相应于上述流程， 假定一个单板具有 一个可编程硬件组件 （当然， 也可以有多个可编程硬件组件， 每个可编程硬件 组件负责单板中部分进程的通信）， 若报文是同一单板内进程发送给另一进程 时 , 则处理艮文发送的可编程硬件组件和处理 ^艮文接收的可编程硬件组件可为 同一对象， 若报文是另一单板内的进程发送给本单板中的进程时， 则报文发送 的可编程硬件组件和处理报文接收的可编程硬件組件为不同对象。
如图 3 所示， 为本发明实施例中的分布式多进程通信方法的另一具体流程 示意图。 在该实施例中， 以可编程硬件組件进行源进程报文的发送处理为例进 行说明， 该方法包括如下步骤。
301、 可编程硬件组件从源共享队列中获取报文， 所述报文是源进程写入与 所述源进程对应的源共享队列的报文， 且所述报文包括源进程地址和目标进程 地址。
302、 可编程硬件组件根据所述 ^艮文中的源进程地址、 目标进程地址和本地 存储的路由分发信息对所述报文进行转发。 当然， 具体的转发根据报文的目的 进程所在位置有所区别， 若目的进程与源进程处于同一单板， 且其报文转发的 可编程硬件组件为同一对象， 则本步骤中所描述的转发， 是指将报文写入相应 的目标共享队列中； 若目的进程与源进程处于不同单板， 则此处的转发是指可 编程硬件组件将 4艮文发送至相应的接口， 如， 前述的 XAUI接口、 SPi4接口、 serdes接口或者 Rgmii接口等， 通过这些接口转发至目标单板， 再由目标单板 上的相应的可编程硬件组采取前述图 1所描述的方式进行报文处理。
与前述实施例相同的， 本例中的报文类型也可以包括多种， 如报文类型包 括用户态类型和内核态类型， 则在步骤 301 之前还包括： 所述源进程将用户态 类型报文发送给所述源进程对应的用户进程共享队列； 所述源进程将内核态类 型报文发送给所述源进程对应的内核态驱动组件， 所述内核态驱动组件将所述 内核态类型报文写入与源进程对应的内核共享队列。
同时， 上述各实施例中的报文也可包括单播报文、 多播报文和广播报文， 相应的路由分发信息中存储有所述单播报文的目的进程信息和所述多播报文的 多个目的进程信息。 在接收报文和发送报文时， 需要区别报文为单播报文、 多 播报文还是广播报文。 单播是在网络中从源地到目的地转发通信的过程。 仅有 一个发送者， 和一个接受者， 如可称为点对点通信； 多播是在一个网络上一单 个发送者和多个接收者之间的通信， 多播技术在很多接收者同时想收听或看相 同的源通过递送一单个信息流给很多接收者时被用于减少网络通信； "广播" 可 以理解为一个人通过广播喇叭对在场的全体说话， 这样做的好处是通话效率高， 信息一下子就可以传递到全体。
以下以示例说明多播报文和单播报文的格式， 以及对应的路由转发信息的 内容。
如图 2所示，单播通信的 MAC帧头地址最后两个字节设置为进程地址的最 后两个字节， 其他剩余字节内容为固定为 00-eO-fc-fc; 多播通信的 MAC帧头地 址最后两个字节设置为进程地址的最后两个字节， 最高 4 字节固定为多播地址 01-00-5e-58-58„ 多播地址根据最后一个字节划分为 256个多播组， 加入每个多 播组的进程能够接收该地址多播报文。
如图 4 所示， 为存储在可编程硬件组件中的路由转发信息 （本例中， 以路 由转发表的形式存储） 的内容示意图。
单播地址至少还有一列， 另一列应该是进程号（标识入哪个队列）。 多播匹 配位图就是一列， 每个进程占有一位， 如果为 1表示需要复制到该进程队列中， 为不复制。 这里定义了最大 32个进程。 其实可以扩展多于 32个进程。 当然， 该表中也可包括目标进程地址， 源进程地址， 报文协议类型， 掩码匹配等等。
FPGA进行转发表掩码与匹配， 如果成功匹配则写入指定的进程中。
如图所示， 由单播 MAC地址匹配表和多播组匹配位图表组成。 单播 MAC 地址匹配表的数目由单板要运行的进程数目决定的， 需要大于后者； 多播 MAC 地址的匹配采用位图形式，将通讯的多播 MAC地址按最后一个字节划分 256个 多播组， 每个组设置一个匹配位图长字。 这样每个要运行的进程对应位图长字 中的一位， 设置为 1 表示该进程要接收该多播报文， 反之不接收。 多播通信的 报文是一对多的方式， 这样匹配长字的各个位就表示对应的进程是否要接收。
相应于多播报文， 在进行报文转发时需要根据情况对报文进行复制， 即所 述硬件逻辑组件识别所述报文为多播报文， 根据所述多播报文的多个目的进程 信息对所述多播报文进行复制； 将复制获得的多个所述多播报文放入对应的目 标共享队列中。
在源进程对应的硬件逻辑组件进行报文转发时也类似， 若报文是发往不同 的单板， 则所述硬件逻辑组件识别所述报文为多播报文后， 也要根据所述多播 报文的多个目的进程信息对所述多播报文进行复制， 并将复制获得的多个所述 多播报文通过接口进行对应的转发。
为了更详细的描述上述流程， 以下分别 ΛΜ艮文发送和 文接收两个方面来 详细描述本发明的具体实施例。
如图 5 所示， 本发明实施例中的报文发送方向的处理流程示意图。 本例中 应用的系统为 Linux系统。
501、 当 Linux用户进程发送 IPC和 UIP报文时， 进程中的 IPC和 UIP报文 处理模块将报文写入用户进程共享队列的进程发送队列中。 FPGA逻辑定时查询 该队列， 如果发现有报文要发送， 则检查该报文的目标 MAC地址。 对于单播报 文则转步骤 502处理， 否则为多播报文转步骤 503进行处理。 图 5中仅示例了， 当 Linux用户进程发送 IPC和 UIP报文时的 FPGA逻辑组件执行的流程示意图。
当 Linux用户进程发送 TCP报文时， 进程中的 TCP报文处理模块通过创建 的 SOCKET发送到 Linux系统内核的 Linux协议栈进行处理， Linu 协议栈处理 完成后通过内核态驱动 （如， 调用网卡驱动的发送函数） 将处理后的报文发送 到 FPGA逻辑组件 （即 FPGA芯片）处理。 由于 Linux协议栈采用 SKB方式的 内存管理， 和网卡驱动使用的硬件共享内存不同， 这里由网卡驱动进行一次报 文拷贝。 （图中未示）
502、 对于单播报文， 提取其目标 MAC地址和单播路由分发表进行匹配， 如杲匹配成功则将该报文写入路由分发表指示的接收进程的接收共享队列中， 如杲匹配失败表明目标进程为另一单板中的进程， 则将报文发送到 XAUI接口 出单板。
503、 对于多播报文， 提取其目标 MAC地址获得多播组号， 获得路由分发 表中的多播组分发位图。如果该多播组分发位图为零则直接将报文发送到 XAUI 接口出单板。 否则循环处理将报文依次写入多播组位图指示的接收进程的接收 共享队列中， 同时报文引用计数加一， 处理完成后还需要将报文发送到 XAUI 接口出单板。 因为多播接收者进程也可能存在于另一单板中。
如图 6所示 , 本发明实施例中的报文接收方向的内核侧 （即 FPGA逻辑组 件和其他内核驱动）的处理流程示意图。 本例中应用的系统仍为 Linux系统， 假 定报文来自另一单板。
601、 FPGA逻辑组件从 XAUI接口接收到报文后， 首先分析其 MAC头的 报文类型域， 如果是 IPC报文则转步骤 602处理， 否则继续检查是否为 UIP类 型报文，如果是 UIP报文则转步骤 602继续处理， 其他的类型报文则转步骤 603 进行处理。
602、 对于 IPC和 UIP类型报文， 其与上述发送报文的用户进程处理的流程 类似。 FPGA逻辑首先检查报文的目标 MAC地址， 如果是单播类型报文则转步 骤 604进行路由分发处理； 否则为多播类型报文转步骤 605继续处理。
603、 对于非 IPC、 UIP类型的报文， FPGA逻辑写入网卡接收队列中， 位 于内核态的网卡驱动程序定时查询网卡接收队列， 发现存在报文后将其上送 Linux协议栈。 由于 Linux协议栈采用 SKB方式的内存管理， 和 FPGA逻辑处 理的硬件共享内存不同， 这里需要进行一次报文拷贝。 Linux协议栈中 TCP协 议处理完成后将报文写入 SOCKET接收緩冲区，用户进程从 SOCKET连接的接 收緩冲区中得到通信报文。
604、 对于单播类型的报文， 提取其目标 MAC地址和单播路由分发表进行 匹配， 如果匹配成功则将该报文写入路由分发表指示的接收进程的接收共享队 列中。 否则将艮文丢弃。
605、 对多播类型的报文， 提取其目标 MAC地址获得多播组号， 获得路由 分发表中的多播分发位图。 如杲该多播分发位图为零则将该报文丢弃； 否则循 环处理将报文依次写入多播位图指示的接收线程的接收共享队列中， 同时报文 引用计数加一。
如图 7所示， 本发明实施例中的报文接收方向的用户侧的处理流程示意图。 本例为相应于图 6中的内核侧处理后的用户侧的处理。
701、 Linux用户态驱动组件 （程序） 定时查询自己的报文接收共享队列。
702、 判断是否存在报文， 如果存在报文则需要分析报文类型， 对于 IPC类 型报文递交给上层 IPC接收函数处理； 对于 UIP类型报文递交给上层 UIP接收 函数处理； 如果共享队列中没有^ ^文则进行睡眠 1ms处理。
所述进程包括主用进程和备用进程， 当进行主备进程切换时， 将所述路由 分发信息中的主用进程地址对应为备用进程地址， 或将备用进程地址对应为主 用进程地址。 如图 8所示， 为本发明实施例中的主备进程倒换时的示意图。
如图所示， 业务处理板 HI上运行有进程 A H11和进程 B H12, 业务处理单 板 H3运行有进程 C H31和进程 D H32。 其中进程 B H12和进程 D H32是主备 配置关系， 进程 B H12是主， 进程 D H32是备。 主用进程处理业务数据包， 而 备用进程不处理， 主备进程之间进行数据的同步操作。 H2为多个业务板之间通 信需要进行报文交换的单板， 类似于常见的以太网交换机 /Hub等。
业务处理单板上的每个进程启动后，通过 TCP连接建立和槽位维护单板 H4 之间的链接， 下载进程通信关系的拓朴表。 每个进程根据下载的拓朴关系表配 置到本单板的路由转发表中。 配置的内容有本进程的通讯 MAC地址，要加入的 多播组位图等。
当进程关系发生主备倒换的时候， 主用进程 B H12倒换为备用进程， 备用 进程 D H32倒换为主用进程。 主备倒换的具体操作步骤为：
D11 : 操作维护单板 H4向主用进程 B H12发出倒换命令， 主用进程修改路 由转发表 H13 , 将本进程的通讯 MAC地址修改为备用进程的 MAC地址， 完成 主用进程降为备用进程操作。 来自其他进程的业务数据包到达业务处理板 HI 后， 由于 FPGA逻辑查询路由转发表 H13失败， 报文被丢弃， 这样进程 B H12 将接收不到业务数据报文。
D12: 操作维护单板 H4向备用进程 D H32发出倒换命令， 备用进程 D H32 修改路由转发表 H33 , 将本机的通讯 MAC地址修改为主用进程的 MAC地址， 完成备用进程升级为主用进程操作。 来自其他进程的业务数据包到达业务处理 板 H3后， 由于 FPGA逻辑查询路由转发表 H33成功， 报文被转发， 这样进程 D H32就能接收到业务数据包， 可见， 无需发送进程的参与， 倒换过程比较简单， 只需要修改路由转发表就行。
相应的， 本发明实施例还提供了一种通信装置， 可进行分布式多进程通信， 如图 9 所示， 本例中通信装置用于报文的接收， 该装置包括： 可编程硬件组件 80, 用于接收来自源进程的报文， 并根据所述报文中的源进程地址、 目标进程 地址和本地存储的路由分发信息将所述报文写入目标进程对应的目标共享队 列， 其中， 所述报文中包括源进程地址和目标进程地址； 至少一个进程组件 82, 用于根据所述目标共享队列获取所述报文。 当然， 对于运行有多个进程的系统， 则相应的包括多个进程组件。
相应的， 若通信装置用于报文的发送时， 该装置 （未图示） 包括： 至少一 个进程组件， 用于将报文写入与所述进程组件对应的源共享队列， 所述报文包 括源进程地址和目标进程地址； 可编程硬件组件， 用于从所述源共享队列中获 取所述 ^艮文， 并根据所述 4艮文中的源进程地址、 目标进程地址和本地存储的路 由分发信息对所述报文进行转发。
其中，如图 10所示，本发明实施例中提供的用于分布式多进程通信的装置， 可包括可编程硬件组件 80, 该可编程硬件组件 80可包括： 接收模块 800, 用于 接收来自源进程的 艮文， 其中， 所述 4艮文中包括源进程地址和目标进程地址； 写入模块 802, 用于根据所述报文中的源进程地址、 目标进程地址和本地存储的 路由分发信息将所述报文写入目标进程对应的目标共享队列， 使所述目标进程 根据所述目标共享队列获取所述报文。
若， 将报文分为内核态处理报文和用户态处理报文， 则可编程硬件組件 80 可进一步包括（图 10中虚线所示）： 识别模块 804, 用于识别所述报文类型， 所 述"¾文类型包括用户态类型和内核态类型； 相应的， 所述写入模块 802还用于 根据所述报文中的源进程地址、 目标进程地址和本地存储的路由分发信息将所 述用户态类型报文写入与所述目标进程对应的用户进程共享队列， 将所述内核 态类型报文写入与内核态驱动组件对应的内核共享队列。
当然， 若所述报文包括单播报文、 多播报文和广播报文， 所述路由分发信 息中存储有所述单播报文的目的进程信息、 所述多播报文的多个目的进程信息； 则所述识别模块 804还用于识别所述报文为多播报文； 所述写入模块 802还用 于根据所述多播报文的多个目的进程信息对所述多播报文进行复制， 并将复制 获得的多个所述多播报文放入对应的目标共享队列中。
当分布式多进程通信的装置用于源进程的报文转发时， 其包括的可编程硬 件组件 （未图示） 可包括获取模块， 用于从所述源共享队列中获取报文， 所述 报文是源进程写入与所述源进程对应的源共享队列， 且所述报文包括源进程地 址和目标进程地址； 转发模块， 用于根据所述报文中的源进程地址、 目标进程 地址和本地存储的路由分发信息对所述报文进行转发。
当 艮文类型包括用户态类型和内核态类型， 相应的， 如图 11所示， 该进程 组件 82可包括： 用户态驱动组件 820 , 用于从所述用户进程共享队列获取用户 态类型报文并转发给用户态类型报文处理模块 822; 用户态类型报文处理模块 822, 用于接收所述用户态类型报文， 并进行报文解析处理； 内核态类型报文处 理模块 824, 用于接收内核态驱动组件 84从所述内核共享队列获取后发送来的 内核态类型报文， 并进行报文解析处理。
相应的， 所述装置 8还包括内核态驱动组件 84， 用于从所述内核共享队列 获取的所述内核态类型报文， 并将所述内核态类型报文发送至所述内核态报文 处理模块。
同样的， 当可编程硬件组件进行源进程的报文转发时， 则所述用户态驱动 组件 82还用于将用户态类型 · ^文写入与所述可编程硬件組件共享的用户进程共 享队列； 所述内核态类型报文处理模块 824还用于将内核态类型报文发送至所 述内核态驱动组件； 所述内核态驱动组件 84还用于获取并将所述内核态类型报 文写入与所述可编程硬件组件共享的内核共享队列； 所述可编程硬件組件 80还 用于从所述用户进程共享队列和所述内核共享队列获取相应的报文， 将根据本 地存储的路由分发信息对所述报文进行转发。
上述装置中的各术语和功能与前述方法实施例中的类似， 此处不做赞述。 如图 12所示， 为本发明实施例中的通信装置的另一个具体组成示意图。 本 例中， 该装置采用 Linux操作系统， FPGA逻辑组件通过 XAUI接口收发以太网 报文。
该装置由位于 Linux内核态的内核态驱动组件 Gll、位于 Linux用户态的用 户态驱动组件 G15 , Linux操作系统协议栈 G12以及 FPGA逻辑组件 G20组成。 运行于 Linux系统中的进程通过自己的用户态驱动组件处理 IPC和 UIP报 文， 通过 Linux协议栈处理 TCP报文。 每个进程管理自己在用户态的软件共享 内存区 G18 , FPGA逻辑管理自己的硬件共享内存 G22。 这样， 硬件 FPGA接 收到报文后用自己管理的内存， 用户进程发送报文的时候用自己的内存， 可以 实现各自管理自己的内存， 各自管理自己的内存具有简单、 交互少、 效率高等 优点。
用户态驱动组件 G15和 PGA逻辑组件 G20之间通过用户进程共享队列 G16 接收和发送报文。 对应于前述的报文处理流程， 本例中的处理步驟如下。
All : Linux操作系统启动后装入内核态驱动组件（即虛拟网卡驱动） G11 , 映射用户进程共享队列 G16、 软件共享内存 G18和硬件共享内存 G22。 同时将 FPGA操作的寄存器地址映射到用户态， 建立用户态驱动组件 G15的程序环境。
这是由于， 在 Linux 下进程采用虚拟内存机制， 用户进程要从 FPGA中读 取报文就需要一个队列， 该队列中存储的是报文的地址不是内容。 即需要将共 享队列 G16的地址映射到进程自己的虚拟地址空间中。 这里是 G18、 G22这块 内存用来存储报文内容的。 为了处理效率分成两个物理内存区。 这里需要注意 的是所有 Linux进程映射这两块空间的虚拟地址是一样的，这样进程之间通信不 会产生访问异常。 而 FPGA使用的是物理地址， 用户态进程使用的是虚拟地址， 这个工作由用户态驱动来转换。同时，由于 Linux内核态与用户态之间是隔离的， 只有 Linux态运行在特权级别可以访问芯片的物理寄存器。用户态进程没有特权 无法访问， 但是用户态进程通过把寄存器的地址映射到用户空间使得用户态代 码可以直接访问硬件寄存器。
A12: 用户进程启动后， 初始化映射用户进程共享队列、 软件共享内存区和 硬件共享内存区的地址空间。 用户进程通过 TCP通信模块 G13连接操作维护中 心， 下载进程节点配置关系。 最后将本进程的地址信息写入路由分发表 G21中。
A13 : 来自 XAUI口的以太网报文由 FPGA逻辑组件 G20接收处理， 根据 路由分发表 G21 中配置的信息， 分析接收到的以太网报文。 如果为 IPC或 UIP 报文则写入用户进程共享队列 G16中， 由用户态驱动组件 G15接收， 最后交给 UIP处理模块 G14和 IPC处理模块 G17。 对于其他类型报文写入网卡接收队列 (即内核共享队列） G19中， 由网卡驱动 G11查询到后交给 Linux协议栈 G12 处理， 再通过 SOCKET接口交给进程的 TCP通信模块 G13接收。
A14:用户态进程 UIP处理模块 G14和 IPC处理模块 G17需要发送报文时， 从共享内存 G18申请空间，由用户态驱动 G15写入进程发送队列 G16中。 FPGA 逻辑组件 G20查询到用户进程报文后从进程发送队列 G16中获取报文并发送到 XAUI接口。 对于 TCP发送报文通过 TCP通信模块 G13建立的 SOCKET接口 发送到 Linux内核协议栈 G12, 再调用内核态驱动组件 G11的发送函数写入网 卡发送队列 （即内核共享队列） G19, 最后由 FPGA逻辑组件 G20查询到后发 送到 XAUI接口。
其中， PGA逻辑组件 G20需要接收来自 XAUI接口的报文时候， 从硬件共 享内存区 G22申请内存； FPGA逻辑组件 G20释放内存时候， 将内存归还到硬 件共享内存区。用户态进程组件 G15需要发送报文时候，从软件共享内存区 G18 分配内存； 用户态进程 G15释放内存时候， 将内存归还到软件共享内存区。
当 FPGA逻辑组件需要释放来自用户态进程产生的报文时候， 构造一条报 文释放消息写入到用户进程共享队列 G16中。 当用户态驱动组件 G15查询到该 条释放消息后， 将报文内存释放到软件内存共享区 G18。 当用户进程需要释放 来自 FPGA逻辑组件接收的报文时候， 构造一条报文释放消息写入到用户进程 发送队列 G16中。 当 FPGA逻辑查询到该条释放消息后， 将报文内存释放到硬 件共享内存区 G22中。
当内核态驱动 G11需要申请 FPGA逻辑的硬件内存时候， 从网卡緩存队列 当内核态驱动 G11需要释放 FPGA逻辑的硬件内存时候， 构造一条报文释放消 息写入到网卡发送队列 G16中。 当 FPGA逻辑查询到该条释放消息后， 将报文 内存释放到硬件共享内存区 G22中。
在本发明实施例中， 设置可编程硬件組件根据本地路由分发信息进行进程 间报文的转发， 可以通过灵活的配置路由分发信息来实现对特定进程报文的接 收、 屏蔽不想要的垃圾报文， 同时采用目标共享队列交互报文， 实现了内存零 拷贝， 减少了系统调用， 减少了 CPU的占有率。 进一步的， 将报文分为用户态 处理和内核态处理， 有效利用了用户态驱动容易进行在线升级、 容易管理的优 势。
采用可编程硬件组件管理硬件内存， 用户态进程管理软件内存（ 即可编程 硬件组件接收后的报文要写入内存， 该块内存的申请释放由可编程硬件组件管 理， 所以这片内存叫硬件内存， 同样进程管理的那片内存叫软件内存）。， 各自 管理自己的内存区， 互不影响。 有效地解决了用户进程和可编程硬件组件竟争 内存资源的互锁问题。 使用不同单板的路由转发表的机制可以很容易实现主备 进程倒换， N+1备份方式以及进程迁移。
本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程， 是可以通过计算机程序来指令相关的硬件来完成， 所述的程序可存储于一计算 机可读取存储介质中， 该程序在执行时， 可包括如上述各方法的实施例的流程。 其中， 所述的存储介质可为磁碟、 光盘、 只读存储记忆体（Read-Only Memory, ROM ) 或随机存储记忆体（Random Access Memory, RAM ) 等。
以上所揭露的仅为本发明一种较佳实施例而已， 当然不能以此来限定本发 明之权利范围， 因此依本发明权利要求所作的等同变化， 仍属本发明所涵盖的 范围。

Claims

权 利 要 求
1、 一种分布式多进程通信方法， 其特征在于， 所述方法包括：
可编程硬件组件接收来自源进程的报文， 所述报文中包括源进程地址和目 标进程地址；
所述可编程硬件组件根据所述 4艮文中的源进程地址、 目标进程地址和本地 存储的路由分发信息将所述报文写入目标进程对应的目标共享队列， 使所述目 标进程根据所述目标共享队列获取所述报文。
2、 如权利要求 1所述的分布式多进程通信方法， 其特征在于， 所述可编程 硬件组件根据路由分发信息将所述报文写入目标共享队列包括：
所述可编程硬件组件识别所述 文类型 , 所述 4艮文类型包括用户态类型和 内核态类型；
所述可编程硬件组件根据所述> ^文中的源进程地址、 目标进程地址和本地 存储的路由分发信息将所述用户态类型报文写入与所述目标进程对应的用户进 程共享队列， 将所述内核态类型报文写入与内核态驱动组件对应的内核共享队 列。
3、 如权利要求 1所述的分布式多进程通信方法， 其特征在于， 所述可编程 硬件组件根据路由分发信息将所述报文写入目标共享队列包括：
所述可编程硬件组件根据所述> ^文中的源进程地址、 目标进程地址和本地 存储的路由分发信息将所述报文写入与内核态驱动組件对应的内核共享队列； 所述内核态驱动组件获取所述内核共享队列的报文， 并将所述报文发送至 Linu 协议栈；
所述 Linux协议栈将报文写入 SOCKET接收緩冲区， 以便所述目标进程从 所述 SOCKET接收緩冲区中获得所述报文。
4、 如权利要求 2所述的分布式多进程通信方法， 其特征在于， 使所述目标 进程根据所述目标共享队列获取所述报文包括： 使所述目标进程中的用户态驱 动组件从所述用户进程共享队列获取所述用户态类型报文并转发给所述目标进 程中的用户态类型报文处理模块进行报文解析处理；
所述内核态驱动组件从所述内核共享队列获取所述内核态类型报文， 并将 所述内核态类型报文发送给所述目标进程， 使所述目标进程中的内核态类型报 文处理模块接收并进行报文解析处理。
5、如权利要求 1至 4中任一项所述的分布式多进程通信方法，其特征在于， 所述用户态类型报文包括进程间通讯报文和 /或用户数据报文， 所述内核态类型 报文包括 TCP报文、 ARP报文、 ICMP报文中的一种或多种。
6、如权利要求 1至 5中任一项所述的分布式多进程通信方法，其特征在于， 所述报文包括单播报文、 多播报文和广播报文， 所述路由分发信息中存储有所 述单播报文的目的进程信息、 所述多播报文的多个目的进程信息。
7、 如权利要求 6所述的分布式多进程通信方法， 其特征在于， 所述方法还 包括：
所述硬件逻辑组件识别所述报文为多播报文， 根据所述多播报文的多个目 的进程信息对所述多播报文进行复制；
将复制获得的多个所述多播报文放入对应的目标共享队列中。
8、 如权利要求 1至 7中任一项所述分布式多进程通信方法， 其特征在于， 所述目标进程包括主用进程和备用进程， 当进行主备进程切换时， 将所述路由 分发信息中的主用进程地址对应为备用进程地址， 或将备用进程地址对应为主 用进程地址。
9、 一种分布式多进程通信方法， 其特征在于， 所述方法包括：
可编程硬件组件从源共享队列中获取报文， 所述报文是源进程写入与所述 源进程对应的源共享队列的报文， 且所述 4艮文包括源进程地址和目标进程地址； 可编程硬件组件根据所述报文中的源进程地址、 目标进程地址和本地存储 的路由分发信息对所述报文进行转发。
10、 如权利要求 9所述的分布式多进程通信方法， 其特征在于， 所述报文 类型包括用户态类型和内核态类型， 所述方法还包括：
所述源进程将用户态类型报文发送给所述源进程对应的用户进程共享队 列；
所述源进程将内核态类型报文发送给所述源进程对应的内核态驱动组件， 所述内核态驱动组件将所述内核态类型报文写入与源进程对应的内核共享队 列。
11、 如权利要求 9至 10中任一项所述的分布式多进程通信方法， 其特征在 于， 所述用户态类型报文包括进程间通讯报文和 /或用户数据报文， 所述内核态 类型报文包括 TCP报文、 ARP报文、 ICMP报文中的一种或多种。
12、 一种用于分布式多进程通信的装置， 包含可编程硬件组件， 其特征在 于， 所述可编程硬件组件包括：
接收模块， 用于接收来自源进程的报文， 其中， 所述报文中包括源进程地 址和目标进程地址；
写入模块， 用于根据所述报文中的源进程地址、 目标进程地址和本地存储 的路由分发信息将所述报文写入目标进程对应的目标共享队列， 使所述目标进 程根据所述目标共享队列获取所述报文。
13、如权利要求 12所述的装置， 其特征在于， 所述可编程硬件组件还包括： 识别模块， 用于识别所述报文类型， 所述报文类型包括用户态类型和内核 态类型；
所述写入模块还用于根据所述 · ^文中的源进程地址、 目标进程地址和本地 存储的路由分发信息将所述用户态类型报文写入与所述目标进程对应的用户进 程共享队列， 将所述内核态类型报文写入与内核态驱动组件对应的内核共享队 列。
14、 如权利要求 12至 13 中任一项中所述的装置， 其特征在于， 所述报文 包括单播报文、 多播报文和广播报文， 所述路由分发信息中存储有所述单播报 文的目的进程信息、 所述多播报文的多个目的进程信息；
所述识别模块还用于识别所述报文为多播报文；
所述写入模块还用于根据所述多播报文的多个目的进程信息对所述多播报 文进行复制， 并将复制获得的多个所述多播报文放入对应的目标共享队列中。
15、 如权利要求 12至 14中任一项所述的装置， 其特征在于， 所述可编程 硬件组件还包括获取模块， 所述获取模块用于从源共享队列中获取报文， 并根 据所述报文中的源进程地址、 目标进程地址和本地存储的路由分发信息对所述 艮文进行转发；
其中， 所述报文为所述源进程写入的与所述源进程对应的源共享队列的报 文， 所述报文中包括源进程地址和目标进程地址。
16、 如权利要求 12或 15 中任一项所述的装置， 其特征在于， 所述用户态 类型报文包括进程间通讯报文和 /或用户数据报文， 所述内核态类型报文包括 TCP报文、 ARP报文、 ICMP报文中的一种或多种。
17、 一种用于分布式多进程通信的装置， 包含可编程硬件组件， 其特征在 于， 所述可编程硬件组件包括：
获取模块， 用于从所述源共享队列中获取报文， 所述报文是源进程写入与 所述源进程对应的源共享队列， 且所述 · ^文包括源进程地址和目标进程地址； 转发模块， 用于根据所述报文中的源进程地址、 目标进程地址和本地存储 的路由分发信息对所述报文进行转发。
18、 一种通信装置， 可进行分布式多进程通信， 其特征在于， 所述装置包 括：
可编程硬件组件， 用于接收来自源进程的报文， 并根据所述报文中的源进 程地址、 目标进程地址和本地存储的路由分发信息将所述报文写入目标进程对 应的目标共享队列， 其中， 所述 ^文中包括源进程地址和目标进程地址；
至少一个进程组件， 用于根据所述目标共享队列获取所述报文。
19、 如权利要求 18所述的通信装置， 其特征在于， 所述报文类型包括用户 态类型和内核态类型， 所述进程组件包括：
用户态驱动组件， 用于从所述用户进程共享队列获取用户态类型报文并转 发给用户态类型报文处理模块；
用户态类型报文处理模块， 用于接收所述用户态类型报文， 并进行报文解 析处理；
内核态类型报文处理模块， 用于接收内核态驱动组件从所述内核共享队列 获取后发送来的内核态类型报文， 并进行报文解析处理；
相应的， 所述装置还包括内核态驱动组件， 用于从所述内核共享队列获取 的所述内核态类型 4艮文， 并将所述内核态类型 4艮文发送至所述内核态 文处理 模块。
20、 如权利要求 18所述的通信装置， 其特征在于，
所述用户态驱动组件还用于将用户态类型 4艮文写入与所述可编程硬件组件 共享的用户进程共享队列；
所述内核态类型报文处理模块还用于将内核态类型报文发送至所述内核态 驱动组件；
所述内核态驱动组件还用于获取并将所述内核态类型报文写入与所述可编 程硬件组件共享的内核共享队列；
所述可编程硬件组件还用于从所述用户进程共享队列和所述内核共享队列 获取相应的报文， 将根据本地存储的路由分发信息对所述报文进行转发。
21、 一种通信装置， 可进行分布式多进程通信， 其特征在于， 所述装置包 括：
至少一个进程组件， 用于将报文写入与所述进程组件对应的源共享队列， 所述报文包括源进程地址和目标进程地址；
可编程硬件组件， 用于从所述源共享队列中获取所述报文， 并根据所述报 文中的源进程地址、 目标进程地址和本地存储的路由分发信息对所述报文进行 转发。
22、 如权利要求 21所述的通信装置， 其特征在于， 所述报文类型包括用户 态类型和内核态类型， 所述进程组件将 "^文写入与所述进程组件对应的源共享 队列包括：
所述进程组件将用户态类型报文发送给所述进程组件对应的用户进程共享 队列；
所述进程组件将将内核态类型报文发送给所述进程组件对应的内核态驱动 组件， 所述内核态驱动组件将所述内核态类型报文写入与所述进程组件对应的 内核共享队列。
PCT/CN2011/076529 2011-06-28 2011-06-28 一种分布式多进程通信方法和装置 WO2012159305A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
PCT/CN2011/076529 WO2012159305A1 (zh) 2011-06-28 2011-06-28 一种分布式多进程通信方法和装置
CN201180001507.3A CN102971723B (zh) 2011-06-28 一种分布式多进程通信方法和装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2011/076529 WO2012159305A1 (zh) 2011-06-28 2011-06-28 一种分布式多进程通信方法和装置

Publications (1)

Publication Number Publication Date
WO2012159305A1 true WO2012159305A1 (zh) 2012-11-29

Family

ID=47216550

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2011/076529 WO2012159305A1 (zh) 2011-06-28 2011-06-28 一种分布式多进程通信方法和装置

Country Status (1)

Country Link
WO (1) WO2012159305A1 (zh)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107133109A (zh) * 2017-04-24 2017-09-05 京信通信系统（广州）有限公司 一种模块间通信的方法、装置及计算设备
CN108628684A (zh) * 2017-03-20 2018-10-09 华为技术有限公司 一种基于dpdk的报文处理方法及计算机设备
CN109002350A (zh) * 2018-05-23 2018-12-14 中国石油天然气集团有限公司 一种集群系统中的进程通信方法及装置
CN109491804A (zh) * 2018-10-11 2019-03-19 视联动力信息技术股份有限公司 消息传输方法和装置
CN112118167A (zh) * 2020-08-17 2020-12-22 深圳市风云实业有限公司 一种跨网隧道数据快速传输方法

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1949206A (zh) * 2005-10-12 2007-04-18 大唐移动通信设备有限公司 多处理器系统的消息通信方法及装置
CN101127685A (zh) * 2007-09-20 2008-02-20 中兴通讯股份有限公司 一种进程间通讯装置及其进程间通讯方法
US20090086737A1 (en) * 2007-09-29 2009-04-02 Applied Micro Circuits Corporation System-on-chip communication manager
CN101448018A (zh) * 2008-12-26 2009-06-03 中兴通讯股份有限公司 进程间通信方法和装置

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1949206A (zh) * 2005-10-12 2007-04-18 大唐移动通信设备有限公司 多处理器系统的消息通信方法及装置
CN101127685A (zh) * 2007-09-20 2008-02-20 中兴通讯股份有限公司 一种进程间通讯装置及其进程间通讯方法
US20090086737A1 (en) * 2007-09-29 2009-04-02 Applied Micro Circuits Corporation System-on-chip communication manager
CN101448018A (zh) * 2008-12-26 2009-06-03 中兴通讯股份有限公司 进程间通信方法和装置

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108628684A (zh) * 2017-03-20 2018-10-09 华为技术有限公司 一种基于dpdk的报文处理方法及计算机设备
CN108628684B (zh) * 2017-03-20 2021-01-05 华为技术有限公司 一种基于dpdk的报文处理方法及计算机设备
CN107133109A (zh) * 2017-04-24 2017-09-05 京信通信系统（广州）有限公司 一种模块间通信的方法、装置及计算设备
CN107133109B (zh) * 2017-04-24 2020-01-14 京信通信系统（中国）有限公司 一种模块间通信的方法、装置及计算设备
CN109002350A (zh) * 2018-05-23 2018-12-14 中国石油天然气集团有限公司 一种集群系统中的进程通信方法及装置
CN109002350B (zh) * 2018-05-23 2021-08-03 中国石油天然气集团有限公司 一种集群系统中的进程通信方法及装置
CN109491804A (zh) * 2018-10-11 2019-03-19 视联动力信息技术股份有限公司 消息传输方法和装置
CN112118167A (zh) * 2020-08-17 2020-12-22 深圳市风云实业有限公司 一种跨网隧道数据快速传输方法
CN112118167B (zh) * 2020-08-17 2022-04-12 深圳市风云实业有限公司 一种跨网隧道数据快速传输方法

Also Published As

Publication number Publication date
CN102971723A (zh) 2013-03-13

Similar Documents

Publication Publication Date Title
US20220214919A1 (en) System and method for facilitating efficient load balancing in a network interface controller (nic)
US7937447B1 (en) Communication between computer systems over an input/output (I/O) bus
TWI458307B (zh) 管理網路資訊處理的系統和方法
US7996569B2 (en) Method and system for zero copy in a virtualized network environment
CA2904053C (en) Medical device communication method
US7817634B2 (en) Network with a constrained usage model supporting remote direct memory access
CN108270676B (zh) 一种基于Intel DPDK的网络数据处理方法及装置
CN112291293B (zh) 任务处理方法、相关设备及计算机存储介质
WO2014206105A1 (zh) 虚拟交换方法、相关装置和计算机系统
US10609125B2 (en) Method and system for transmitting communication data
WO2015081734A1 (zh) 一种在VxLAN中发送ARP报文发送方法、VTEP及VxLAN控制器
JP2008535342A (ja) オペレーティング・システム・パーティションのためのネットワーク通信
WO2012159305A1 (zh) 一种分布式多进程通信方法和装置
US8976789B2 (en) Communication transport protocol for distributed information technology architectures
CN103200085A (zh) 一种实现vxlan报文线速收发的方法及系统
WO2015027738A1 (zh) 一种传输、接收元数据的方法、开放流逻辑交换机
WO2023109891A1 (zh) 组播传输方法、装置和系统
CN111212061B (zh) 基于afdx的套接字的实现方法
CN101262425A (zh) 基于网络地址转换的多播转发的方法
WO2022160714A1 (zh) 一种通信方法、装置以及系统
WO2021027047A1 (zh) 异构链路数据转译和分发方法、系统、设备和存储介质
US20230403229A1 (en) System and method for facilitating efficient host memory access from a network interface controller (nic)
CN116760504B (zh) 会话同步方法、装置、服务节点、终端及可读存储介质
CN102971723B (zh) 一种分布式多进程通信方法和装置
Feng et al. Implementation and Real-Time Optimization of Lwip Stack Based on AM3354 UCOS-II

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 201180001507.3

Country of ref document: CN

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 11866013

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 11866013

Country of ref document: EP

Kind code of ref document: A1