Methods, systems and computer-readable medium for receiving test configuration information
Abstract
The invention relates to a method, a system and a computer-readable medium for receiving test configuration information. The claimed method takes place in a node configured to operate in a private network and includes: registering node identification information with a registration server, sending a keep-alive message to the registration server, receiving, in response to the keep-alive message, via the registration server, test configuration information from a configuration system outside the private network. The claimed system comprises a node configured to operate in a private network, said node comprising a test configuration module (TCM) configured to register node identification information with a registration server, to send a keep alive message to the registration server and to receive, in response to the keep-alive message and via the registration server, test configuration information from a configuration system outside the private network.

Term
8.2 yearsto projected expiry
Projected expiry 27 November 2034, counted from filing; an application has no term until it is granted.
- Priority and filed
- Published
- Today
- Projected expiry
23 claims: 3 independent, 20 dependent
- 1CLAIMS REVENDICĂRI It is claimed:Se revendică: 1. A method for receiving test configuration information, which uses a recording server, the method comprising: 1. O metodă de recepționare de informații de configurarea testărilor, care utilizează un server de înregistrare, metoda cuprinzând: la un nod configurat să funcționeze într-o rețea privată: to a node configured to work on a private network: recording node identification information to the registration server, sending a maintenance message to the registration server;and receiving, in response to the maintenance message and through the registration server, information about configuring the tests from an operating system outside the private network. înregistrarea informațiilor de identificare a nodului la serverul de înregistrare, transmiterea unui mesaj de întreținere la serverul de înregistrare;și recepționarea, ca răspuns la mesajul de întreținere șî prin intermediul serverului de înregistrare, de informații de configurarea testărilor de la un sistem de operare din afara rețelei private.
- 12A system for receiving information from test setups, the system comprising:12. Un sistem pentru recepționarea de informații de configurarea testărilor, sistemul cuprinzînd: a node configured to operate on a private network, the node comprising: a configured test configuration (TCM) module: un nod configurat să opereze într-o rețea privată, nodul cuprinzând: un modul de configurarea testărilor (TCM) configurat: record node identification information on a registration server, send a maintenance message to the registration server;and receive, in response to the maintenance message and through the registration server, the configuration information of the tests from an operating system outside the private network. să înregistreze informațiile de identificare a nodului la un server de înregistrare, să trimită un mesaj de întreținere la serverul de înregistrare;și să primească, ca răspuns la mesajul de întreținere și prin intermediul serverului de înregistrare, informațiile de configurarea testărilor de la un sistem de operare din afara rețelei private.
- 232. 3. A non-transient computer-supported medium, which contains executable instructions on the computer, incorporated into the non-transient medium, which, when executed by a computer, performs the following steps;23. Un suport non-tranzitoriu.citibil de calculator, care conține instrucțiuni executabile pe calculator, încorporate în suportul non-tranzitoriu, care, atunci când sunt executate de un calculator, efectuează următorii pași conținând;la un nod configurat să opereze într-o rețea privată;to a node configured to operate on a private network;Recording node identification information to a registration server;Înregistrarea informațiilor de identificare a nodului la un server de înregistrare;sending a maintenance message to the recording server;and what ZO 1 4 - - 009182 7 -11- 2014 receiving, in response to the maintenance message and through the registration server, information about configuring the tests from an operating system outside the private network. transmiterea unui mesaj de întreținere la serverul de înregistrare;și ce Z O 1 4 - - 009182 7 -11- 2014 recepționarea, drept răspuns la mesajul de întreținere și prin intermediul serverului de înregistrare, de informații de configurarea testărilor de la un sistem de operare din afara rețelei private.
Independent claims3
178 paragraphs in 6 sections, as filed
DESCRIPTION
METHODS, SYSTEMS AND READABLE COMPUTER SUPPORT FOR RECEIVING INFORMATION FROM TEST CONFIGURATION.
TECHNICAL FIELD
The object of the invention described herein relates to the configuration of the tests. Specifically, the object of the invention relates to methods, systems and computer readable support for receiving information from test setup.
PREVIOUS STAGE OF THE TECHNIQUE
Network operators typically test network nodes for security and other features, prior to deploying nodes to active (for example, non-test) and / or private networks. Although testing a network node before implementation may be beneficial, there are scenarios where testing a node in a private and / or active network is useful and / or necessary, for example, for detecting and / or resolving previously undetected problems. However, when trying to configure network nodes for testing on an active and / or private network, problems may occur. In particular, configuring network nodes for testing on an active and / or private network can create or exacerbate security concerns, since the test operator will have to go beyond the firewall and / or network devices. network address translation (NAT) to communicate with network nodes.
Conventional solutions, such as the penetration of network protocols that use secure channel between network (SSH) or text (HTTP) devices, allow testing configuration information to cross the firewall and NAT. However, they are not completely secure, as they require the presence of a network operator, which will open ports on firewall devices (eg, port, 80 'for HTTP and port, 22' for SSH tunnels). These solutions also require a significant product support effort, as each route through which test setup information passes requires a tunnel. Furthermore, HTTP ripping is preferred because, although the operator can allow the 80 'port to be opened in the firewall, content-aware devices can block traffic. further, for
A- 2 0 1 4 - - 009182 7 -11- 2014 crossing NAT, it is usually necessary to manually set the endpoints of the IP network (endpoint). As such, a significant effort is generally required to configure network nodes for testing in an active and / or private network.
As a result, there is a need for computer readable methods, systems and support for receiving test setup information.
EXPOSURE OF THE INVENTION
Methods, systems and computer readable support for receiving test setup information are disclosed. According to an embodiment of the method, the method according to the invention takes place in a node configured to operate on a private network. The method includes recording node identification information on a registration server. The method also includes sending a keep-alive message to the recording server. The method also includes receiving, in response to the maintenance message and through the registration server, the information to configure the tests from an operating system outside the private network.
According to an embodiment of the system, the system includes a node configured to operate on a private network. The node includes a Test Configuration Module (TCM), configured to record node identification information to a registration server, send a maintenance message to the registration server, and receive, in response to the maintenance message and through the server. registration, information about configuring tests from an operating system outside the private network.
The object of the invention described herein may be implemented by software in combination with hardware and / or firmware. For example, the object of the invention described herein may be implemented by software executed by a processor. In another embodiment of the invention, the object of the invention described herein may be implemented using a computer readable medium that stores instructions executable by the computer, which, when executed by the processor of a computer, commands it to perform steps . The computer readable medium according to the invention, suitable for implementing the object of the invention described herein includes non-transient devices, such as memory disks, memory chips, programmable logic devices, user programmable gate networks and integrated circuits with specific applications. In addition, a computer readable medium that implements the subject matter of the invention £ 2014-- 0 0 9 1 8 2 7 -11- 2014 described herein may be located on a single computer device or platform or may be distributed on multiple computer devices or platforms. .
As used herein, the term "node" refers to a physical computing platform, which includes one or more processors, network interfaces and memory.
As used herein, each of the terms "function" and "module" refers to hardware, firmware, or software in combination with hardware and / or firmware for implementing the features described herein.
BRIEF DESCRIPTION OF THE DRAWINGS
The object of the invention described herein will be explained with reference to the accompanying drawings, in which:
- Figure 1 is a diagram illustrating a computer platform for receiving information from the configuration of the tests, according to an embodiment of the present invention;
- Figure 2 is a diagram illustrating a means for receiving information by configuring the tests, according to an embodiment of the present invention;
- Figure 3 is a diagram illustrating a test network, according to an embodiment of the present invention;
- Figure 4 is a diagram illustrating the registration of an end point, according to an embodiment of the present invention;
- Figure 5 is a diagram illustrating the retrieval of information regarding the end point, according to an embodiment of the present invention;
- Figure 6 is a diagram illustrating the communication of information regarding the configuration of the tests, according to an embodiment of the present invention;
Figure 7 is a diagram illustrating a test setup according to an embodiment of the invention described herein;
Figure 8 is a diagram illustrating the completion of a test, according to an embodiment of the present invention;
Figure 9 is a diagram illustrating the processing of a response to the maintenance message, according to an embodiment of the present invention;
¢1- 2014-- 00918' 2 7 -11- 2614
<img file="RO131252A2_D0001.tif" />
Figure 10 is a diagram illustrating a process for managing the connection of an endpoint, according to an embodiment of the present invention;
- Figure 11 is a diagram illustrating the processing of a test connection, according to an embodiment of the present invention;
Figure 12 is a diagram illustrating communications in a test network, according to an embodiment of the present invention; and
- Figure 13 is a diagram illustrating a process of receiving information from the test configuration, according to an embodiment of the present invention.
DETAILED DESCRIPTION
The invention described herein includes methods, systems and computer readable support for receiving test setup information. When preparing network node testing, test operators typically need to provide test configuration information to one or more nodes. For example, test setup information may include any information that is appropriate for generating test traffic, informing and establishing test participants, and / or executing a test session that conforms to the test requirements, that is, as decided by the test operator. Currently, in order for test configuration information to pass through a firewall, a setting port must be opened that an endpoint should consider. Also, if network address translation (NAT) is enabled, manual mapping between public and private IP endpoints must be performed.
According to some aspects of the object of the invention described herein, the techniques for communicating test configuration information may include the use of various mechanisms (eg, endpoint registration, reverse connections, proxy endpoints, recording servers and / or messaging services). maintenance), so that test configuration information passes through security devices (such as a firewall and / or network address translation (NAT) device to reach endpoints (eg, traffic generators). For example, a recording server can be used to provide test configuration information (eg, address and / or port information of an off-network operating system) without opening ports in ¢ (- 2014-- 0 0 9 1 8 2 7 -11- 2014
<img file="RO131252A2_D0002.tif" />
firewall devices and / or without mapping address information (such as Internet Protocol (IP) addresses), if NAT is enabled.
Advantageously, according to some aspects of the invention described herein, by communicating test configuration information without opening ports in a firewall and / or without mapping address information if NAT is enabled, test configuration information can be provided and received. through network nodes in an active and / or private network, while changes are made or removed to network security devices.
References will be made in detail to the embodiments of the present invention, examples illustrated by the accompanying drawings. Whenever possible, the same reference numbers will be used in the drawings, to refer to the same or similar parts.
Figure 1 is a diagram illustrating a computer platform 100 for receiving information related to the configuration of a test, according to an embodiment of the present invention. Referring to Figure 1, a private network may include a computer platform 100 and a public network may include an operating system 104.
The computer platform 100 may be represented by a network device, a network module, a node or a system of devices, nodes and / or modules. For example, the computer platform 100 may be an endpoint located behind one or more associated security devices, such as a firewall or a NAT device, on a private network (for example, a test network or the network of a company). In some embodiments, the computer platform 100 may be a single node or may include functions distributed between multiple computer platforms or nodes.
In some embodiments, the computer platform 100 may include a traffic generator and may emulate one or more network nodes. For example, the computing platform 100 may be configured to emulate a web server and / or user device and may generate test traffic (for example, messages and / or packets) associated with these nodes.
In some embodiments, the computer platform 100 and / or its modules may receive test configuration information, used to set up a test session and / or run a test session. For example, test setup information may include a list of test participants and a script for generating and sending traffic and / or special streams to test participants. in ^ -2014-- 0 0 9 1 8 2 7-11-2014 /// this example, after receiving the test configuration information, the computer platform 100 can configure, generate and / or execute test traffic based on the test setup.
The computer platform 100 may communicate (for example, directly and / or indirectly) with the operating system 104. The operating system 104 may represent a node or device that includes functions for generating and / or sending information for testing configuration. For example, the operating system 104 may provide a user interface or communication console 106. In some embodiments, user 106 may be an automatic system or may be controlled or controllable by a human user. The user 106 may select and / or decide the test information for the configuration of the computer platform 100 and / or order the test (for example, start, pause and / or stop), using one or more control commands via the operating system 104.
In some embodiments, the operating system 104 may include one or more ports and / or modules for configuring one or more tests. For example, the operating system 104 can be configured to send different test configuration information and to test different network nodes, sometimes simultaneously. In this example, communications from or to the operating system 104 may take place through different port addresses, for example, depending on the test nodes or the associated network.
In some embodiments, communications from or to the operating system 104 and / or other nodes (for example, on a public network or on a network other than the computer platform 100) may occur without changing the configurations associated with the security devices from a private and / or active network. For example, test configuration information of an operating system 104 from a public network may be received by the computer platform 100 of a corporate network without opening ports on a firewall and / or without NAT-related mapping changes.
Computer platform 100 may include or access a test configuration module (TCM) 102. TCM 102 may represent any appropriate entity or entities (for example, a computer platform, a processor executable software, a logic device, a complex programmable logic device (CPLD), user programmable gateway networks (FPGA) and / or an integrated circuit with specific application (ASIC)) for performing one or more aspects related to the reception, transmission and / or use of configuration information <2014-- 0 0 9 1 8 2 7 -11- 2DK tests. For example, TCM 102 may receive communication test information and may use communication test information to configure computer platform 100 and / or its modules for testing purposes.
In some embodiments, TCM 102 may include the function of receiving information by configuring the tests via the operating system 104 and / or another node. For example, the computer platform and / or a module thereof may be configured to record on a recording server and, after registration, send maintenance messages (for example, every 2 seconds) to the recording server. In this example, the recording server can receive test configuration information from operating system 104 and can provide test configuration information via a response message to the maintenance message on the computer platform 100 and / or TCM 102.
In some embodiments, the computer platform and / or TCM 102 may include functions for using test configuration information. For example, the computer platform and / or TCM 102 may receive and use test configuration information to discover or identify operating system 104, to initiate connections to operating system 104, to configure a test session, to receive a signal opening the test session, for executing the test session (for example, generating, receiving and / or sending traffic), for receiving a signal to stop the test session, for stopping or completing the test session and / or for reporting test results for one or more nodes.
In some embodiments, TCM 102 may include one or more communication interfaces for interaction with users, systems and / or nodes. For example, TCM 102 may include one or more communication interfaces for receiving and sending different types of messages, such as IR messages, version 4 (V4), version 6 (V6), messages using the transmission control protocol. TCP, messages using SCTP data stream control, messages using RTP real-time transport protocol or RDP property, messages using GPRS, GTP, messages using a tunnel protocol and / or other messages.
TCM memory 108 may represent any appropriate entity (for example, a non-transient media readable by the computer or a memory device) for storing data associated with messages (message flows, test traffic, test results, statistics) and / or test.
^‘2014-- 0 0 9 1 8 2 7 -11- 2014
Examples of data stored on TCM 108 memory may include connection information, related traffic information, test information, address information, port, proxy, node identification, test configuration, testlor results, statistics and / or other information.
In some embodiments, TCM memory 108 may be integrated or accessible through TCM 102, computer platform 100, or modules thereof. In some embodiments, the TCM memory 108 may be located at a node other than the TCM 102 and / or the computer platform 100. For example, the TCM memory 108 may be associated with a storage device separate from the computer platform 100.
It is appreciated that Figure 1 is illustrative and that several nodes, their locations and / or their functions described above in connection with Figure 1 may be changed, modified, added or deleted. For example, some nodes and / or functions can be combined into one entity.
Figure 2 is a diagram illustrating the environment 200 according to the invention for receiving test setup information, according to an embodiment of the invention described herein. Referring to Figure 2, the environment 200 may include a network of large remote server groups (cloud network) 202 and an endpoint 210 connected to an enterprise network or a private network 206 via the Internet or other public network.
The endpoint 210 may be a node (for example, the computer platform 100) including TCM 102 and / or a similar function for receiving the information for testing configuration and generating test traffic, using test configuration information. In some embodiments, the endpoint 210 may be located in a different network than the nodes in the cloud network 202 and / or a private network 206. For example, endpoint 210 may be able to communicate directly with cloud network 202 and its nodes, but may require proxy nodes or may wait for private network input connections 206, for example, because network security devices are connected. private 206 can block the outgoing connections from the endpoint 210.
The cloud network 202 may include a console and a recording server (console / recording server) 204. The recording console / server 204 may represent one or more nodes that include the function of registering nodes in the enterprise network 206 and / or in the testing environment 208 and / or for providing £ <2014-- 0 0 9 1 8 2 7 -11- 2014 information on configuring node testing, initiating a test, a stop test and / or interaction with one or more test operators.
Private network 206 may include an endpoint 214, a firewall and / or a NAT device (firewall / NAT) 218, a proxy recording server 220, and / or a test environment 208. End point 214 may represent a node. (for example, computer platform 100), including TCM 102 and / or a similar function to receive test configuration information and test traffic generation, using test configuration information. In some embodiments, the endpoint 214 may be able to communicate directly with the recording console / server 204, but may require proxy nodes or may wait for the incoming connections to be established with the test medium 208 or its nodes, for example, because security devices related to the test environment 208 may block the output connections at the end point 214.
In some embodiments, communications to or from the endpoint 214 may pass through the firewall / NAT 218. The firewall / NAT 218 may represent any security device, such as a firewall and / or a NAT device. , which may block, modify and / or remove some communications. For example, firewall / NAT 218 may remove or block incoming connection requests from all nodes on an external network, for example, connection requests from the console / record server 204 on the cloud 202.
The proxy registration server 220 may include functions for communicating node identification information from one or more nodes to the console / registration server 204. For example, the proxy registration server 220 may be configured to receive registration messages from the nodes. in the test environment 208 and, after receiving the information, can send the information to the recording console / server 204.
Test environment 208 may be one or more nodes associated with the test. For example, the test environment 208 may represent a test laboratory located outside or isolated from an active enterprise network, for example, the private network 206. The test environment 208 may include a firewall / NAT 216 and an endpoint. 212. Endpoint 212 may represent a node (for example, computer platform 100), including TCM 102 and / or a similar function to receive test configuration information and to generate test traffic, using rt-2 0 1 4 - 0 0 9 1 8 2? -11- 201 «test configuration information. In some embodiments, communications to or from the endpoint 216 may cross the firewall / NAT 218.
In some embodiments, the private network 206 may include multiple levels of security. In such examples, the test configuration information (for example, test setup information) may be propagated from the recording console / server 204 to different nodes involved in testing.
In some embodiments, connections may only be opened or initiated by nodes within the private network 206, because the associated security devices (eg, firewall / NAT 218) cannot allow inbound connections to ports, for example, others. than test ports. In such examples, the endpoints of the private network 206 and / or the test environment 208 can only receive configuration information from the recording console / server 204 through outbound connections or through a proxy node or intermediary node.
In some embodiments, the recording console / server 204 may use proxy nodes, such as a proxy registration server 220, to communicate with some nodes and / or networks. For example, the recording console / server 204 may receive node identification information (eg, registration information) from endpoint 212 through the proxy registration server 220. In this example, a security device, for example, a firewall and / or a NAT (firewall / NAT) device 218 may block the input connection from the endpoint 212 recording console / server 204, but may allow connections output from or input connections to the proxy registration server 220.
It will be appreciated that Figure 2 is illustrative and that several nodes, their locations and / or their functions, described above in connection with Figure 2, may be changed, modified, added or removed. For example, some nodes and / or functions may be separated between multiple entities.
Figure 3 is a diagram illustrating an example of a test network 300, according to an embodiment of the invention described herein. Referring to Figure 3, the test network 300 may include a recording server 302, a proxy recording server 304, an endpoint 306, a proxy endpoint 308, and a console 310.
Recording server 302 may be a node capable of communicating (for example, directly or indirectly) with proxy registration server 304, endpoint 306, proxy endpoint 308, and / or console 310. In some examples of (\ - 2 0 1 4 - - 009182 7 -11- 2014, the registration server 302 can receive and store node identification information from different nodes. In some embodiments, the recording server 304 may receive test configuration information from console 310 and may provide test configuration information to one or more nodes. In some embodiments, the recording server 302 may be located on a different network from one or more nodes.
In some embodiments, the recording server 302 may register various nodes for testing purposes. In such embodiments, the registration server 302 may also receive maintenance messages from the registered nodes to indicate the current status and / or availability of the nodes, and may respond with messages containing test configuration information and / or other information. .
In some embodiments, the registration server 302 may communicate with the proxy registration server 304. The proxy registration server 304 may include functions similar to the registration server 220 and may be used to communicate node identification information from one or multiple nodes on the server
I recording 302. For example, endpoint 306 may be behind a firewall and / or NAT device, which prevents direct communication with the recording server 302, but may allow direct communication between the endpoint 306 and the proxy recording server. 304. In this example, the proxy registration server 304 can provide information received from endpoint 306 to the registration server 302. In some embodiments, the proxy registration server 304 may be located on a network other than the registration server 302 and / or other nodes.
Endpoint 306 may represent a node (for example, computer platform 100), including TCM 102 and / or a similar function for receiving test configuration information and generating test traffic, using test configuration information. In some embodiments, the end point 306 may include functions similar to the end points 210-214. In some embodiments, the endpoint 306 may be located on a network other than the console 310, the registration server 302, and / or other nodes.
In some embodiments, the endpoint 306 may be configured to send maintenance messages to the recording server 302 and / or to the recording server 304 and receiving a response message from the recording server 302 and / or the recording server 304 In some embodiments, the point
0 1 4 - - 0 0 9 1 8 2 7 Ί1- 2014 end 306 can initiate a test session and store test results and / or test information.
In some embodiments, the endpoint 306 may communicate with the proxy endpoint 308. The proxy endpoint 308 may be used to communicate test results and / or other test-related information to the console 310. For example, the endpoint end 306 may be behind a firewall and / or NAT device that prevents direct communication with console 310, but may allow direct communication between end point 306 and proxy end point 308. In some embodiments, the proxy endpoint 308 may be used for load balancing. In some embodiments, the proxy endpoint 308 may be located on a network other than one or more nodes.
Console 310 may represent a node, including functions for generating and / or sending test configuration information to the recording server 1202 and / or other nodes, such as proxy endpoint 308 and endpoint 306. In some embodiments , console 310 may include functions similar to the console function described above, related to the console / recording server 204. In some embodiments, the console 310 may be used to configure a test session, receive test results, process and / or display them to a user. For example, the console 310 may indirectly communicate with the endpoint 306 through one or more proxy nodes.
It will be appreciated that Figure 3 is illustrative and that several nodes, their locations and / or their functions described above in connection with Figure 3 can be changed, modified, added or deleted. For example, some nodes and / or functions may be combined into a single entity, for example, the registration server 302 may be integrated into the console 310 similar to the console / registration server 204.
Figure 4 is a diagram illustrating the recording end point in the test network 300, according to an embodiment of the invention described herein. Referring to Figure 4, end point 306 may send a registration message to the registration server 304, for providing node identification information and / or other information (for example, status and / or status information) regarding at end point 306. The proxy registration server 304 can receive the registration message and can store or update a registration data structure 402 based on the information provided. The proxy registration server 304 may also send the registration message and / or the information ^ -2014-- 009182 7 -11- 2014 associated with the endpoint 306 to the registration server 302. The registration server 304 can receive the registration message and / or information related to it and can store or update a registration data structure 400, based on the information provided. The proxy endpoint 308 may send a registration message to the registration server 302, for providing node identification information and / or other information (for example, status and / or status information) related to the endpoint 308. The registration server 302 can receive the registration message and can store or update the registration data structure 400 based on the information provided.
In some embodiments, after registration with the registration server 302 and / or 304, endpoints 306 and / or 308 may periodically or non-periodically send a maintenance message to indicate that the node is currently operational or active. For example, if the recording server 302 does not receive a maintenance message from the proxy endpoint 308 within a certain period of time (for example, at least every four seconds), the recording server 302 may interpret that the proxy endpoint 308 is inoperable or inactive.
In some embodiments, a registration message may include node identification information. For example, node identification information may include a name, a version identifier, an operating system identifier, a platform identifier, address information, and / or port information. In this example, node identification information may also include initialization information that can be preconfigured and can be used to indicate where to send the registration messages and / or which registration server is used.
Figure 5 is a diagram illustrating the extraction of information from the endpoint in the test network 300, according to an embodiment of the invention described herein. Referring to Figure 5, before generating test configuration information, console 310 may request node identification information from registration server 302. In some embodiments, in response to receiving a request for node identification information, the registration server 302 can obtain node identification information from the registration data structure 400 and can send the node identification information in a message. response to the console.
In some embodiments, console 310 may receive information about available (eg, registered) endpoints (eg, endpoints 306 and 308) from the registration server 302. In this example, console 310 may use this information to generate a test session and / or to generate test configuration information.
Figure 6 is a diagram illustrating the communication of test configuration information in test network 300, according to an embodiment of the invention described herein. Referring to Figure 6, after generating test configuration information, console 310 (for example, user-controlled 106) can initiate a test session and / or propagate and / or communicate test configuration information to the recording server 302, the server Proxy Registration Record 304, End Point 306 and / or Proxy End Point 308.
In some embodiments, the console 310 may send test configuration information, such as test data 600, to the recording server 302. In some embodiments, the recording server 302 may modify the test configuration information and / or generate information. additional to configuring the tests before sending information to one or more nodes. For example, the registration server 302 may receive test setup information and create Endpoint Test data (for example, endpoint test data 602 or 604), which contains test information for each endpoint. end that receives test setup information.
In some embodiments, the recording server 302 may send test configuration information (eg, relevant end point test data) to the corresponding end points and / or intermediate nodes. For example, the recording server 302 may respond to a maintenance message from the proxy registration server 304 with a message containing the test data of endpoint 602. In this example, after receiving endpoint test data 602 and in response to receiving a maintenance message from endpoint 306, the proxy recording server 304 may respond with a message containing endpoint test data. 602. In another example, the recording server 302 may respond to a maintenance message at the proxy endpoint 308 with a message containing the endpoint test data 604.
In some embodiments, the endpoint configuration information and / or endpoint test data may include address and / or port information to communicate to console 310 and / or to other peer-to-peer nodes. For example, test configuration information may include an IP address and a communication port identifier with console 310. Testing configuration information may also indicate whether a node will initiate a connection or will be the beneficiary of initiating a connection. For example, test configuration information may include a set of equal rank inputs (peers) and / or a set of equal rank outputs (peers) for a particular node.
In some embodiments, a peer-to-peer entry may be a node that sends a connection request to a particular node, and a peer-to-peer output may be a node that receives a request from a particular node. For example, a node can initiate a connection with a peer-to-peer output, while a peer-to-peer input can initiate a connection with the node.
In some embodiments, a peer-to-peer input may represent a node from which information is received directly or indirectly, and a peer-to-peer output may be a node from which information is sent directly or indirectly . For example, the test data 600 may indicate that, for a test session 11, the proxy endpoint 308 acts as a peer-to-peer input for delivering test results and / or other information to the console 310 and that the point end 306 acts as a peer-to-peer output to receive test configuration information and / or other information from console 310.
In some embodiments, for example, if a node does not wait for a connection to be initiated or if a node does not initiate a connection, peer-to-peer input or output cannot be stored. For example, endpoint test data 602 may indicate that, for a test session 11, proxy endpoint 308 acts as a peer-to-peer output for endpoint 306 and that endpoint 306 does not include a peer-to-peer entry.
Figure 7 is a diagram illustrating configuration testing in test network 300, according to an embodiment of the invention described herein. In some embodiments, after receiving test setup information, proxy endpoint 308 and / or endpoint 306 may use test setup information to request additional information (for example, traffic and / or setting information test).
¢2014-- 009182 7 -11- 2014
<img file="RO131252A2_D0003.tif" />
Referring to Figure 7, endpoint 306 may open (for example, initiate and establish) a connection to proxy endpoint 308, for example, using the address information received through a registration response message from the registration server 302 Proxy endpoint 308 can open a connection to console 310 and provide node identification information associated with endpoint 306 on console 310. Console 310 may send test setting information associated with endpoint 306 to proxy end point 308. After receiving the test setup information, proxy end point 308 may send or transmit test setup information to end point 306.
In some embodiments, after each endpoint has received the appropriate test configuration (for example, test setup information), endpoint 306 may run a test session and obtain or gather test results.
Figure 8 is a diagram illustrating the completion of testing on test network 300, according to an embodiment of the invention described herein. Referring to Figure 8, after the test results are obtained or collected, the console 310 can send a final test command for stopping or ending a specific test session. For example, the console 310 can send the final test command ending the test session. 11 for the registration server 302. In this example, the recording server 302 can relay the final test command of the endpoint 306 through the proxy recording server 304, using response maintenance messages. In another example, the final test command can be sent to end point 306 and a test completion message via proxy end point 308.
In some embodiments, after receiving the final test command, endpoint 306 may stop the test and inform the proxy endpoint 308 that the test session has ended and, in response, the proxy endpoint 308 may notify console 310 that the test session ended.
In some embodiments (for example, the embodiments described in FIGS. 7 and 8), the recording server 302 and / or the recording server 304 cannot act as a communication router from console 310 to endpoints 306 and / or 308, since directing such communications may be inefficient and / or cause significant delays. In contrast, in such embodiments, the registration server 302 and / or the registration server 304 may act as facilitating factors for providing information (eg, address information) to enable (X-2 0 1 4 - - 009182 7 -11- 20Μ console 310 and endpoints 306 and 308 to be discovered and communicated with each other, for example, to receive additional test setup information (eg, test setup information), start the test session and / or end it.
Figure 9 is a diagram illustrating an example of a process for processing a response maintenance message, according to an embodiment of the invention described herein. In some embodiments, the process or parts thereof may be performed by or at the computer platform 100, TCM 102 and / or another node or module. In some embodiments, the process may include some of steps 900-930.
Referring to Figure 9, an example of a process can start at step 900. At step 902, an endpoint can connect and / or register to a recording server.
At step 904, the endpoint can send a maintenance message to the recording server. For example, endpoint 302 may be configured to periodically send maintenance messages to registration server 304 and may include status and / or status information.
At step 906, the endpoint may receive a response message from the recording server. For example, the recording server 304 may send a response message indicating when a new test begins or that a maintenance operation is needed.
In step 908, you can determine if testing setup and / or test setup is required. if you require test setup information and / or test setup, step 910 may appear. If not, step may appear
916.
In step 910, testing the configuration and / or setting of the test can be performed, including generating or restoring the thread for each emulated user or node that generates test traffic. For example, if a test session is started, endpoint 302 may receive test configuration information for restoring one or more threads, if each thread can generate and / or send test traffic for one or more threads. more emulated users.
In step 912, it can be determined whether more users or nodes need to be emulated. If so, step 910 can take place until many users or nodes through the execution threads are emulated ¢¢ 2014-- 009182 1 -Π- 2014. If not, step 914 can take place.
In step 914, the exemplified procedure can be terminated.
In step 916, in response to the decision that testing setup and / or test setup is not required, it can be determined whether an upgrade or maintenance is required. If an upgrade or maintenance is required, step 918 may take place. If not, step 924 may occur.
In step 918, upgrade or maintenance information can be received from the registration server.
In step 920, an installation application or other application can be reproduced or generated for an upgrade or maintenance.
In step 922, the exemplified procedure can be terminated.
At step 924, you can decide whether to restart the system. If you need to restart the system, step 926 can take place. If not, step 930 can take place.
In step 926, a restart script or other application can be created or generated to perform system restart.
In step 928, the exemplified procedure can be terminated.
At step 930, the exemplified procedure can be terminated.
It will be appreciated that the process described in Figure 9 is illustrative and that different and / or additional actions may be used. It will also be appreciated that the different actions described here may occur in a different order or sequence.
Figure 10 is a diagram of an example of a process for manipulating the connection of an end point according to an embodiment of the invention described herein. In some embodiments, the exemplary process or parts thereof may be performed by or at the computer platform 100, TCM 102 and / or another node or module. In some embodiments, the exemplary process may include some of steps 1000-1024.
Referring to Figure 10, the exemplary process may begin at step 1000. At step 1002, it can be determined whether an endpoint is a proxy endpoint. if the endpoint is a proxy, step 1004. may take place. If not, step 1016 may occur.
In step 1004, in response to the decision that the endpoint is a proxy node, the proxy endpoint can initiate the connection with a console. For example, the dot
2014- - 009182 7 -11- 2014 proxy end 308 can use an IP address and port identifier received from the registration server 302 when a connection to console 310 is initiated.
At step 1006, the proxy endpoint can wait for a connection to start by a target endpoint and accept the connection. For example, the endpoint 306 may initiate a connection with the proxy endpoint 308 and the proxy endpoint 308 may accept the connection, once initiated.
In step 1008, the test configuration information (for example, test setup information) can be received from the console and can be transmitted to the test point. For example, proxy endpoint 308 may receive test setup information from console 310 and may transmit it to endpoint 306.
In step 1010, a test session can be run and the proxy endpoint can send test results and / or information received from the target endpoint to the console. For example, during and / or after a test session, endpoint 306 may transmit test results and / or reports to proxy endpoint 308 and proxy endpoint 308 may send or resend information to console 310.
In step 1012, the proxy endpoint can close the connection to the console. For example, after performing the testlor, the proxy endpoint 308 may close the connection with the console 310.
At step 1014, the exemplary procedure can be terminated.
In step 1016, in response to the decision that the endpoint is not a proxy, the endpoint may initiate a peer connection, for example, a proxy endpoint. For example, endpoint 306 may initiate a connection with proxy endpoint 308 for receiving test setup information (eg, test setup information) from console 310.
At step 1018, the endpoint can receive test setup information (for example, test setup information) from a console. For example, endpoint 306 may initiate a connection to proxy endpoint 308, proxy endpoint 308 may receive test setup information from console 310, and may resend testing setup information to endpoint 306.
At step 1020, a test session can be run and the endpoint can send test results and / or associated information received to the peer. For example, during and / or after a test session, endpoint 306 may transmit test results and / or reports to proxy endpoint 308.
<2 0 1 4 - 00918I Ί -11- 2014/2 / -
At step 1022, the endpoint can close the peer connection. For example, after testing is completed, endpoint 306 may close the connection with proxy endpoint 308.
At step 1024, the exemplified procedure can be terminated.
It will be appreciated that the process described in Figure 10 is illustrative and that different and / or additional actions may be used. It will also be appreciated that the different actions described here may occur in a different order or sequence.
Figure 11 is a diagram illustrating the processing of the connection test, according to an embodiment of the invention described herein. In some embodiments, connection requests may include requests for testing configuration information (for example, test setting information) and / or other test related information and may include node identification information to indicate the applicant. For example, the console 310 may receive connection requests from different endpoints. In this example, the different endpoints may be associated with different test configurations and, as such, console 310 may be configured to provide information about configuring the appropriate (and probably different) testing at each endpoint.
In some embodiments, the console 310 may use multiple program threads or application threads to handle the various aspects of processing the connection request. For example, one or more threads can be configured to receive connection requests and place requests in a queue or data structure. In this example, the set wires associated with certain endpoints can be configured to take the connection requests from the data structure and, if appropriate (for example, a thread is associated with the same end point as a specific request), to process them, for example, by accepting the connection and sending test configuration information.
Referring to Figure 11, a connection monitoring wire 1100 may represent a service, application, or process (for example, executing executable software on a processor) for receiving connection requests and storing them in a 1102 data structure of connections. In some embodiments, the connection monitoring wire 1100 may avoid inspection and / or processing (for example, response to requests) of the connection requests to avoid bottlenecks and / or associated delays. In some embodiments, several $ - 2 0 1 4 - - 009182 7 -11- 2014 1100 connection monitoring wires may be used for one or more networks, segments, nodes, and / or test operators.
The connection data structure 1102 may represent any data structure suitable for storing and / or placing queues for connection requests. In some embodiments, connection data structure 1102 could be used to identify indexable or searched node identifiers. For example, each connection request may indicate an endpoint through an endpoint identifier (for example, ΕΓ). In this example, when a thread, such as one of the setting wires 1104, strings or obtains a connection request from the connection data structure 1102, the wire may attempt to select a connection associated with a particular data identifier. end point.
The setting wire (s) 1104 represents one or more services, applications, or processes (for example, executing software on a processor) for obtaining connection requests from the data connection structure 1102 and for inspecting connection requests and / or returning connection requests or processing connection requests (for example, by establishing connections and / or providing test setup information). In some embodiments, each setting wire 1104 may be associated with a particular endpoint or test session. For example, a first setting wire 1104 can process the connection requests associated with an end point, E1 'and a second setting wire 1104 can process the connection requests associated with an end point, E2'.
In some embodiments, each of the setting wires 1104 may query or seek a connection request associated with a particular endpoint. If a connection request is found associated with a particular end point, the setting wire (s) 1104 can obtain more relevant requests (for example, the oldest request associated with the relevant end point) and can process them, for example, by accepting requesting and / or sending test configuration information through an accepted connection.
In some embodiments, if no connection request is found associated with a particular endpoint, the setting wire (s) 1104 may select or obtain an unassociated connection request, for example, a request that is not yet identified (by for example, by one of the setting wires 1104) as being associated with some endpoint identifier. After obtaining the connection request, can the setting wire (s) 1104 identify an end point associated with the request of <2014-- 009182? -11- 2014/25 connection. If the connection request is associated with the same end point with the setting wire (s) 1104, the setting wire (s) 1104 may continue processing the request.
In some embodiments, if the obtained connection request is not associated with the same end point as the setting wire 1104, the setting wire (s) 1104 may return the connection request to the connection data structure 1102, where the connection request returned can be indexed, using an identifier indicating the associated end point. After the connection request has been replaced, the setting wire (s) 1104 may attempt to obtain and process another connection request.
In some embodiments, the connection request returned with an associated end point can be obtained and processed by an appropriate setting wire 1104. For example, the setting wire (s) 1104 can query or search the connection data structure 1102 for a particular endpoint, which is associated with a returned connection request, and after it finds that the returned connection request is indexed by the endpoint, it can process the connection request.
Figure 12 is a diagram illustrating communication examples in a test network according to an embodiment of the invention described herein. In the embodiment illustrated in Figure 12, an endpoint 1200, a recording server 1202 and a console 1204 are illustrated. Endpoint 1200 may represent a node, including TCM 102 and / or a similar function for receiving test configuration information and generating test traffic, using test configuration information. In some embodiments, endpoint 1200 may include a function similar to endpoint 306 and / or proxy endpoint 308.
Registration server 1202 may represent a node capable of communicating with endpoint 1200 and console 1204. In some embodiments, registration server 1202 may receive and store node identification information from endpoint 1200. In some embodiments , registration server 1202 can receive test configuration information from console 1204 and can provide test configuration information at endpoint 1200. In some embodiments, the recording server 1202 may include functions similar to the recording server 302 and / or the proxy registration server 304.
<\- 2 0 1 4 - - 0 0 9 1 8 2 7 -11- 2014
<img file="RO131252A2_D0004.tif" />
Console 1204 may represent a node, including functions for generating and / or sending test configuration information to the registration server 1202. In some embodiments, console 1204 may be used to configure a test session, to receive test results. , to process and / or display them to a user. In some embodiments, the console 1204 may include functions similar to the console 310.
Referring to Figure 12, in step 1, a registration message can be sent from the endpoint 1200 to the registration server 1202. In some embodiments, the registration message may include node identification information, such as uploading an IP address. and port information.
In step 2, a record data structure (for example, record data structure 400) can be updated to include node identification information in the registration message.
In step 3, a registration validation message, indicating successful registration, can be sent from registration server 1202 to endpoint 1200.
In step 4, the query request can be sent from console 1204 to registration server 1202 to request node identification information associated with the available endpoints for testing purposes.
In step 5, after generating test setup information using node identification data, test setup information for a test session 1 can be sent from console 1204 to registration server 1204.
In step 6, the test configuration information for test session 1 can be stored and / or placed in the queue for forwarding to the relevant nodes.
In step 7, endpoint 1200 can be configured to wait for two seconds before sending a maintenance message to the recording server 1202.
In step 8, a maintenance message that includes node identification information can be sent from endpoint 1200 to registration server 1202.
In step 9, the recording server 1202 can inspect the node identification information associated with the maintenance message, to determine what relevant configuration testing information should be propagated to endpoint 1200.
In step 10, test setup information for test session 1 can be sent from the recording server 1202 to endpoint 1200. in some (Κ- 2 0 1 4 - - 0 0 9 1 8 l 7-11-11, 2014
<img file="RO131252A2_D0005.tif" />
In embodiments, test configuration information may include address and / or port information for communicating with the 1204 console and / or an intermediate node.
In step 11, a request is sent from endpoint 1200 to console 1204 to create a connection and / or to receive test setting information for test session 1.
In step 12, the test setup information can be sent from console 1204 to endpoint 1200 for creating and / or starting test session 1.
It will be appreciated that these communications shown in Figure 12 are illustrative and that different and / or additional actions may be used. It will also be appreciated that the different actions described here may occur in a different order or sequence.
Figure 13 is a diagram illustrating an example of a process for receiving information for testing configuration information 1300, according to an embodiment of the invention described herein. In some embodiments, the exemplified process or parts thereof may be performed by the computer platform 100 or at TCM 102 and / or another node or module.
In some embodiments, the exemplified method 1300 may include steps 1302.1304 and / or 1306.
With reference to method 1300, in step 1302, node identification information can be recorded to a registration server. For example, endpoint 1200 may send a registration request that contains node identification information to the registration server 1202. In this example, the registration server 1202 can receive registration requests, store the node's identifying information in a data structure, and send a response message to the record, indicating that endpoint 1200 is registered.
In step 1304, a maintenance message can be sent to the recording server. For example, after registering with the registration server 1202, the endpoint 1200 may periodically send a maintenance message to the registration server 1202.
In step 1306, in response to the maintenance message and through the registration server, information can be received by configuring the tests from an operating system outside the private network. For example, console 1204 can generate and transmit test configuration information to the recording server 1202, transmitting test configuration information to endpoint 1200. In this
0 14 - - 0 0 9 1 8 2 Ί -11- 2014 example, in response to receiving a maintenance message from the end point
1200, registration server 1202 can send test configuration information (for example, address information, associated with the operating system), in an endpoint response message 1200.
In some embodiments, before an endpoint (eg, endpoint 1200) receives test configuration information from an operating system (eg, console 1204), outside the private network, the operating system may be configured to request node identification information from the registration server to generate, using node identification data, test configuration information and send it to the registration server.
In some embodiments, after receiving test configuration information from an operating system outside the private network, the test configuration information may be sent to one or more nodes in the private network. For example, in response to receiving, through registration server 302, testing configuration information from console 310, registration server 304 may send testing configuration information to endpoint 306.
In some embodiments, after receiving test configuration information from an operating system outside the private network, a node may be configured to initiate, using test configuration data, a connection to the operating system or to an intermediate node associated with the operating system, to receive additional information about testing setup. For example, endpoint 306 may communicate with proxy endpoint 308, using an IP address and port number provided by the registration server 304, and proxy endpoint 308 may communicate with console 310 to receive test configuration information and it can supply them to the end point 306.
In some embodiments, after receiving test configuration information from an operating system separate from the private network, a node may be configured for testing using test configuration information. For example, in response to receiving, through the registration server 302, testing information from the console 310, endpoint 308 can be configured for testing using test configuration data.
In some embodiments, an operating system (for example, console 310 or console 1204) may be configured to receive, from a node, a connection request containing node identification information, to store, through a thread <-2014-- 009182 7 -11- 2014
IM monitoring, the request for connection in a data structure, to select, by an installation thread, the request for connection from the data structure; to inspect, by the installation thread, the node identification data associated with the connection request; to decide, through the installation thread and using node identification information, whether the setting thread should process the connection request, and in response, decide whether the installation thread should process the connection request, to process it, through the setting wire.
In some embodiments, in response to the decision that a setting thread should not process a connection request, it may be stored in a data structure with the node's identifying information as the key, in which a different thread selects request connection using the key.
In some embodiments, a node receiving test configuration information may be located behind a firewall that blocks direct communications sent from an operating system. For example, while the recording server 1202 may be able to communicate directly with endpoint 1200 (for example, through a firewall device), direct communications sent from console 1204 to endpoint 1200 may be blocked or removed ( for example, by a firewall device).
In some embodiments, node identification information may include a name, version identifier, operating system identifier, platform identifier, address information and / or port information.
In some embodiments, a node that receives test configuration information may include an endpoint, a proxy endpoint, a proxy recording server, a recording server, and / or a proxy node.
In some embodiments, test configuration information may include information about a test session, node identification information, address information associated with an operating system, and port information associated with the operating system, information about one or more peer-topeer entries for one or more nodes associated with the test session and / or information about one or more peer-to-peer outputs for one or more nodes associated with the test session.
It will be appreciated that the exemplified procedure 1300 is illustrative and that different and / or additional actions may be used. It will also be appreciated that the different actions described here may occur in a different order or sequence.
¢ (-2014-- 0 0 9 1 8 2 7-Π-2014 / l®
It should be noted that the computer platform 100, TCM 102 and / or the function described herein may be a device specially designed for computational purposes. Furthermore, the computer platform 100, TCM 102 and / or the function described herein may improve the technology of the network node testing domain by providing mechanisms for providing and / or receiving information for configuring the tests on a private network, for example, using a recording server.
The object of the invention described herein for receiving test configuration information enhances the operation of test platforms and / or test instruments, by providing mechanisms for communicating test configuration information to nodes in a private network (for example, nodes behind a network). firewall device and / or NAT device), without the need to open additional ports or translate addresses.
It should also be noted that the computer platform that implements the objects of the invention described herein may comprise a special computer device (for example, a traffic generator), useful in receiving information from test setup.
It will be understood that the various details of the invention described herein may be modified without departing from the scope described herein. Moreover, the above description is merely illustrative and not limiting, since the invention described herein is defined by the claims set forth below.
Contents6
13 sheets
Sheet 1 Sheet 2 Sheet 3 Sheet 4 Sheet 5 Sheet 6 Sheet 7 Sheet 8 Sheet 9 Sheet 10 Sheet 11 Sheet 12 Sheet 13
3 members in 2 offices
Priority claims2
| Document | Office | Kind | Date |
|---|---|---|---|
| 201400918 | Romania | A | |
| RO20140000918 | – | – | – |
Members3
| Document | Office | Kind | |
|---|---|---|---|
| US2016156541A1 | United States of America | A1 | |
| RO131252A2This record | Romania | A2 | |
| US10097442B2 | United States of America | B2 |
Numbers
- Publication
- 131252
- Publication, DOCDB
- 131252
- Publication, EPODOC
- RO131252
- Application
- 918
- Application, DOCDB
- 201400918
- Application, EPODOC
- RO20140000918
Titles2
- English
- METHODS, SYSTEMS AND COMPUTER-READABLE MEDIUM FOR RECEIVING TEST CONFIGURATION INFORMATION
- Romanian
- METODE, SISTEME ŞI SUPORT CITIBIL PE CALCULATOR PENTRU RECEPŢIONAREA INFORMAŢIILOR DE CONFIGURARE A TESTĂRILOR
Classification
- CPC, 5
- H04L43/50
- H04L41/0806
- H04L41/28
- H04L43/10
- H04L63/10
- IPC, 1
- H04L12 26