KR20120121202A - Method for protecting DDS network overload - Google Patents

Abstract

PURPOSE: A DDS(data distribution service) network overload prevention method is provided to prevent network overload generated by processing a heartbeat message between a server and a subscription node in a DDS environment. CONSTITUTION: A subscription executes a first ping test(S21). If the first ping test fails, the subscription node executes a DDS application(S22). When a ping test period is arranged, the subscription node recognizes the ping test period using a timer(S23). The subscription node periodically executes a second ping test(S24). When the second ping test succeeds, the subscription node terminates the execution of the DDS application(S25). [Reference numerals] (20) Ping period DB; (AA) Start; (BB) Yes; (CC) End; (S21) First ping test?; (S22) DDS application execution; (S23) Approching a ping test period?; (S24) Second ping test?; (S25) Ending DDS application

Description

Data Distribution Services Network Overload Prevention Method {Method for protecting DDS network overload}

The present invention relates to a method for preventing network overload in a data distributed service environment and to a method for preventing network load by processing heartbeat messages between a server and a subscription node.

Most naval combat system systems developed in Korea use RTI's Data Distribution Service (DDS) communication middleware. DDS internally uses a HeartBeat message of 200 hz for module discovery to dynamically maintain sessions between modules. Even if the software developer or software user does not send a message for intermodule communication, the server sends a heartbeat message to determine whether or not there is a subscription node.

However, if the subscribing node is developed in the company network and transmits a response message according to the heartbeat message of 200 hz to the server, the response message of the heartbeat message of 200 hz is a considerable burden on the server.

If only DDS application development is required in the subscribing node, the exchange of heartbeat and response messages by the connection between the server and the subscribing node is unnecessary. Therefore, when developing or using a naval combat system system using a data distribution service (DDS), the LAN cable, which is a network cable in the company network, is physically removed and used. That is, every time the user (user) uses the DDS, he physically removes the LAN line from his PC as a subscription node, stops using the DDS, and uses the LAN line again to use the Internet.

As described above, if the LAN line is removed every time the DDS is used, and the LAN line is connected again when the DDS is not used, excessive traffic is not transmitted to the server, which is not a problem. However, if the developer or the user repeats the above steps, they may accidentally use the DDS application without removing the LAN line. During the time when the user does not recognize the server, the server may receive an excessive 200hz heartbeat message and Since the response message must be processed, the overall network performance is a burden. If multiple developers (users) make this mistake at the same time, the server will be as if under a distributed denial of service attack (DDos), resulting in a server crash.

The technical problem of the present invention is to prevent network overload in a DDS environment. In addition, the technical problem of the present invention is to prevent the network load by the heartbeat message processing between the server and the subscription node. In addition, the technical problem of the present invention is to prevent damage caused by a user error when using the DDS network. In addition, the technical problem of the present invention is to make the user to the DDS network development to recognize that the network is connected. In addition, the technical problem of the present invention is to minimize the load caused by the ping test signal generation of the subscription node.

According to an embodiment of the present invention, a process of performing a ping first test by a subscribing node of a data distribution service (DDS) to check a connection state with a server to which the subscribing node is subscribed, and, if the ping first test is successful, the subscribing node. Executing a DDS application in the subscription node if the first ping test fails, and periodically performing a second ping test during the execution of the DDS application, and If the ping second test is successful, the running DDS application is terminated. If the ping second test fails, the process includes maintaining the execution of the DDS application.

In the ping second test, the ping test cycle is different for each type of DDS application to be executed. Construct a database configured with different ping test cycles for each type of DDS application to be executed.

If the second ping test is successful, terminating the execution of the DDS application includes terminating the DDS application of the ping second successful test node and requesting the other subscriber node belonging to the group of the joining node to terminate the DDS application. And terminating the DDS application running in the other subscribing node.

According to an embodiment of the present invention, network overload due to heartbeat message processing between a server and a subscription node in a DDS environment can be prevented. In addition, according to the embodiment of the present invention, it is possible to prevent network overload due to a developer's mistake in developing a DDS application of a subscription node. In addition, according to the embodiment of the present invention, when the user develops the DDS application, the user can check the network connection state and take appropriate measures. In addition, according to the embodiment of the present invention, by preventing the server overload in the DDS network, it is possible to prevent damage due to unexpected server down.

1 is a diagram illustrating a configuration module of a data distribution service (DDS) that performs data exchange through general data publishing / subscription.
2 is a flowchart illustrating a process of preventing network overload in a DDS according to an embodiment of the present invention.
3 is a diagram illustrating a DDS application execution window displayed on a display window of a subscription node when a DDS application is driven in a subscription node.
4 is a diagram illustrating a window in which a DDS application is displayed in a process area.
5 is a diagram illustrating a screen for notifying a user that a DDS application is terminated.
6 is a flowchart illustrating a process of preventing network overload in DDS for each grouping of subscription nodes according to an embodiment of the present invention.
7 is a diagram illustrating a state in which subscription nodes are grouped according to an embodiment of the present invention.

Hereinafter, with reference to the accompanying drawings will be described an embodiment of the present invention in more detail. However, the present invention is not limited to the embodiments disclosed below, but will be implemented in various forms, and only the embodiments are intended to complete the disclosure of the present invention and to those skilled in the art to fully understand the scope of the invention. It is provided to inform you. Wherein like reference numerals refer to like elements throughout.

1 is a diagram illustrating a configuration module of a data distribution service (DDS) that performs data exchange through general data publishing / subscription.

To reduce the burden on application developers in implementing direct data exchange between applications, standardized communication techniques and communication middleware dedicated to exchanging data are required.For this purpose, CORBA (Common Object Request Broker Architecture) or JMS (Java) is required. Communication middleware such as Message System.

However, in an environment in which communication devices dynamically form domains and frequently exchange data of the same type, a data-centric publish-subscriber method is preferable to COBRA or JMS. As a standard specification of communication middleware suitable for such a publisher-subscriber method, the data distribution service (DDS) of the object management group (OMG) has been proposed, and this DDS defines an interface with an application and a lower communication networking function. do.

In a distributed system composed of various equipments such as air control systems and combat systems, various sensors and weapons provided by various manufacturers must be operated in conjunction with multiple multifunction consoles, and the dependency on communication networks is high. The data distribution service (DDS) is used as a standard communication middleware for solving interoperability problems, reliability problems, etc. according to environmental differences of communication nodes.

For example, information processing in a naval battle system is triggered by data collected from sensors or by operator's command, so the data-oriented communication characteristics are strong and often propagate to multiple nodes simultaneously. DDS is used as the middleware standard suitable for this naval battle system, and the interface with the application / sub-communication networking function and the middleware function requirements are defined.

Data Distribution Service (DDS) is defined in OMG for the purpose of data-driven real-time data distribution. Data can be published and subscribed to an unspecified number of domains.

Data centric communication is appropriate when nodes in a domain frequently exchange data of the same type. In addition, if the number of nodes participating in the domain is large and dynamic registration and deregistration is performed, the data that the user wants without knowing the partner rather than server / client data exchange where the application finds and connects to the data exchange partner. Data exchange in the form of publishing / subscribing is more effective. The publishers publishing the data and the subscribers subscribing the data gather together to set up one domain and distribute data samples of the promised type in a multicast manner.

Detailed process of publishing / subscribing data in the data distribution service (DDS) is shown in FIG. 1. In the domain, there is a publishing node (server) and a subscriber node (subscriber), which exchange samples of Topic, which is a data type that has been promised.

The major modules that make up Data Distribution Service (DDS) are as follows:

Domain: a group of publishing nodes (servers) and subscriber nodes (subscribers)

Topic: data types exchanged within the domain

Data Writer (DataWriter): Receives data to be sent from an application, generates a topic sample, and sends data to a domain.

Data Reader (DataReader): executes the function of converting the Topic sample received from the domain into a message usable by the application and delivering it to the application.

2 is a flowchart illustrating a process of preventing network overload in a DDS according to an embodiment of the present invention.

In the following description, a publishing node that publishes data in a domain of a data distribution service (DDS) is called a server, and a subscription node that subscribes to data in a domain of the DDS is called a subscription node.

Each subscribing node that subscribes to data from the server, which is the publishing node, must run the DDS application installed in the subscribing node to access the server. The DDS application is an application that provides a data distribution service (DDS) communication middleware and performs a function of processing a DDS protocol. Each subscription node has a DDS application, and each subscription node in the DDS service domain may have a plurality of DDS applications.

First, when a developer requests execution of a DDS application in a subscription node, the subscription node checks whether the subscription node and the server are disconnected from each other before initially running the DDS application.

When the DDS application is started, a HeartBeat Message is sent to the subscribing node in a fast cycle (for example, 200 hz). In a developing environment, sending heartbeat messages to the DDS server is a server load. Therefore, this is to confirm the non-connection between the subscription node and the server before the DDS application is initially started.

For reference, the heartbeat message is a status check message transmitted from a server for checking whether a state of a subscription node managed by the server is operating normally. The heartbeat message is continuously transmitted to the subscription nodes in a fast cycle such as 200 hz. Message. The subscribing node receiving the heartbeat message transmits a response message to the server, and the server receiving the response message determines that the application of the subscribing node sending the response message is normal.

The subscription node checks whether the subscription node and the server are disconnected from each other before initially running the DDS application. This verification process is performed by a ping test generated by the subscription node (hereinafter referred to as a 'ping first test'). ') (S21).

The ping is a communication program used to check whether a specific system connected to a network is normally connected. The pinging program sends an ICMP echo request message to the remote host to wait for a response. That is, if the host that received the sent ICMP echo reqest is running, it will respond and the host will not run. In this way, depending on whether the ICMP echo reply returns, you can check whether the remote host is running or not.

Therefore, the subscribing node generates a ping signal and transmits it to the server node, and determines whether the ping test succeeds whether the ping response message of the server is correctly received. The result of the ping test is determined to be true or false. Ping test success (true) is a case in which the server sends a ping response message to the ping sent by the subscribing node, which means that the server and the subscribing node are normally connected by the network. On the other hand, a ping test false is a case in which the server did not send a ping response message to the ping sent by the subscribing node, indicating that the server and the subscribing node are disconnected without being connected by the network. it means

Therefore, when the test result is determined to be true (S21a) as a result of the ping first test S21, it may be determined that the server and the subscribing node are normally connected to the network. As described above, when the ping server and the subscribing node are networked to each other, the server may be overloaded due to the heartbeat message and the response message exchange due to the DDS application running. End the process.

On the other hand, if the ping first test result determines that the test result is false (S21b), it may be determined that the server and the subscribing node are disconnected from each other. As described above, when the ping server and the subscribing node are disconnected from each other (S21b), since the heartbeat message and the corresponding response message are not exchanged due to the DDS application, the server is not overloaded. Therefore, if it is determined that the ping test fails, the developer executes the DDS application development task by executing the DDS application (S22). For reference, FIG. 3 is a diagram illustrating a DDS application execution window displayed on a display window of a subscription node when a DDS application is driven in a subscription node.

Meanwhile, since the DDS application execution window is displayed on the display window of the subscription node as shown in FIG. 3 while the DDS application is running (S22), the developer may recognize that the DDS application is running. However, while the DDS application is running, the DDS application execution window as shown in FIG. 3 may not appear on the user's screen by chance. However, even if the DDS application execution window disappears, there may be a case where it still remains in the process area as shown in FIG. 4. That is, when the screen overlaps another screen or when the ShowWindow property is set to hide, the DDS application may not appear on the screen. For reference, in FIG. 3 and FIG. 4, the executable file name of the DDS application is "Comm.exe".

As a result, although the DDS application is still running, the developer may not be aware of the DDS application execution.

Even though the DDS application is running, the developer may misjudge that the DDS application is terminated because the DDS application window is not displayed on the screen, and connect the network LAN to the subscribing node. When the server and the subscribing node are networked while the DDS application is running as described above, due to the heartbeat and the exchange of response messages, the corresponding traffic is transmitted to the server as it is. Developers who misjudge that a DDS application is not running don't think about blocking the network, so excessive traffic can be sent to the server for a long time, causing server load problems.

Therefore, in order to prevent such a problem, the ping test (hereinafter referred to as 'ping second test') is periodically performed whenever the ping test cycle arrives even after the application is driven and executed. That is, when a predetermined cycle arrives (S23), the timer recognizes the cycle by a timer (not shown) and performs a ping second test (S24).

As a result of the ping second test (S24), if it is determined that the ping test failed (false) indicating a network connection failure, since the network between the server and the subscribing node is still disconnected, the DDS application execution (S22) continues to be performed. Continue development.

On the contrary, if it is determined that the ping test succeeds (true) that the network connection is normal, it means the network connection state between the server and the subscribing node, and thus the execution of the DDS application is terminated (S25). Upon termination, the user (developer) is notified that the DDS application is terminated, so that the user (developer) can know whether the DDS application is terminated. The user (developer) knows that the DDS application is terminated, and through this, the subscriber node and the server know that the network is connected to each other, and can take measures such as disconnection of a LAN. For reference, FIG. 5 is a diagram illustrating a screen for notifying the user that the DDS application is terminated, and displaying a termination notification window on the screen so that the user can know it. Alternatively, the user may be notified in the form of an SMS or MMS message through a wired or wireless communication network.

On the other hand, the period of the ping second test (S23) is a period in which the ping second test is executed, the period is set in advance by varying the ping test period for each type of DDS application to be executed, the ping test period is set differently It is stored in the ping period DB 20.

The ping second test period lengthens the ping test period in proportion to the execution load of the DDS application. For example, when the load of the subscription node takes more than a preset threshold when the DDS first application of the subscription node is executed, the load of the subscription node by the ping test is minimized by holding the second ping test period as long as possible. This is because frequent ping test attempts create additional load on the joining node. Therefore, by setting a long ping test period in the case of a DDS application that is heavily loaded due to the execution of the DDS application, the load due to the ping test is minimized.

Conversely, when the DDS application is running, if the load of the subscription node is less than the threshold, the ping test cycle is shortened without worrying about the load, and frequently the network connection between the server and the subscription node is checked.

On the other hand, generating a ping test signal each time a ping test period arrives can likewise act as a load on the server. This is because the server, which has received the ping test signal, should grasp the normal arrival packet, the non-arrival packet, etc. of the received data and include it in the message and transmit it to the subscribing node that has sent the ping test as a ping response message. Therefore, if a plurality of subscribing nodes transmit ping tests to the server at frequent intervals, server load problems may occur. In consideration of this problem, the DDS application termination processing for each grouping is performed. A detailed description will be given with reference to FIGS. 6 and 7.

6 is a flowchart illustrating a process of preventing network overload in DDS for each grouping of subscription nodes according to an embodiment of the present invention.

As described above with reference to FIG. 2, the embodiment of the present invention performs a ping first test before driving the DDS application (S21), and if it is determined that the ping test result is false, the DDS application is executed (S22). ). Thereafter, during the execution of the DDS application, the second test S24 is periodically performed (S23). If the ping test fails, the DDS application is continuously executed (S22), and if the ping test is successful, the DDS application is executed. End (S25).

However, according to another embodiment of the present invention, the DDS application is terminated (S25) for each grouping of the joining nodes. To this end, as shown in FIG. 7, a plurality of subscribing nodes that subscribe to data from the server 70 should be grouped with a certain number of subscribing nodes 80a, 80b,. The grouping may be determined according to network attributes between the joining nodes. For example, when there are joining nodes connected by different gateways, joining nodes connected to the same gateway may be grouped into the same group.

If at least one member joining the group is determined to be a successful ping test, all of the DDS applications operated in the joining nodes of the entire group to which the joining node determined to be successful in the ping test belong.

You can try to ping only one joining node and terminate the DDS application running in other joining nodes in the same group according to the result, so you don't have to try frequent pinging of each joining node. Can be minimized.

To this end, according to an embodiment of the present invention, if it is determined that the ping test succeeds (true) when the ping second test (S24) is performed during the execution of the DDS application as shown in FIG. It is determined whether or not (S26). If the group-specific termination mode is set, the DDS application of all the subscription nodes in the group to which the ping test successful subscription node belongs is terminated (S27). For example, if it is determined that the ping test executed by the second subscribing node 82 belonging to the first group 80a shown in FIG. 7 is true, the second subscribing node 82 belongs to All DDS applications operating in the first to the tenth joining nodes in the group 80a are terminated (S27). At this time, it does not affect whether the DDS application of the subscribing nodes in the second group 80b to the N-th group 80n to which the subscribing node to which the ping test succeeds belongs does not belong.

For reference, if the ping test succeeds, the successful subscribing node terminates the DDS application operating in its own node and transmits a message requesting the termination of the DDS application to other grouped subscribing nodes. The subscribing node receiving the DDS application termination message terminates the DDS application operating in its own.

On the other hand, as a result of determining whether it is set to the end mode for each group (S26), if it is not set to the end mode for each group, only the joining nodes that have successfully pinged the test terminate the DDS application (S28) and belong to the same / other group. The DDS application of the other subscribing nodes continues to run.

Although the present invention has been described with reference to the accompanying drawings and the preferred embodiments described above, the present invention is not limited thereto but is limited by the following claims. Accordingly, those skilled in the art will appreciate that various modifications and changes may be made thereto without departing from the spirit of the following claims.

S21: Ping First Test S22: Running DDS Application
S23: Ping test cycle arrives S24: Ping second test
S25: DDS Application Termination

Claims (9)

Performing a ping first test by the subscribing node of the data distribution service (DDS) to check a connection status with a server to which the subscribing node subscribes;
Not executing a DDS application in the subscribing node if the ping first test is successful, and executing a DDS application in the subscribing node if the ping first test fails;
Periodically performing a ping second test during execution of the DDS application;
Terminating a running DDS application if the second ping test is successful, and maintaining execution of the DDS application if the ping second test fails;
DDS network overload prevention method comprising a. The method of claim 1, wherein the second ping test comprises changing a ping test period for each type of DDS application to be executed. The DDS network overload prevention method according to claim 2, wherein a database configured by setting a ping test cycle for each type of DDS application to be executed is constructed. The method according to claim 2, wherein the ping test period increases the ping test period in proportion to the execution load of the DDS application. The method according to claim 1, wherein if the second ping test succeeds and terminates execution of the DDS application, the DDS network overload prevention method is notified to the user of the termination of the DDS application. The method of claim 1, wherein a plurality of subscribing nodes are subscribed to a server to perform DDS communication. The method of claim 6, wherein the subscribing nodes subscribed to the server are grouped into a plurality of groups. The method according to claim 7, wherein if the second ping test is successful, the DDS network overload prevention method which terminates execution of a DDS application operating in another subscription node belonging to the group of the ping second successful test subscription node. The method of claim 8, wherein the execution of the DDS application is terminated when the ping second test is successful.
Terminating the DDS application of the subscribing node that has successfully completed the ping second test;
Requesting termination of a DDS application from another subscription node belonging to the group of the subscription node;
Terminating a DDS application running in the other subscribing node;
DDS network overload prevention method comprising a.

Images