CN113472784A - Separated DDS protocol stack architecture based on data distribution service - Google Patents
Separated DDS protocol stack architecture based on data distribution service Download PDFInfo
- Publication number
- CN113472784A CN113472784A CN202110738789.0A CN202110738789A CN113472784A CN 113472784 A CN113472784 A CN 113472784A CN 202110738789 A CN202110738789 A CN 202110738789A CN 113472784 A CN113472784 A CN 113472784A
- Authority
- CN
- China
- Prior art keywords
- protocol stack
- dds
- dds protocol
- client
- data distribution
- 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
Links
- 230000007246 mechanism Effects 0.000 claims abstract description 6
- 238000000034 method Methods 0.000 claims description 7
- 230000008569 process Effects 0.000 claims description 6
- 238000004891 communication Methods 0.000 abstract description 6
- 230000005540 biological transmission Effects 0.000 abstract description 5
- 238000005457 optimization Methods 0.000 abstract description 5
- 230000007547 defect Effects 0.000 abstract description 2
- 239000008186 active pharmaceutical agent Substances 0.000 description 9
- 230000006872 improvement Effects 0.000 description 5
- 238000012545 processing Methods 0.000 description 4
- 239000002699 waste material Substances 0.000 description 4
- 238000010586 diagram Methods 0.000 description 3
- 230000002159 abnormal effect Effects 0.000 description 2
- 230000008901 benefit Effects 0.000 description 2
- 230000005012 migration Effects 0.000 description 2
- 238000013508 migration Methods 0.000 description 2
- 230000005856 abnormality Effects 0.000 description 1
- 230000004075 alteration Effects 0.000 description 1
- 230000006399 behavior Effects 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 238000013507 mapping Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000008520 organization Effects 0.000 description 1
- 238000000926 separation method Methods 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer And Data Communications (AREA)
Abstract
The invention relates to a separated DDS protocol stack architecture based on data distribution service, belonging to the field of communication transmission. The architecture comprises a plurality of user applications and a plurality of DDS protocol stacks, wherein a protocol stack service end is embedded in the DDS protocol stacks, and a protocol stack client is embedded in the user applications; the protocol stack server communicates with the protocol stack client through an IPC mechanism. The invention solves the defects of the traditional DDS protocol deployment mode, and the traditional DDS protocol stack is split and deployed, the protocol stack client is arranged at the user application layer, and the protocol stack server is arranged in the DDS protocol stack. Therefore, user application and protocol are not influenced mutually any more, and the safety and stability of operation are improved. Meanwhile, the problem of resource occupation under the condition of multiple applications is solved. And the invention is based on traditional DDS data distribution service, although separates the client of DDS protocol stack, it still provides the interface consistent with the original DDS protocol stack, which is convenient for optimization and deployment.
Description
Technical Field
The invention relates to a separated DDS protocol stack architecture based on data distribution service, belonging to the field of communication transmission.
Background
The DDS is called Data Distribution Service, i.e. Data Distribution Service, and is a new generation of distributed real-time communication middleware technical specification made by the object management Organization (OMG) based on the standards of HLA, CORBA, and the like. The DDS information distribution middleware is a software layer as a flexible middleware technology capable of providing real-time information transmission, and abstracts applications from details of an operating system, network transmission, and a bottom data format. The same concepts and APIs provide different programming languages so that applications exchange information between different operating systems, programming languages, and processor architectures. The underlying details including data transport format, discovery, connectivity, reliability, protocol, QoS management, etc. are managed by the middleware. The DDS middleware is a software layer that abstracts applications from the details of the operating system, network transport, and underlying data format. The same concepts and apis are provided for different authoring languages, enabling applications to exchange information between different operating systems, authoring languages, and processing architectures. The underlying details including data transport format, discovery, connectivity, reliability and, protocol, Qos policies, etc. are managed by the middleware.
The DDS adopts a publish/subscribe system architecture, takes data as a center and provides rich QoS (quality of service) strategies.
At the heart of the data-centric is that the DDS knows the data within the entire integrated network and controls the sharing of the data. With conventional message-centric middleware, the issue of sending messages must be considered. And data values can be shared by using the data-centric middleware only by considering the problems of how to share data and when to share data. The DDS implements controlled, managed, secure data sharing directly for the user, rather than managing all responsible logic in the application code. Among numerous communication, the DDS is the only standard taking data as the center and is suitable for the Internet of things.
As middleware, the above several DDS products provide a related library file, and a user performs application development according to an API thereof. The implementation layer equivalent to the DDS specification and its interoperability protocol layer are run inside each user application. The benefits of this deployment modality are plug-and-play and high scalability.
Meanwhile, because the user service and the DDS protocol stack operate in the same process space, when any one party has unrecoverable abnormality, the operation of the other party is affected. And the tampering behavior of the newly expanded user application on the data in the DDS protocol stack cannot be avoided. When a plurality of DDS applications run, because each application allocates at least one corresponding DDS protocol stack, the memory and resources occupied by the running of the protocol stacks are multiplied. In addition, the DDS protocol stack is not a lightweight protocol stack, and the waste of resources is aggravated with the increase of applications. This waste of resources also presents challenges to optimizing device performance.
In view of the above situation, there is a need for a new way to solve the problems of security, stability, resource waste and performance optimization in the DDS data distribution service.
Disclosure of Invention
The technical problem to be solved by the invention is as follows: how to provide a DDS protocol stack architecture based on data distribution service, which is used for solving the problems of safety, stability, occupation of CPU resources and memory resources and performance optimization existing in the traditional DDS protocol stack during deployment.
In order to solve the technical problems, the technical scheme provided by the invention is as follows: a separate DDS protocol stack architecture based on data distribution service comprises a plurality of user applications and a plurality of DDS protocol stacks, and is characterized in that: a protocol stack server is embedded in the DDS protocol stack, and a protocol stack client is embedded in the user application; and the protocol stack server communicates with the protocol stack client through an IPC mechanism.
The further improvement of the scheme is as follows: the release end of the user application sends information to the DDS protocol stack; and the subscription end of the user application receives the information sent by the DDS protocol stack.
The further improvement of the scheme is as follows: the protocol stack client provides an API interface, and when a user application calls, the protocol stack client transmits an API instruction and parameters to the protocol stack server through IPC.
The further improvement of the scheme is as follows: and the protocol stack server is responsible for maintaining the connection with the protocol stack client.
The further improvement of the scheme is as follows: the DDS protocol stacks are connected through a network.
The further improvement of the scheme is as follows: and setting a unique DDS protocol stack or setting a main DDS protocol stack and a standby DDS protocol stack under the same operating environment, wherein each DDS protocol stack is distributed with an independent process space and is effectively isolated from the user application.
The invention has the beneficial effects that: the invention solves the defects of the traditional DDS protocol deployment mode, and the traditional DDS protocol stack is split and deployed, the protocol stack client is arranged at the user application layer, and the protocol stack server is arranged in the DDS protocol stack. The user application and the protocol are not influenced mutually, and the running safety and stability are improved. Meanwhile, the problem of resource occupation under the condition of multiple applications is solved. And the invention is based on traditional DDS data distribution service, although separates the client of DDS protocol stack, it still provides the interface consistent with the original DDS protocol stack, which is convenient for optimization and deployment.
In order to further improve the safety, each protocol stack is limited to operate in an independent process space and is isolated from user application so as to prevent mutual influence; in order to further save the operation resources, only one running DDS protocol stack is required to be kept under each operation environment, and the situation that a plurality of DDS protocol stacks run simultaneously and CPU resources and memory resources are occupied is avoided.
Drawings
Fig. 1 is a schematic comparison diagram of a conventional DDS protocol stack and a DDS protocol stack of the present invention.
Fig. 2 is a diagram illustrating a topology architecture of a separated DDS protocol stack according to an embodiment of the present invention.
Fig. 3 is a schematic diagram of a partial topology architecture of a separate DDS protocol stack deployed in a master-slave mode in the second embodiment of the present invention.
Detailed Description
Example one
A separate DDS protocol stack architecture based on data distribution service in this embodiment, as shown in fig. 2, includes a user application 1, a user application 2, a user application 3, a user application 4, a DDS protocol stack 1, and a DDS protocol stack 2. As shown in fig. 1, a protocol stack server is embedded in a DDS protocol stack, and a protocol stack client is embedded in a user application; the protocol stack server communicates with the protocol stack client through an IPC mechanism, namely, a release end applied by a user sends information to the DDS protocol stack; and a subscription terminal of the user application receives the information sent by the DDS protocol stack. As shown in fig. 2, the user application 1 and the user application 2 are connected in a matching manner with the DDS protocol stack 1, and they may be deployed on the same host or on different hosts, but it is required to ensure that the user application can perform normal IPC communication with the DDS protocol stack. As shown in fig. 2, the user application 3 and the user application 4 are connected to the DDS protocol stack 2 in a matching manner. And the DDS protocol stack 1 and the DDS protocol stack 2 are connected through a network.
In this embodiment, it can be seen that data interaction between user applications may occur within the same protocol stack or across different protocol stacks. And the operation between the protocol stack and the user is independent and does not interfere with each other. Therefore, no matter the DDS protocol stack or the user service is abnormal in operation, the other party is not abnormal. The data of the DDS protocol stack is prevented from being tampered by the user service unintentionally or maliciously. Different levels of security can be achieved by the DDS protocol stack and the user applications. The DDS protocol stack may even be used as part of a black channel communication.
The protocol stack client in this embodiment provides an API interface, and when a user application calls, the protocol stack client transmits an API instruction and parameters to the protocol stack server through IPC. The protocol stack server is responsible for maintaining the connection with the protocol stack client, managing mapping table entries, and executing actual DDS API instructions.
The operation of the DDS protocol stack occupies memory and CPU resources, and in the same operation environment, when a plurality of DDS applications operate simultaneously, under the conventional condition, a plurality of DDS protocol stacks operate simultaneously to be matched with the DDS applications, so that the memory and CPU resources are occupied. In addition, the DDS protocol stack is not a lightweight protocol stack, and the occupation of the resources is increased sharply with the increase of the running quantity.
However, this embodiment does not have this situation, and this example is due to the splitting of the server and the client of the DDS protocol stack. Therefore, only one DDS protocol stack mentioned in the embodiment needs to be operated in each operation environment, and waste of CPU resources and memory resources is avoided. Although a client of one protocol stack is still reserved in each user application, it takes relatively less resources than the way the conventional DDS protocol stack is fully present in the application as shown in fig. 1. In addition, the client is mainly responsible for the transmission of API interface instructions and parameters, is relatively light and is also one reason for selecting resident applications.
As shown in fig. 1, the conventional DDS protocol stack is in each user application, but the DDS protocol stack and the user application of this embodiment are independent from each other, so that optimization means such as process-level core binding processing, thread-level core binding processing, pre-allocation of a macro-page memory, and the like can be implemented conveniently.
Although the present embodiment sets the protocol stack client and the protocol stack server in the user application and the DDS protocol stack, respectively, the resulting interface is still in accordance with the height of the API interface. The migration of user applications brings great convenience. Because the protocol stack client is also provided for the user in the form of a library, the user only needs to switch the library file reference in the compiled file to complete the migration, thereby avoiding a large amount of code modification. Similarly, the user can change the dependent library file according to the requirement, and the switching between the two modes is realized, wherein the convenience is self-evident.
Example two
The embodiment is basically the same as the first embodiment, except that, as shown in fig. 3, a main DDS protocol stack and a standby DDS protocol stack are set in the same environment, and are respectively a DDS protocol stack 1, a host and a DDS protocol stack 2, and a standby machine, where the DDS protocol stack 1 in a running state establishes an effective IPC connection with a user application. By applying a keep-alive mechanism over the IPC connection. When the keep-alive of the DDS protocol stack 1 and the user application fails, the user application is switched to establish connection with the DDS protocol stack 2, the DDS protocol stack 2 takes over the DDS processing service of the user application, and meanwhile, the main and standby identities of the DDS protocol stack 1 and the DDS protocol stack 2 are exchanged.
In addition to the active/standby deployment form described in this embodiment, other backup deployment forms may be used to meet different high availability requirements. This of course benefits from the separation of the client and server sides of the DDS protocol stack.
The present invention is not limited to the specific technical solutions described in the above embodiments, and other embodiments may be made in the present invention in addition to the above embodiments. For example, when multiple user application processes communicate with different DDS protocol stacks through an IPC mechanism, a flexible deployment modality can be achieved. In addition to the aforementioned diversified deployment of redundant devices, a more flexible deployment format can be adopted according to the actual software and hardware environment and functional requirements. For example, if we require to provide differentiated services to meet different reliability requirements, matching the user application with a specific DDS protocol stack; or the DDS protocol stack may be deployed in a higher performance runtime environment, and the user application may be deployed in another runtime environment. The operating environment can be reached as long as IPC can be met. It can be seen that under the framework of the present invention, deployment will become more flexible and varied. It will be understood by those skilled in the art that various changes, substitutions of equivalents, and alterations can be made without departing from the spirit and scope of the invention.
Claims (6)
1. A separate DDS protocol stack architecture based on data distribution service comprises a plurality of user applications and a plurality of DDS protocol stacks, and is characterized in that: a protocol stack server is embedded in the DDS protocol stack, and a protocol stack client is embedded in the user application; and the protocol stack server communicates with the protocol stack client through an IPC mechanism.
2. The separated DDS protocol stack architecture based on data distribution services of claim 1, wherein: the release end of the user application sends information to the DDS protocol stack; and the subscription end of the user application receives the information sent by the DDS protocol stack.
3. The separated DDS protocol stack architecture based on data distribution services of claim 2, wherein: the protocol stack client provides an API interface, and when a user application calls, the protocol stack client transmits an API instruction and parameters to the protocol stack server through IPC.
4. The separated DDS protocol stack architecture based on data distribution services of claim 3, wherein: and the protocol stack server is responsible for maintaining the connection with the protocol stack client.
5. The separated DDS protocol stack architecture based on data distribution services of claim 1, wherein: the DDS protocol stacks are connected through a network.
6. The separated DDS protocol stack architecture based on data distribution services of claim 1, wherein: the method comprises the steps that a unique DDS protocol stack is arranged or a main DDS protocol stack and a standby DDS protocol stack are arranged under the same operation environment, and each DDS protocol stack is distributed with an independent process space.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110738789.0A CN113472784A (en) | 2021-06-30 | 2021-06-30 | Separated DDS protocol stack architecture based on data distribution service |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110738789.0A CN113472784A (en) | 2021-06-30 | 2021-06-30 | Separated DDS protocol stack architecture based on data distribution service |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN113472784A true CN113472784A (en) | 2021-10-01 |
Family
ID=77876833
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202110738789.0A Pending CN113472784A (en) | 2021-06-30 | 2021-06-30 | Separated DDS protocol stack architecture based on data distribution service |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN113472784A (en) |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114553980A (en) * | 2021-12-31 | 2022-05-27 | 西安空间无线电技术研究所 | Message service method for decoupling control flow and data flow |
| CN114610506A (en) * | 2022-03-09 | 2022-06-10 | 奥特酷智能科技(南京)有限公司 | Intra-domain shared memory transmission architecture and mechanism based on separated data distribution service |
| CN115250287A (en) * | 2022-06-23 | 2022-10-28 | 重庆长安汽车股份有限公司 | Automatic adaptation method and system based on DDS multiport |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20110264740A1 (en) * | 2010-04-21 | 2011-10-27 | John Diachina | Mtc device bandwidth reduction |
| CN109842567A (en) * | 2017-11-24 | 2019-06-04 | 华为技术有限公司 | Data distributing method and the distribution server |
| CN114610506A (en) * | 2022-03-09 | 2022-06-10 | 奥特酷智能科技(南京)有限公司 | Intra-domain shared memory transmission architecture and mechanism based on separated data distribution service |
-
2021
- 2021-06-30 CN CN202110738789.0A patent/CN113472784A/en active Pending
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20110264740A1 (en) * | 2010-04-21 | 2011-10-27 | John Diachina | Mtc device bandwidth reduction |
| CN109842567A (en) * | 2017-11-24 | 2019-06-04 | 华为技术有限公司 | Data distributing method and the distribution server |
| CN114610506A (en) * | 2022-03-09 | 2022-06-10 | 奥特酷智能科技(南京)有限公司 | Intra-domain shared memory transmission architecture and mechanism based on separated data distribution service |
Cited By (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114553980A (en) * | 2021-12-31 | 2022-05-27 | 西安空间无线电技术研究所 | Message service method for decoupling control flow and data flow |
| CN114553980B (en) * | 2021-12-31 | 2023-11-10 | 西安空间无线电技术研究所 | Message service method for decoupling control flow and data flow |
| CN114610506A (en) * | 2022-03-09 | 2022-06-10 | 奥特酷智能科技(南京)有限公司 | Intra-domain shared memory transmission architecture and mechanism based on separated data distribution service |
| CN115250287A (en) * | 2022-06-23 | 2022-10-28 | 重庆长安汽车股份有限公司 | Automatic adaptation method and system based on DDS multiport |
| CN115250287B (en) * | 2022-06-23 | 2023-08-04 | 重庆长安汽车股份有限公司 | Automatic adaptation method based on DDS multiple ports |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10649798B2 (en) | Virtual switching method, related apparatus, and computer system | |
| CN113472784A (en) | Separated DDS protocol stack architecture based on data distribution service | |
| US8027354B1 (en) | Network consolidation for virtualized servers | |
| US7085805B1 (en) | Remote device management in grouped server environment | |
| US20080140857A1 (en) | Service-oriented architecture and methods for direct invocation of services utilizing a service requestor invocation framework | |
| US20080263544A1 (en) | Computer system and communication control method | |
| US20200344126A1 (en) | Network slice deployment method and apparatus | |
| WO2019160030A1 (en) | Service provision system, resource allocation method, and resource allocation program | |
| CN113821268B (en) | Kubernetes network plug-in method fused with OpenStack Neutron | |
| CN106790084A (en) | A kind of heterogeneous resource integrated framework and its integrated approach based on ICE middlewares | |
| CN110224917B (en) | Data transmission method, device and system and server | |
| US8732308B1 (en) | Coordinated management in virtualized systems using management brokers and management channels | |
| CN108345490B (en) | Method and system for deploying virtual machine in NFV | |
| WO2021043124A1 (en) | Kbroker distributed operating system, storage medium, and electronic device | |
| WO2023016415A1 (en) | Node for running container group, and management system and method of container group | |
| Benomar et al. | Cloud-based enabling mechanisms for container deployment and migration at the network edge | |
| CN113515408A (en) | Data disaster tolerance method, device, equipment and medium | |
| Bruneo et al. | Mobile middleware: Definition and motivations | |
| CN112698838A (en) | Multi-cloud container deployment system and container deployment method thereof | |
| KR102119456B1 (en) | Distributed Broker Coordinator System and Method in a Distributed Cloud Environment | |
| CN116800616B (en) | Management method and related device of virtualized network equipment | |
| US11561916B2 (en) | Processing task deployment in adapter devices and accelerators | |
| CN113608836A (en) | Cluster-based virtual machine high availability method and system | |
| CN114615268B (en) | Service network, monitoring node, container node and equipment based on Kubernetes cluster | |
| CN112398668B (en) | IaaS cluster-based cloud platform and node switching method |
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 | ||
| CB02 | Change of applicant information |
Address after: 210012 room 401-404, building 5, chuqiaocheng, No. 57, Andemen street, Yuhuatai District, Nanjing, Jiangsu Province Applicant after: AUTOCORE INTELLIGENT TECHNOLOGY (NANJING) Co.,Ltd. Address before: 211800 building 12-289, 29 buyue Road, Qiaolin street, Pukou District, Nanjing City, Jiangsu Province Applicant before: AUTOCORE INTELLIGENT TECHNOLOGY (NANJING) Co.,Ltd. |
|
| CB02 | Change of applicant information | ||
| RJ01 | Rejection of invention patent application after publication |
Application publication date: 20211001 |
|
| RJ01 | Rejection of invention patent application after publication |