CN112883007A - Native protocol message processing method and device for Linux system - Google Patents

Native protocol message processing method and device for Linux system Download PDF

Info

Publication number
CN112883007A
CN112883007A CN202110193646.6A CN202110193646A CN112883007A CN 112883007 A CN112883007 A CN 112883007A CN 202110193646 A CN202110193646 A CN 202110193646A CN 112883007 A CN112883007 A CN 112883007A
Authority
CN
China
Prior art keywords
processing
kernel
mode
protocol stack
native
Prior art date
Legal status (The legal status 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 status listed.)
Pending
Application number
CN202110193646.6A
Other languages
Chinese (zh)
Inventor
刘昊
王晨
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hangzhou DPTech Technologies Co Ltd
Original Assignee
Hangzhou DPTech Technologies Co Ltd
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 Hangzhou DPTech Technologies Co Ltd filed Critical Hangzhou DPTech Technologies Co Ltd
Priority to CN202110193646.6A priority Critical patent/CN112883007A/en
Publication of CN112883007A publication Critical patent/CN112883007A/en
Pending legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10File systems; File servers
    • G06F16/18File system types
    • G06F16/188Virtual file systems
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F5/00Methods or arrangements for data conversion without changing the order or content of the data handled
    • G06F5/06Methods or arrangements for data conversion without changing the order or content of the data handled for changing the speed of data flow, i.e. speed regularising or timing, e.g. delay lines, FIFO buffers; over- or underrun control therefor
    • G06F5/065Partitioned buffers, e.g. allowing multiple independent queues, bidirectional FIFO's

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

The present disclosure relates to a processing, an apparatus, an electronic device and a computer readable medium of native protocol packets for a Linux system. The method comprises the following steps: acquiring a local protocol message when the hardware of the Linux system runs in a user mode; judging the application scene of the native protocol message; when the application scene is a real-time scene, forwarding the native protocol packet to a user mode protocol stack for processing; and when the application scene is a non-real-time scene, forwarding the native protocol packet to a kernel-mode protocol stack for processing. The processing method, the processing device, the electronic equipment and the computer readable medium for the native protocol message can select the mode for processing the native protocol message according to specific application scenes, meet the efficiency requirements of different scenes, and realize the interaction of a user mode and a kernel protocol stack message.

Description

Native protocol message processing method and device for Linux system
Technical Field
The present disclosure relates to the field of computer information processing, and in particular, to a method and an apparatus for processing native protocol packets, an electronic device, and a computer-readable medium.
Background
With the development of information technology, linux systems are widely applied in the field of communication. In order to meet the requirements of privileged instructions such as system performance and I/O instructions, a conventional Linux device driver model often operates in the same address space as an operating system kernel and has all the permissions of the kernel. The operating system is unconditionally trusted with code running in kernel mode, so a small error in the device driver will also cause a system-wide failure. In addition, kernel driver programming is subject to strict limitations, and tools for driver development, debugging and testing are deficient, so that reliability of drivers is difficult to guarantee. So user-state driven programming has become a trend, more and more switch chip vendors migrate their own SDKs (software development kits) to user states.
At present, the commonly used SDKs are all developed based on the driving of the user mode, so that the sending and receiving packets of the SDKs are all migrated to the user mode. The former SDK receiving and sending packets are completed by kernel mode drive, and the messages can directly interact with the kernel protocol stack in the kernel mode space. However, in a practical application scenario of hardware, some protocol packets that need to be processed by a kernel protocol stack still exist, and cannot be processed in a current interaction state.
The above information disclosed in this background section is only for enhancement of understanding of the background of the disclosure and therefore it may contain information that does not constitute prior art that is already known to a person of ordinary skill in the art.
Disclosure of Invention
In view of this, the present disclosure provides a method and an apparatus for processing native protocol packets, an electronic device, and a computer readable medium, which can select a method for processing native protocol packets according to a specific application scenario, meet efficiency requirements of different scenarios, and implement interaction between a user mode and a kernel protocol stack packet.
Additional features and advantages of the disclosure will be set forth in the detailed description which follows, or in part will be obvious from the description, or may be learned by practice of the disclosure.
According to an aspect of the present disclosure, a method for processing a native protocol packet is provided, where the method includes: acquiring a local protocol message when the hardware of the Linux system runs in a user mode; judging the application scene of the native protocol message; when the application scene is a real-time scene, forwarding the native protocol packet to a user mode protocol stack for processing; and when the application scene is a non-real-time scene, forwarding the native protocol packet to a kernel-mode protocol stack for processing.
In an exemplary embodiment of the present disclosure, further comprising: and creating a virtual file system in a kernel mode of the Linux system to realize the read-write operation of the hardware.
In an exemplary embodiment of the present disclosure, further comprising: and creating a socket cache chain for storing the message sent by the kernel mode protocol stack.
In an exemplary embodiment of the present disclosure, forwarding the native protocol packet to a kernel-mode protocol stack for processing includes: the user state driver acquires the native protocol message; sending the native protocol message to the kernel mode protocol stack to generate a processing result; and the user state driver acquires the processing result and sends the processing result to a Linux system.
In an exemplary embodiment of the present disclosure, sending the native protocol packet to the kernel-mode protocol stack includes: and forwarding the native protocol packet to a kernel-mode protocol stack for processing based on the write operation of the virtual file system.
In an exemplary embodiment of the present disclosure, sending the native protocol packet to the kernel-mode protocol stack to generate a processing result includes: sending the native protocol message to the kernel-mode protocol stack; and the kernel mode protocol stack processes the native protocol message to generate a processing result.
In an exemplary embodiment of the present disclosure, the obtaining, by the user state driver, the processing result and sending the processing result to a Linux system includes: the kernel mode protocol stack adds a processing result to the tail of the socket cache chain; the user state driver reads the processing result by the socket cache chain; and the user state driver sends the processing result to a Linux system.
In an exemplary embodiment of the present disclosure, the adding, by the kernel-mode protocol stack, the processing result to the tail of the socket cache chain further includes: and awakening the queue head of the socket cache chain.
In an exemplary embodiment of the disclosure, the user-state driving reading the processing result by the socket cache chain includes: the user state drives to create a thread; and performing a read operation on the socket cache chain in a blocking mode based on the thread to obtain the processing result.
In an exemplary embodiment of the present disclosure, performing a read operation on the socket cache chain in a blocking manner based on the thread to obtain the processing result includes: when the socket cache chain is not empty, the thread reads the processing result; and when the socket cache chain is empty, the thread is in a dormant state.
According to an aspect of the present disclosure, an apparatus for processing a native protocol packet is provided, the apparatus including: the acquisition module is used for acquiring a local protocol message when the hardware of the Linux system operates in a user mode; the judging module is used for judging the application scene of the native protocol message; the user mode module is used for forwarding the native protocol message to a user mode protocol stack for processing when the application scene is a real-time scene; and the kernel mode module is used for forwarding the native protocol packet to a kernel mode protocol stack for processing when the application scene is a non-real-time scene.
In an exemplary embodiment of the present disclosure, further comprising: the creating module is used for creating a virtual file system in a kernel mode of the Linux system so as to realize the read-write operation of the hardware; and the method is also used for creating a socket cache chain and storing the messages sent by the kernel mode protocol stack.
According to an aspect of the present disclosure, an electronic device is provided, the electronic device including: one or more processors; storage means for storing one or more programs; when executed by one or more processors, cause the one or more processors to implement a method as above.
According to an aspect of the disclosure, a computer-readable medium is proposed, on which a computer program is stored, which program, when being executed by a processor, carries out the method as above.
According to the local protocol message processing method, the local protocol message processing device, the electronic equipment and the computer readable medium, when the hardware of the Linux system runs in a user mode, the local protocol message is obtained; judging the application scene of the native protocol message; when the application scene is a real-time scene, forwarding the native protocol packet to a user mode protocol stack for processing; when the application scene is a non-real-time scene, the local protocol packet is forwarded to the kernel-mode protocol stack for processing, the local packet processing mode can be selected according to the specific application scene, the efficiency requirements of different scenes are met, and the interaction between the user mode and the kernel protocol stack packet can be realized.
It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the disclosure.
Drawings
The above and other objects, features and advantages of the present disclosure will become more apparent by describing in detail exemplary embodiments thereof with reference to the attached drawings. The drawings described below are merely some embodiments of the present disclosure, and other drawings may be derived from those drawings by those of ordinary skill in the art without inventive effort.
Fig. 1 is a flowchart illustrating a method for processing native protocol packets according to an example embodiment.
Fig. 2 is a schematic diagram illustrating a method and an apparatus for processing a native protocol packet according to an exemplary embodiment.
Fig. 3 is a flowchart illustrating a method for processing native protocol packets according to another example embodiment.
Fig. 4 is a block diagram illustrating an apparatus for processing native protocol messages in accordance with an example embodiment.
FIG. 5 is a block diagram illustrating an electronic device in accordance with an example embodiment.
FIG. 6 is a block diagram illustrating a computer-readable medium in accordance with an example embodiment.
Detailed Description
Example embodiments will now be described more fully with reference to the accompanying drawings. Example embodiments may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the concept of example embodiments to those skilled in the art. The same reference numerals denote the same or similar parts in the drawings, and thus, a repetitive description thereof will be omitted.
Furthermore, the described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments. In the following description, numerous specific details are provided to give a thorough understanding of embodiments of the disclosure. One skilled in the relevant art will recognize, however, that the subject matter of the present disclosure can be practiced without one or more of the specific details, or with other methods, components, devices, steps, and so forth. In other instances, well-known methods, devices, implementations, or operations have not been shown or described in detail to avoid obscuring aspects of the disclosure.
The block diagrams shown in the figures are functional entities only and do not necessarily correspond to physically separate entities. I.e. these functional entities may be implemented in the form of software, or in one or more hardware modules or integrated circuits, or in different networks and/or processor means and/or microcontroller means.
The flow charts shown in the drawings are merely illustrative and do not necessarily include all of the contents and operations/steps, nor do they necessarily have to be performed in the order described. For example, some operations/steps may be decomposed, and some operations/steps may be combined or partially combined, so that the actual execution sequence may be changed according to the actual situation.
It will be understood that, although the terms first, second, third, etc. may be used herein to describe various components, these components should not be limited by these terms. These terms are used to distinguish one element from another. Thus, a first component discussed below may be termed a second component without departing from the teachings of the disclosed concept. As used herein, the term "and/or" includes any and all combinations of one or more of the associated listed items.
It is to be understood by those skilled in the art that the drawings are merely schematic representations of exemplary embodiments, and that the blocks or processes shown in the drawings are not necessarily required to practice the present disclosure and are, therefore, not intended to limit the scope of the present disclosure.
The technical abbreviations involved in this disclosure are explained as follows:
waiting for the queue: the waiting queue refers to a queue formed by processes in the linux system, and is a process which needs other events to be woken up, that is, the processes wait for other processes to provide conditions for the processes to occur. They are consumers, but what they want to consume has not yet been generated, these are processes in wait state, which constitute a wait queue.
SKB the Linux network core data structure is socket buffer (SKB for short). It represents a message to be sent or processed and runs through the entire protocol stack.
The SDK is a software development kit, which is generally a collection of development tools used by some software engineers to build application software for a specific software package, software framework, hardware platform, operating system, and the like. A software development tool broadly refers to a collection of related documents, paradigms, and tools that assist in developing a certain class of software.
In the existing processing scheme, the protocol message transceiving processing of the local machine is a standard kernel-mode protocol message transceiving processing flow, and the protocol message transceiving processing is completed in the kernel mode as follows:
(1) local protocol message receiving: after the driver receives the message through the hardware, whether the message is a native protocol message is judged according to the two-layer header of the message, and if the message is the native protocol message, the message is directly uploaded to a kernel state protocol stack for processing.
(2) Local protocol message sending: the kernel mode protocol stack sends the message to a driver for processing, and the driver sends the message out through hardware.
For the native protocol message, if the hardware receives the message and then directly sends the message to the kernel state driver for processing, then the message is sent to the kernel state protocol stack, which is a standard general processing flow. However, some manufacturers' SDKs are submitted to the user mode after receiving the message through hardware, and the native message received by the user mode cannot be directly submitted to the kernel mode protocol stack for processing. Moreover, after the kernel mode protocol stack sends the packet, the message also needs to be sent out through the user mode.
In order to solve the dilemma in the prior art, the present disclosure provides a method for processing a native protocol packet, and the method of the present disclosure is described in detail below with reference to specific embodiments.
Fig. 1 is a flowchart illustrating a method for processing native protocol packets according to an example embodiment. The method 10 for processing native protocol packets at least includes steps S102 to S108.
As shown in fig. 1, in S102, the hardware of the Linux system obtains the native protocol packet when operating in the user mode. Because of the need to limit the accessibility between different programs, preventing them from acquiring memory data of other programs, or acquiring data of peripheral devices, and sending them to the network, the CPU divides two levels of permissions: user mode and kernel mode.
Macroscopically, the kernel of the Linux operating system is essentially software: controls the hardware resources of the computer and provides an environment for upper-layer application programs to run. The user mode is the activity space of the upper application program, and the execution of the application program must depend on the resources provided by the kernel, including CPU resources, storage resources, I/O resources and the like. In order for upper layer applications to access these resources, the kernel must provide an interface for upper layer applications to access: i.e. a system call.
In S104, an application scenario of the native protocol packet is determined. The application scene of the message can be judged according to the message data in the native protocol message.
In S106, when the application scenario is a real-time scenario, the native protocol packet is forwarded to a user mode protocol stack for processing. For example, messages processed by video stream data and voice stream data belong to real-time scene type messages, and need to be processed by a user mode protocol stack.
The user mode protocol stack in the present disclosure may be a new type of user mode protocol stack that meets the standard of message transmission and reception, and in the new type of user mode protocol stack, the protocol message transmitted and received by the user mode driver may be directly handed to the user mode protocol stack for processing.
In S108, when the application scenario is a non-real-time scenario, the native protocol packet is forwarded to a kernel-mode protocol stack for processing. The remote connection device requests and checks messages such as device information belonging to non-real-time scenes, and the messages can be forwarded to the kernel protocol stack for processing. The native protocol packet may be forwarded to a kernel-mode protocol stack for processing based on a write operation to the virtual file system.
In a non-real-time scene, the protocol message received and sent by the user mode driver is handed to the kernel mode driver for processing. More specifically, as shown in fig. 2, the user mode driver obtains the native protocol packet; sending the native protocol message to the kernel mode protocol stack to generate a processing result; and the user state driver acquires the processing result and sends the processing result to a Linux system.
According to the local protocol message processing method disclosed by the invention, the hardware of the Linux system obtains the local protocol message when running in the user mode; judging the application scene of the native protocol message; when the application scene is a real-time scene, forwarding the native protocol packet to a user mode protocol stack for processing; when the application scene is a non-real-time scene, the local protocol packet is forwarded to the kernel-mode protocol stack for processing, the local packet processing mode can be selected according to the specific application scene, the efficiency requirements of different scenes are met, and the interaction between the user mode and the kernel protocol stack packet can be realized.
The protocol message processing method has the advantages of being high in protocol message processing efficiency and high in speed, and the defects of long development period and high maintenance cost.
The method has the advantages that a kernel protocol stack is mature and stable, simple and easy to use, and does not need to be re-developed, and the defect is that the protocol message processing efficiency of the local machine is influenced by the interaction of the user mode messages and the kernel mode messages.
It should be clearly understood that this disclosure describes how to make and use particular examples, but the principles of this disclosure are not limited to any details of these examples. Rather, these principles can be applied to many other embodiments based on the teachings of the present disclosure.
In one embodiment, further comprising: and creating a virtual file system in a kernel mode of the Linux system to realize the read-write operation of the hardware. And creating an SKB chain table head, and inserting the message sent by the kernel mode protocol stack into the tail part of the chain table. The enqueue and dequeue operations of the queue of the SKB linked list are provided by the SKB.
And creating a proc type device in a kernel state, and realizing Read and Write operations of the device driver.
The Read operation is used for solving the problem of packet sending of the kernel mode protocol stack. After the protocol stack sends out the message, the protocol message of the local machine is added into the queue tail of the SKB linked list queue created before, and the waiting queue is awakened, and the protocol message buffered by the SKB linked list queue waits to be read. And starting a thread in the queue user state to read the equipment in a blocking mode, sending out the protocol message of the equipment through the user state after reading the protocol message in the SKB linked list queue, and blocking if the protocol message cannot be read.
The Write operation is used for solving the problem that the user mode cannot upload the kernel protocol stack after receiving the native protocol message. After receiving the protocol message of the native machine, the user mode hands the message to the kernel mode protocol stack for processing through the write operation of the proc equipment.
In one embodiment, further comprising: and creating a socket cache chain for storing the message sent by the kernel mode protocol stack. And creating a proc type device in a kernel state, and realizing Read and Write operations of the device driver. The proc file system on the Linux system is a pseudo file system (also called a virtual file system), and stores a series of special files of the current kernel operating state, so that a user can view information about system hardware and a current running process through the files, and even can change the operating state of the kernel by changing some files.
Furthermore, reading the SKB linked list in a blocking mode is realized by a waiting queue mode. And when the user mode thread reads the SKB linked list, adding the thread into the waiting queue, and if the SKB queue is not empty, taking out the message and sending out the message through the user mode. If the SKB queue is empty the process stops here and sleeps. When the message of the machine is sent out from the protocol stack, the message is enqueued in an SKB linked list queue, and the head of the queue is awakened. Therefore, the native message sent by the kernel state protocol stack can be sent out through the user state.
Fig. 3 is a flowchart illustrating a method for processing native protocol packets according to another example embodiment. The flow 30 shown in fig. 3 is a detailed description of "forwarding the native protocol packet to the kernel-mode protocol stack for processing" in S108 in the flow shown in fig. 1.
As shown in fig. 3, in S302, the user mode driver obtains the native protocol packet.
In S304, the native protocol packet is sent to the kernel-mode protocol stack to generate a processing result. The method comprises the following steps: sending the native protocol message to the kernel-mode protocol stack; and the kernel mode protocol stack processes the native protocol message to generate a processing result.
In S306, the user mode driver obtains the processing result and sends the processing result to the Linux system. The method comprises the following steps: the kernel mode protocol stack adds a processing result to the tail of the socket cache chain; the user state driver reads the processing result by the socket cache chain; and the user state driver sends the processing result to a Linux system.
Wherein, the kernel mode protocol stack adds the processing result to the queue tail of the socket cache chain, and the method further comprises: and awakening the queue head of the socket cache chain.
Wherein the user state driver reads the processing result from the socket cache chain, and the reading includes: the user state drives to create a thread; and performing a read operation on the socket cache chain in a blocking mode based on the thread to obtain the processing result.
Wherein, performing a read operation on the socket cache chain in a blocking manner based on the thread to obtain the processing result includes: when the socket cache chain is not empty, the thread reads the processing result; and when the socket cache chain is empty, the thread is in a dormant state.
The method for processing the native protocol message realizes the interaction between the user mode and the kernel protocol stack message by creating a proc device and realizes the buffering of the interaction message between the user mode and the kernel protocol stack by creating an SKB linked list queue.
Those skilled in the art will appreciate that all or part of the steps implementing the above embodiments are implemented as computer programs executed by a CPU. When executed by the CPU, performs the functions defined by the above-described methods provided by the present disclosure. The program may be stored in a computer readable storage medium, which may be a read-only memory, a magnetic or optical disk, or the like.
Furthermore, it should be noted that the above-mentioned figures are only schematic illustrations of the processes involved in the methods according to exemplary embodiments of the present disclosure, and are not intended to be limiting. It will be readily understood that the processes shown in the above figures are not intended to indicate or limit the chronological order of the processes. In addition, it is also readily understood that these processes may be performed synchronously or asynchronously, e.g., in multiple modules.
The following are embodiments of the disclosed apparatus that may be used to perform embodiments of the disclosed methods. For details not disclosed in the embodiments of the apparatus of the present disclosure, refer to the embodiments of the method of the present disclosure.
Fig. 4 is a block diagram illustrating an apparatus for processing native protocol messages in accordance with an example embodiment. As shown in fig. 4, the processing apparatus 40 for native protocol packets includes: the system comprises an acquisition module 402, a judgment module 404, a user mode module 406, a kernel mode module 408 and a creation module 410.
The obtaining module 402 is used for obtaining a native protocol message when the hardware of the Linux system operates in a user mode;
the judging module 404 is configured to judge an application scenario of the native protocol packet; the application scene of the message can be judged according to the message data in the native protocol message.
The user mode module 406 is configured to forward the native protocol packet to a user mode protocol stack for processing when the application scenario is a real-time scenario; for example, messages processed by video stream data and voice stream data belong to real-time scene type messages, and need to be processed by a user mode protocol stack.
The kernel mode module 408 is configured to forward the native protocol packet to a kernel mode protocol stack for processing when the application scenario is a non-real-time scenario. The remote connection device requests and checks messages such as device information belonging to non-real-time scenes, and the messages can be forwarded to the kernel protocol stack for processing. The native protocol packet may be forwarded to a kernel-mode protocol stack for processing based on a write operation to the virtual file system.
The creating module 410 is configured to create a virtual file system in a kernel mode of the Linux system, so as to implement read-write operation of the hardware; and the method is also used for creating a socket cache chain and storing the messages sent by the kernel mode protocol stack.
According to the processing device of the local protocol message, when the hardware of the Linux system runs in a user mode, the local protocol message is obtained; judging the application scene of the native protocol message; when the application scene is a real-time scene, forwarding the native protocol packet to a user mode protocol stack for processing; when the application scene is a non-real-time scene, the local protocol packet is forwarded to the kernel-mode protocol stack for processing, the local packet processing mode can be selected according to the specific application scene, the efficiency requirements of different scenes are met, and the interaction between the user mode and the kernel protocol stack packet can be realized.
FIG. 5 is a block diagram illustrating an electronic device in accordance with an example embodiment.
An electronic device 500 according to this embodiment of the disclosure is described below with reference to fig. 5. The electronic device 500 shown in fig. 5 is only an example and should not bring any limitation to the functions and the scope of use of the embodiments of the present disclosure.
As shown in fig. 5, the electronic device 500 is embodied in the form of a general purpose computing device. The components of the electronic device 500 may include, but are not limited to: at least one processing unit 510, at least one memory unit 520, a bus 530 that couples various system components including the memory unit 520 and the processing unit 510, a display unit 540, and the like.
Wherein the storage unit stores program code that is executable by the processing unit 510 to cause the processing unit 510 to perform the steps according to various exemplary embodiments of the present disclosure described in this specification. For example, the processing unit 510 may perform the steps as shown in fig. 1, fig. 3.
The memory unit 520 may include a readable medium in the form of a volatile memory unit, such as a random access memory unit (RAM)5201 and/or a cache memory unit 5202, and may further include a read only memory unit (ROM) 5203.
The memory unit 520 may also include a program/utility 5204 having a set (at least one) of program modules 5205, such program modules 5205 including, but not limited to: an operating system, one or more application programs, other program modules, and program data, each of which, or some combination thereof, may comprise an implementation of a network environment.
Bus 530 may be one or more of any of several types of bus structures including a memory unit bus or memory unit controller, a peripheral bus, an accelerated graphics port, a processing unit, or a local bus using any of a variety of bus architectures.
The electronic device 500 may also communicate with one or more external devices 500' (e.g., keyboard, pointing device, bluetooth device, etc.), such that a user can communicate with devices with which the electronic device 500 interacts, and/or any devices (e.g., router, modem, etc.) with which the electronic device 500 can communicate with one or more other computing devices. Such communication may occur via input/output (I/O) interfaces 550. Also, the electronic device 500 may communicate with one or more networks (e.g., a Local Area Network (LAN), a Wide Area Network (WAN), and/or a public network, such as the internet) via the network adapter 560. The network adapter 560 may communicate with other modules of the electronic device 500 via the bus 530. It should be appreciated that although not shown in the figures, other hardware and/or software modules may be used in conjunction with the electronic device 500, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems, among others.
Through the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein may be implemented by software, or by software in combination with necessary hardware. Therefore, as shown in fig. 6, the technical solution according to the embodiment of the present disclosure may be embodied in the form of a software product, which may be stored in a non-volatile storage medium (which may be a CD-ROM, a usb disk, a removable hard disk, etc.) or on a network, and includes several instructions to enable a computing device (which may be a personal computer, a server, or a network device, etc.) to execute the above method according to the embodiment of the present disclosure.
The software product may employ any combination of one or more readable media. The readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the foregoing. More specific examples (a non-exhaustive list) of the readable storage medium include: an electrical connection having one or more wires, a portable disk, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.
The computer readable storage medium may include a propagated data signal with readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated data signal may take many forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A readable storage medium may also be any readable medium that is not a readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code embodied on a readable storage medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.
Program code for carrying out operations for the present disclosure may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, C + + or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code may execute entirely on the user's computing device, partly on the user's device, as a stand-alone software package, partly on the user's computing device and partly on a remote computing device, or entirely on the remote computing device or server. In the case of a remote computing device, the remote computing device may be connected to the user computing device through any kind of network, including a Local Area Network (LAN) or a Wide Area Network (WAN), or may be connected to an external computing device (e.g., through the internet using an internet service provider).
The computer readable medium carries one or more programs which, when executed by a device, cause the computer readable medium to perform the functions of: acquiring a local protocol message when the hardware of the Linux system runs in a user mode; judging the application scene of the native protocol message; when the application scene is a real-time scene, forwarding the native protocol packet to a user mode protocol stack for processing; and when the application scene is a non-real-time scene, forwarding the native protocol packet to a kernel-mode protocol stack for processing.
Those skilled in the art will appreciate that the modules described above may be distributed in the apparatus according to the description of the embodiments, or may be modified accordingly in one or more apparatuses unique from the embodiments. The modules of the above embodiments may be combined into one module, or further split into multiple sub-modules.
Through the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein may be implemented by software, or by software in combination with necessary hardware. Therefore, the technical solution according to the embodiments of the present disclosure may be embodied in the form of a software product, which may be stored in a non-volatile storage medium (which may be a CD-ROM, a usb disk, a removable hard disk, etc.) or on a network, and includes several instructions to enable a computing device (which may be a personal computer, a server, a mobile terminal, or a network device, etc.) to execute the method according to the embodiments of the present disclosure.
Exemplary embodiments of the present disclosure are specifically illustrated and described above. It is to be understood that the present disclosure is not limited to the precise arrangements, instrumentalities, or instrumentalities described herein; on the contrary, the disclosure is intended to cover various modifications and equivalent arrangements included within the spirit and scope of the appended claims.

Claims (12)

1. A native protocol message processing method for a Linux system comprises the following steps:
acquiring a local protocol message when the hardware of the Linux system runs in a user mode;
judging the application scene of the native protocol message;
when the application scene is a real-time scene, forwarding the native protocol packet to a user mode protocol stack for processing;
and when the application scene is a non-real-time scene, forwarding the native protocol packet to a kernel-mode protocol stack for processing.
2. The method of claim 1, further comprising:
and creating a virtual file system in the inner Z core state of the Linux system to realize the read-write operation of the hardware.
3. The method of claim 1, further comprising:
and creating a socket cache chain for storing the message sent by the kernel mode protocol stack.
4. The method of claim 1, wherein forwarding the native protocol packet to a kernel-mode protocol stack for processing comprises:
the user state driver acquires the native protocol message;
sending the native protocol message to the kernel mode protocol stack to generate a processing result;
and the user state driver acquires the processing result and sends the processing result to a Linux system.
5. The method of claim 2 or 4, wherein sending the native protocol packet to the kernel-mode protocol stack comprises:
and forwarding the native protocol packet to a kernel-mode protocol stack for processing based on the write operation of the virtual file system.
6. The method of claim 4, wherein sending the native protocol packet to the kernel-mode protocol stack to generate a processing result comprises:
sending the native protocol message to the kernel-mode protocol stack;
and the kernel mode protocol stack processes the native protocol message to generate a processing result.
7. The method according to claim 3 or 4, wherein the user state driver obtains the processing result and sends the processing result to a Linux system, and comprises:
the kernel mode protocol stack adds a processing result to the tail of the socket cache chain;
the user state driver reads the processing result by the socket cache chain;
and the user state driver sends the processing result to a Linux system.
8. The method of claim 7, wherein the kernel mode protocol stack adds the processing result to the tail of the socket cache chain, further comprising:
and awakening the queue head of the socket cache chain.
9. The method of claim 7, wherein the user-state driver reading the processing result by the socket cache chain comprises:
the user state drives to create a thread;
and performing a read operation on the socket cache chain in a blocking mode based on the thread to obtain the processing result.
10. The method of claim 9, wherein performing a read operation on the socket cache chain in a blocking manner based on the thread to obtain the processing result comprises:
when the socket cache chain is not empty, the thread reads the processing result;
and when the socket cache chain is empty, the thread is in a dormant state.
11. A native protocol packet processing apparatus for a Linux system, comprising:
the acquisition module is used for acquiring a local protocol message when the hardware of the Linux system operates in a user mode;
the judging module is used for judging the application scene of the native protocol message;
the user mode module is used for forwarding the native protocol message to a user mode protocol stack for processing when the application scene is a real-time scene;
and the kernel mode module is used for forwarding the native protocol packet to a kernel mode protocol stack for processing when the application scene is a non-real-time scene.
12. The apparatus of claim 11, further comprising:
the creating module is used for creating a virtual file system in a kernel mode of the Linux system so as to realize the read-write operation of the hardware; and the method is also used for creating a socket cache chain and storing the messages sent by the kernel mode protocol stack.
CN202110193646.6A 2021-02-20 2021-02-20 Native protocol message processing method and device for Linux system Pending CN112883007A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202110193646.6A CN112883007A (en) 2021-02-20 2021-02-20 Native protocol message processing method and device for Linux system

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202110193646.6A CN112883007A (en) 2021-02-20 2021-02-20 Native protocol message processing method and device for Linux system

Publications (1)

Publication Number Publication Date
CN112883007A true CN112883007A (en) 2021-06-01

Family

ID=76056663

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202110193646.6A Pending CN112883007A (en) 2021-02-20 2021-02-20 Native protocol message processing method and device for Linux system

Country Status (1)

Country Link
CN (1) CN112883007A (en)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113259400A (en) * 2021-07-14 2021-08-13 南京易科腾信息技术有限公司 Network interaction system, method and storage medium based on network protocol
CN113596171A (en) * 2021-08-04 2021-11-02 杭州朗和科技有限公司 Cloud computing data interaction method and system, electronic equipment and storage medium
CN114338448A (en) * 2021-12-29 2022-04-12 北京天融信网络安全技术有限公司 Performance test method and device, electronic equipment and storage medium
CN115002028A (en) * 2022-04-30 2022-09-02 济南浪潮数据技术有限公司 Message processing method, device and medium

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070233876A1 (en) * 2006-03-30 2007-10-04 Thompson Belinda L Interprocess communication management using a socket layer
CN101226487A (en) * 2008-01-30 2008-07-23 中国船舶重工集团公司第七〇九研究所 Method for implementing inner core level thread library based on built-in Linux operating system
CN103312601A (en) * 2013-05-31 2013-09-18 汉柏科技有限公司 Data message processing method from user mode to kernel mode
CN110535813A (en) * 2018-05-25 2019-12-03 网宿科技股份有限公司 Kernel state protocol stack and User space protocol stack simultaneously deposit treating method and apparatus

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070233876A1 (en) * 2006-03-30 2007-10-04 Thompson Belinda L Interprocess communication management using a socket layer
CN101226487A (en) * 2008-01-30 2008-07-23 中国船舶重工集团公司第七〇九研究所 Method for implementing inner core level thread library based on built-in Linux operating system
CN103312601A (en) * 2013-05-31 2013-09-18 汉柏科技有限公司 Data message processing method from user mode to kernel mode
CN110535813A (en) * 2018-05-25 2019-12-03 网宿科技股份有限公司 Kernel state protocol stack and User space protocol stack simultaneously deposit treating method and apparatus

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
天夜创作室: "《Linux网络编程技术》", 30 November 2001, 人民邮电出版社 *
李杰: "《嵌入式Linux系统 开发原理与实战》", 30 November 2017, 北京理工大学出版社 *
高俊峰: "《高性能Linux服务器运维实战》", 31 May 2020, 《机械工业出版社》 *

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113259400A (en) * 2021-07-14 2021-08-13 南京易科腾信息技术有限公司 Network interaction system, method and storage medium based on network protocol
CN113596171A (en) * 2021-08-04 2021-11-02 杭州朗和科技有限公司 Cloud computing data interaction method and system, electronic equipment and storage medium
CN113596171B (en) * 2021-08-04 2024-02-20 杭州网易数之帆科技有限公司 Cloud computing data interaction method, system, electronic equipment and storage medium
CN114338448A (en) * 2021-12-29 2022-04-12 北京天融信网络安全技术有限公司 Performance test method and device, electronic equipment and storage medium
CN114338448B (en) * 2021-12-29 2024-02-20 北京天融信网络安全技术有限公司 Performance test method and device, electronic equipment and storage medium
CN115002028A (en) * 2022-04-30 2022-09-02 济南浪潮数据技术有限公司 Message processing method, device and medium
CN115002028B (en) * 2022-04-30 2024-02-13 济南浪潮数据技术有限公司 Message processing method, device and medium

Similar Documents

Publication Publication Date Title
CN112883007A (en) Native protocol message processing method and device for Linux system
WO2021259013A1 (en) Data processing method and apparatus, electronic device, and computer-readable medium
JP2005222533A (en) Adaptive dispatch of received messages to code using inter-positioned message modification
CN107404418B (en) Internet product testing method, device, equipment and storage medium
CN111190766A (en) HBase database-based cross-machine-room cluster disaster recovery method, device and system
US20240106754A1 (en) Load Balancing Method for Multi-Thread Forwarding and Related Apparatus
CN110908707B (en) Resource packaging method, device, server and storage medium
CN111026493B (en) Interface rendering processing method and device
US7539992B2 (en) Scheduling method, program product for use in such method, and task scheduling apparatus
CN114296646B (en) Caching method and device based on IO service, server and storage medium
US10642667B1 (en) Apparatus, system, and method for efficiently sharing data between processes
US7934063B2 (en) Invoking externally assisted calls from an isolated environment
CN109284108A (en) Date storage method, device, electronic equipment and storage medium
CN112700515A (en) Animation playing method and device, storage medium and electronic equipment
CN106933646B (en) Method and device for creating virtual machine
CN111352644A (en) Applet updating method, device, server and storage medium
CN100390741C (en) Program processing system, program processing method, and computer program
CN114696888B (en) Port task processing method, device, equipment and medium of satellite measurement, operation and control system
CN113141407B (en) Page resource loading method and device and electronic equipment
CN111881025B (en) Automatic test task scheduling method, device and system
CN112613955A (en) Order processing method and device, electronic equipment and storage medium
US8560544B2 (en) Clustering of analytic functions
CN111666156B (en) Container arranging method, device, equipment and storage medium
WO2021081730A1 (en) Direct memory access control method, system, computer apparatus, and storage medium
CN114816672A (en) Virtual machine creation method and device, electronic equipment and storage medium

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
RJ01 Rejection of invention patent application after publication

Application publication date: 20210601

RJ01 Rejection of invention patent application after publication