WO2014074097A1 - Confirming a status of an apparatus in a data communication network - Google Patents

Confirming a status of an apparatus in a data communication network Download PDF

Info

Publication number
WO2014074097A1
WO2014074097A1 PCT/US2012/064168 US2012064168W WO2014074097A1 WO 2014074097 A1 WO2014074097 A1 WO 2014074097A1 US 2012064168 W US2012064168 W US 2012064168W WO 2014074097 A1 WO2014074097 A1 WO 2014074097A1
Authority
WO
WIPO (PCT)
Prior art keywords
status check
node
network manager
status
flag
Prior art date
Application number
PCT/US2012/064168
Other languages
French (fr)
Inventor
David Campbell TAYLOR
William James SULLIVAN
Original Assignee
Ambient Corporation
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Ambient Corporation filed Critical Ambient Corporation
Priority to PCT/US2012/064168 priority Critical patent/WO2014074097A1/en
Publication of WO2014074097A1 publication Critical patent/WO2014074097A1/en

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • H04L43/08Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0805Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability
    • H04L43/0817Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability by checking functioning
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • H04L43/10Active monitoring, e.g. heartbeat, ping or trace-route
    • H04L43/103Active monitoring, e.g. heartbeat, ping or trace-route with adaptive polling, i.e. dynamically adapting the polling rate

Definitions

  • the present disclosure relates to data communication, and more particularly, to a network manager that confirms online statuses of apparatuses in a data communication network.
  • a data communication network may be configured to include a network manager and a plurality of other apparatuses, e.g. nodes, where the network manager needs to periodically confirm the online statuses of the nodes. For example with respect to a particular node, the network manager will send, to the node, a status check request, and receive, from the node, a status check response.
  • the communication of the status check request and the status check response is an expense in terms of network traffic and processing overhead. Additionally, a service provider of the data communication network may levy a charge for each message communicated via the data communication network. Moreover, since the network manager periodically confirms that each of the nodes is online, these expenses can be recurring. Also, the total amount of these expenses tends to increase as the number of nodes increases. Thus, it is desirable to minimize the number of status check
  • a method that includes (i) setting a flag to indicate that a status check of an apparatus is required, (ii) initializing a timer for a status check interval, where the timer counts toward a terminal time, (iii) clearing the flag to indicate that the status check is not required, in response to a receipt of a message from the apparatus during the status check interval, and (iv) sending a status request to the apparatus in response to a determination that (a) the timer has reached the terminal time, and (b) the flag indicates that the status check is required.
  • a system that performs the method, and a storage device that contains instructions for controlling a processor to perform the method.
  • An advantageous effect of the method is that it reduces network traffic and processing overhead of the network manager and the nodes. Additionally, in a case where a service provider of the data communication network levies a charge for each message communicated via the data communication network, the method minimizes the cost of utilization of the data communication network.
  • FIG. 1 is a data flow diagram of data communication in a system that includes a network manager, and a plurality of apparatuses whose online statuses need to be periodically confirmed by the network manager.
  • FIG. 2 is a block diagram of a data structure that is maintained by the network manager of FIG. 1.
  • FIGS. 3A and 3B are a flowchart of a method that is performed by the network manager of FIG. 1.
  • FIG. 4 is a block diagram of an embodiment of the network manager of FIG. 1.
  • FIG. 1 is a data flow diagram of data communication in a data communication network 100.
  • Data communication network 100 includes a network manager 105, a data communication network, i.e., a data network 110, and a plurality of apparatuses designated as nodes 125a - 125m and collectively represented as nodes 125.
  • Network manager 105 communicates with nodes 125a - 125m via data network 110.
  • Network manger 105 wishes to periodically confirm that each of nodes 125a - 125m is on-line, that is, active and communicating via data network 110. For example, one way for network manager 105 to confirm that node 125a is online is for network manager 105 to send to node 125a a status request, i.e., a status check request 115a, and receive from node 125a a status check response 120a. Similarly, for network manager 105 to confirm that node 125m is online, network manager 105 sends to node 125m a status check request 115m, and receives from node 125m a status check response 120m. Network manager 105 can engage in similar communications with others of nodes 125.
  • Another way for network manager 105 to confirm that node 125a is online is by receiving a message 116a from node 125a from which network manager 105 can infer that node 125a is online.
  • Message 116a need not be specifically for indicating a status of node 125a, but instead can be any message from which network manager 105 can infer that node 125a is online.
  • network manager 105 need not send status check request 115a.
  • Network manager 105 will draw similar conclusions about the statuses of each of nodes 125a - 125m, based on messages received from those nodes.
  • FIG. 2 is a block diagram of a data structure, designated as a status check list 200, that is maintained by network manager 105 to keep track of the statuses of nodes 125a - 125m, and more specifically, to keep track of whether network manager 105 needs to issue a status check request to any of nodes 125a - 125m.
  • Status check list 200 includes a node object 205a - 205m for each node 125a - 125m, respectively.
  • Node object 205a includes a Node ID 210a and a Needed flag 215a.
  • Node ID 210a is an identifier of node 125a.
  • Needed flag 215a is an indicator of whether node 125a needs a status check. When Needed flag 215a is set, e.g., set to TRUE, it indicates that node 125a needs a status check. When Needed flag 215a is clear, e.g., set to FALSE, it indicates that node 125a does not need a status check.
  • the other node objects in status check list 200 are structured similarly to node object 205a.
  • node object 205m includes a Node ID 210m and a Needed flag 215m.
  • FIGS. 3A and 3B are a flowchart of a method 300 that is performed by network manager 105, for checking of statuses of nodes 125. Method 300 commences with step 305.
  • step 305 network manager 105 gets status check list 200. From step 305, method 300 progresses to step 310.
  • step 310 for each node object in status check list 200, i.e., for each node object 205a - 205m, network manager 105, sets the Needed flag to TRUE, thus indicating that a status check is needed for each of nodes 125a - 125m. From step 310, method 300 progresses to step 315.
  • step 315 network manager 105 initializes a status check interval timer 316.
  • network manager 105 wishes to periodically confirm that each of nodes 125 is on-line.
  • Status check interval timer 316 is a timer that counts toward a terminal time that, when attained, indicates that it is time for network manager 105 to check the statuses of nodes 125. From step 315, method 300 progresses to step 320.
  • step 320 network manager 105 inquires as to whether it is time to perform a status check of nodes 125.
  • network manager 105 checks whether status check interval timer 316 has reached its terminal time. If status check interval timer 316 has not yet reached its terminal time, i.e., it is not yet time to perform a status check, method 300 progresses to step 325. If status check interval timer 316 has reached its terminal time, i.e., it is time to perform a status check, method 300 progresses to step 345.
  • the flow from step 320 to step 345 is indicated by way of a connector labeled "A".
  • step 320 to step 325 is part of a processing loop that returns to step 320, and that is repeatedly executed until, in step 320, status check interval timer 316 is recognized as having reached its terminal time.
  • step 325 network manager 105 checks whether it has received a message from any of nodes 125 since the time of the last execution of step 325. The reason for this check if that if network manager 105 receives a message from a node during the status check interval, then network manager 105 can infer that the node is online, and as such, network manager 105 need not send a status request to the node during the status check interval. If network manager 105 has not received a message from any of nodes 125 since the time of the last execution of step 325, then from step 325, method 300 loops back to step 320. If network manager 105 has received a message from any of nodes 125 since the time of the last execution of step 325, then from step 325, method 300 progresses to step 330.
  • step 330 network manager 105 gets a Node ID from the received message.
  • the node ID identifies the node that sent the message.
  • network manager 105 receives message 116a. Accordingly, from message 116a, network manager 105 will extract a Node ID 332, which in this case identifies node 125a as the sender of message 116a. From step 330, method 300 progresses to step 335.
  • step 335 network manager 105 finds the node object in status check list 200 that has the same Node ID as that of the received message. For example, since Node ID 332 identifies node 125a, and since Node ID 201a identifies node 125a, network manager 105 will find node object 205a. From step 335, method 300 progresses to step 340.
  • step 340 for the node object in status check list 200 that has the same Node ID as that of the received message, network manager 105 will set the Needed flag to FALSE, thus indicating that for the present status check interval, it will not be necessary for network manager 105 to issue a status request for the node that is identified by that Node ID. For example, in response to receipt of message 116a, network manager 105 will clear, i.e., set to FALSE, Needed flag 215a, indicating that for the present status check interval, it will not be necessary for network manager 105 to issue status check request 115a. From step 340, method 300 loops back to step 320.
  • step 345 which is entered from step 320 in a case where status check interval timer 316 has reached its terminal time, network manager 105 gets the first node object, i.e., node object 205a, from status check list 200.
  • the first node object will now be regarded as a node object under consideration. From step 345, method 300 progresses to step 350.
  • step 350 network manager 105 examines the Needed flag in the node object under consideration. If the Needed flag is TRUE, method 300 progresses from step 350 to step 355. If the Needed flag is FALSE, method 300 from step 350 progresses to step 360.
  • step 355 since in the node object under consideration the Needed flag is TRUE, i.e., indicating that the node requires a status check, network manager 105 sends a status request to the node that is identified in the Node ID of the node object under consideration.
  • step 355 is being executed because network manager 105 has determined that (a) in step 320, status check interval timer 316 has reached its terminal time, and (b) in step 350, in the node object under consideration, the Needed flag is TRUE, thus indicating that a status check is required for the node that is identified by the Node ID. From step 355, method 300 progresses to step 365.
  • step 360 since in the node object under consideration the Needed flag is FALSE, i.e., indicating that the node does not require a status check, network manager 105 will not send a status request. In the node object under consideration, network manager 105 sets the Needed flag to TRUE. An explanation of the reason for setting the Needed flag to TRUE is provided a couple of paragraphs below. From step 360, method 300 progresses to step 365.
  • step 365 network manager 105 determines whether there are any more node objects in status check list 200 that need to be considered. If there are more node objects to be considered, method 300 progresses from step 365 to step 370. If there are no more node objects to be considered, method 300 loops back from step 365 to step 315. The flow from step 365 to step 315 is indicated by way of a connector labeled "B".
  • step 365 for the loop back to step 315, all of the Needed flags in all of the node objects 205a - 205m of status check list 200 will be TRUE. This is because upon entry to step 315, where network manager 105 next initializes status check interval timer 316, all of the nodes should be designated as being in need of a status check.
  • step 370 network manager 105 gets the next node object from status check list 200. From step 370, method 300 loops back to step 350.
  • FIG. 4 is a block diagram of an embodiment of network manager 105.
  • Network manager 105 includes a processor 405 and a memory 410.
  • Processor 405 is an electronic device configured of logic circuitry that responds to and executes instructions. In the present document, although we describe operations being performed by method 300 or network manager 105, the operations are actually being performed by processor 405.
  • Memory 410 is a tangible computer-readable storage medium encoded with a computer program.
  • memory 410 stores data and instructions that are readable and executable by processor 405 for controlling the operation of processor 405.
  • Memory 410 may be implemented in a random access memory (RAM), a hard drive, a read only memory (ROM), or a combination thereof.
  • RAM random access memory
  • ROM read only memory
  • One of the components of memory 410 is a program module 415.
  • Program module 415 contains instructions for controlling processor 405 to execute method 300. For example, under control of program module 415, processor 405 (i) sets Needed flag 215a to indicate that a status check of node 125a is required, (ii) initializes status check interval timer 316 for a status check interval, where status check interval timer 316 counts toward a terminal time, (iii) clears Needed flag 215a to indicate that the status check of node 125a is not required, in response to a receipt of a message, e.g., message 116a, from node 125a during the status check interval; and (iv) sends a status check request 115a to node 125a in response to a determination that (a) status check interval timer 316 has reached its terminal time, and (b) Needed flag 215a indicates that the status check of node 125a is required.
  • module is used herein to denote a functional operation that may be embodied either as a stand-alone component or as an integrated configuration of a plurality of subordinate components.
  • program module 415 may be implemented as a single module or as a plurality of modules that operate in cooperation with one another.
  • program module 415 is described herein as being installed in memory 410, and therefore being implemented in software, it could be implemented in any of hardware (e.g., electronic circuitry), firmware, software, or a combination thereof.
  • Storage device 420 is a tangible computer-readable storage medium that stores program module 415 thereon. Examples of storage device 420 include a compact disk, a magnetic tape, a read only memory, an optical storage media, a hard drive or a memory unit consisting of multiple parallel hard drives, and a universal serial bus (USB) flash drive. Alternatively, storage device 420 can be a random access memory, or other type of electronic storage device, located on a remote storage system and coupled to network manager 105 via data network 110 or another network (not shown) such as the Internet.
  • status check interval timer 316 can be implemented in either hardware or software, and steps associated with the processes described herein can be performed in any order, unless otherwise specified or dictated by the steps themselves.
  • present disclosure is intended to embrace all such alternatives, modifications and variances that fall within the scope of the appended claims.

Abstract

There is provided a method that includes (i) setting a flag to indicate that a status check of an apparatus is required, (ii) initializing a timer for a status check interval, where the timer counts toward a terminal time, (iii) clearing the flag to indicate that the status check is not required, in response to a receipt of a message from the apparatus during the status check interval, and (iv) sending a status request to the apparatus in response to a determination that (a) the timer has reached the terminal time, and (b) the flag indicates that the status check is required. There is also provided a system that performs the method, and a storage device that contains instructions for controlling a processor to perform the method.

Description

CONFIRMING A STATUS OF AN APPARATUS IN A DATA
COMMUNICATION NETWORK
BACKGROUND OF THE INVENTION
1. Field of the Invention
[0001] The present disclosure relates to data communication, and more particularly, to a network manager that confirms online statuses of apparatuses in a data communication network.
2. Description of the Related Art
[0002] The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued.
Therefore, the approaches described in this section may not be prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
[0003] A data communication network may be configured to include a network manager and a plurality of other apparatuses, e.g. nodes, where the network manager needs to periodically confirm the online statuses of the nodes. For example with respect to a particular node, the network manager will send, to the node, a status check request, and receive, from the node, a status check response.
[0004] The communication of the status check request and the status check response is an expense in terms of network traffic and processing overhead. Additionally, a service provider of the data communication network may levy a charge for each message communicated via the data communication network. Moreover, since the network manager periodically confirms that each of the nodes is online, these expenses can be recurring. Also, the total amount of these expenses tends to increase as the number of nodes increases. Thus, it is desirable to minimize the number of status check
communications between the network manager and the nodes.
SUMMARY OF THE INVENTION
[0005] It is an object of the present invention to provide for a method that minimizes the number of status check communications between a network manager and nodes in a data communication network. To fulfill this objective, there is provided a method that includes (i) setting a flag to indicate that a status check of an apparatus is required, (ii) initializing a timer for a status check interval, where the timer counts toward a terminal time, (iii) clearing the flag to indicate that the status check is not required, in response to a receipt of a message from the apparatus during the status check interval, and (iv) sending a status request to the apparatus in response to a determination that (a) the timer has reached the terminal time, and (b) the flag indicates that the status check is required. There is also provided a system that performs the method, and a storage device that contains instructions for controlling a processor to perform the method.
[0006] An advantageous effect of the method is that it reduces network traffic and processing overhead of the network manager and the nodes. Additionally, in a case where a service provider of the data communication network levies a charge for each message communicated via the data communication network, the method minimizes the cost of utilization of the data communication network.
BRIEF DESCRIPTION OF THE DRAWINGS
[0007] FIG. 1 is a data flow diagram of data communication in a system that includes a network manager, and a plurality of apparatuses whose online statuses need to be periodically confirmed by the network manager. [0008] FIG. 2 is a block diagram of a data structure that is maintained by the network manager of FIG. 1.
[0009] FIGS. 3A and 3B, together, are a flowchart of a method that is performed by the network manager of FIG. 1.
[0010] FIG. 4 is a block diagram of an embodiment of the network manager of FIG. 1.
[0011] A component or a feature that is common to more than one drawing is indicated with the same reference number in each of the drawings.
DESCRIPTION OF THE INVENTION
[0012] FIG. 1 is a data flow diagram of data communication in a data communication network 100. Data communication network 100 includes a network manager 105, a data communication network, i.e., a data network 110, and a plurality of apparatuses designated as nodes 125a - 125m and collectively represented as nodes 125. Network manager 105 communicates with nodes 125a - 125m via data network 110.
[0013] Network manger 105 wishes to periodically confirm that each of nodes 125a - 125m is on-line, that is, active and communicating via data network 110. For example, one way for network manager 105 to confirm that node 125a is online is for network manager 105 to send to node 125a a status request, i.e., a status check request 115a, and receive from node 125a a status check response 120a. Similarly, for network manager 105 to confirm that node 125m is online, network manager 105 sends to node 125m a status check request 115m, and receives from node 125m a status check response 120m. Network manager 105 can engage in similar communications with others of nodes 125.
[0014] However, with the communication of status check requests 115a and 115m, and status check responses 120a and 120m there is an expense in terms of network traffic through data network 110, and processing overhead for each of network manager 105, and nodes 125a and 125m. Additionally, a service provider of data network 110 may levy a charge for each message communicated via data network 110. Moreover, since network manager 105 periodically confirms that each of nodes 125a - 125m is online, these expenses can be recurring. Also, the total amount of these expenses tends to increase as the number of nodes 125 increases. Thus, it is desirable to minimize the number of status check communications between network manager 105 and nodes 125.
[0015] Another way for network manager 105 to confirm that node 125a is online is by receiving a message 116a from node 125a from which network manager 105 can infer that node 125a is online. Message 116a need not be specifically for indicating a status of node 125a, but instead can be any message from which network manager 105 can infer that node 125a is online. Thus, if network manager 105 receives message 116a, network manager 105 need not send status check request 115a. Network manager 105 will draw similar conclusions about the statuses of each of nodes 125a - 125m, based on messages received from those nodes.
[0016] FIG. 2 is a block diagram of a data structure, designated as a status check list 200, that is maintained by network manager 105 to keep track of the statuses of nodes 125a - 125m, and more specifically, to keep track of whether network manager 105 needs to issue a status check request to any of nodes 125a - 125m. Status check list 200 includes a node object 205a - 205m for each node 125a - 125m, respectively.
[0017] Node object 205a includes a Node ID 210a and a Needed flag 215a. Node ID 210a is an identifier of node 125a. Needed flag 215a is an indicator of whether node 125a needs a status check. When Needed flag 215a is set, e.g., set to TRUE, it indicates that node 125a needs a status check. When Needed flag 215a is clear, e.g., set to FALSE, it indicates that node 125a does not need a status check. The other node objects in status check list 200 are structured similarly to node object 205a. For example, in this regard, node object 205m includes a Node ID 210m and a Needed flag 215m. [0018] FIGS. 3A and 3B, together, are a flowchart of a method 300 that is performed by network manager 105, for checking of statuses of nodes 125. Method 300 commences with step 305.
[0019] In step 305, network manager 105 gets status check list 200. From step 305, method 300 progresses to step 310.
[0020] In step 310, for each node object in status check list 200, i.e., for each node object 205a - 205m, network manager 105, sets the Needed flag to TRUE, thus indicating that a status check is needed for each of nodes 125a - 125m. From step 310, method 300 progresses to step 315.
[0021] In step 315, network manager 105 initializes a status check interval timer 316. As mentioned above, network manager 105 wishes to periodically confirm that each of nodes 125 is on-line. Status check interval timer 316 is a timer that counts toward a terminal time that, when attained, indicates that it is time for network manager 105 to check the statuses of nodes 125. From step 315, method 300 progresses to step 320.
[0022] In step 320, network manager 105 inquires as to whether it is time to perform a status check of nodes 125. In this regard, network manager 105 checks whether status check interval timer 316 has reached its terminal time. If status check interval timer 316 has not yet reached its terminal time, i.e., it is not yet time to perform a status check, method 300 progresses to step 325. If status check interval timer 316 has reached its terminal time, i.e., it is time to perform a status check, method 300 progresses to step 345. The flow from step 320 to step 345 is indicated by way of a connector labeled "A".
[0023] Note that in method 300, the progression from step 320 to step 325 is part of a processing loop that returns to step 320, and that is repeatedly executed until, in step 320, status check interval timer 316 is recognized as having reached its terminal time.
[0024] In step 325, network manager 105 checks whether it has received a message from any of nodes 125 since the time of the last execution of step 325. The reason for this check if that if network manager 105 receives a message from a node during the status check interval, then network manager 105 can infer that the node is online, and as such, network manager 105 need not send a status request to the node during the status check interval. If network manager 105 has not received a message from any of nodes 125 since the time of the last execution of step 325, then from step 325, method 300 loops back to step 320. If network manager 105 has received a message from any of nodes 125 since the time of the last execution of step 325, then from step 325, method 300 progresses to step 330.
[0025] In step 330, network manager 105 gets a Node ID from the received message. The node ID identifies the node that sent the message. For example, and for the next several steps, assume that network manager 105 received message 116a. Accordingly, from message 116a, network manager 105 will extract a Node ID 332, which in this case identifies node 125a as the sender of message 116a. From step 330, method 300 progresses to step 335.
[0026] In step 335, network manager 105 finds the node object in status check list 200 that has the same Node ID as that of the received message. For example, since Node ID 332 identifies node 125a, and since Node ID 201a identifies node 125a, network manager 105 will find node object 205a. From step 335, method 300 progresses to step 340.
[0027] In step 340, for the node object in status check list 200 that has the same Node ID as that of the received message, network manager 105 will set the Needed flag to FALSE, thus indicating that for the present status check interval, it will not be necessary for network manager 105 to issue a status request for the node that is identified by that Node ID. For example, in response to receipt of message 116a, network manager 105 will clear, i.e., set to FALSE, Needed flag 215a, indicating that for the present status check interval, it will not be necessary for network manager 105 to issue status check request 115a. From step 340, method 300 loops back to step 320.
[0028] In step 345, which is entered from step 320 in a case where status check interval timer 316 has reached its terminal time, network manager 105 gets the first node object, i.e., node object 205a, from status check list 200. The first node object will now be regarded as a node object under consideration. From step 345, method 300 progresses to step 350.
[0029] In step 350, network manager 105 examines the Needed flag in the node object under consideration. If the Needed flag is TRUE, method 300 progresses from step 350 to step 355. If the Needed flag is FALSE, method 300 from step 350 progresses to step 360.
[0030] In step 355, since in the node object under consideration the Needed flag is TRUE, i.e., indicating that the node requires a status check, network manager 105 sends a status request to the node that is identified in the Node ID of the node object under consideration. Note that step 355 is being executed because network manager 105 has determined that (a) in step 320, status check interval timer 316 has reached its terminal time, and (b) in step 350, in the node object under consideration, the Needed flag is TRUE, thus indicating that a status check is required for the node that is identified by the Node ID. From step 355, method 300 progresses to step 365.
[0031] In step 360, since in the node object under consideration the Needed flag is FALSE, i.e., indicating that the node does not require a status check, network manager 105 will not send a status request. In the node object under consideration, network manager 105 sets the Needed flag to TRUE. An explanation of the reason for setting the Needed flag to TRUE is provided a couple of paragraphs below. From step 360, method 300 progresses to step 365.
[0032] In step 365, network manager 105 determines whether there are any more node objects in status check list 200 that need to be considered. If there are more node objects to be considered, method 300 progresses from step 365 to step 370. If there are no more node objects to be considered, method 300 loops back from step 365 to step 315. The flow from step 365 to step 315 is indicated by way of a connector labeled "B".
[0033] Note that upon completion of either of steps 355 or 360, the Needed flag of the node under consideration is TRUE. Consequently, upon completion of step 365 for the loop back to step 315, all of the Needed flags in all of the node objects 205a - 205m of status check list 200 will be TRUE. This is because upon entry to step 315, where network manager 105 next initializes status check interval timer 316, all of the nodes should be designated as being in need of a status check.
[0034] In step 370, network manager 105 gets the next node object from status check list 200. From step 370, method 300 loops back to step 350.
[0035] FIG. 4 is a block diagram of an embodiment of network manager 105. Network manager 105 includes a processor 405 and a memory 410.
[0036] Processor 405 is an electronic device configured of logic circuitry that responds to and executes instructions. In the present document, although we describe operations being performed by method 300 or network manager 105, the operations are actually being performed by processor 405.
[0037] Memory 410 is a tangible computer-readable storage medium encoded with a computer program. In this regard, memory 410 stores data and instructions that are readable and executable by processor 405 for controlling the operation of processor 405. Memory 410 may be implemented in a random access memory (RAM), a hard drive, a read only memory (ROM), or a combination thereof. One of the components of memory 410 is a program module 415.
[0038] Program module 415 contains instructions for controlling processor 405 to execute method 300. For example, under control of program module 415, processor 405 (i) sets Needed flag 215a to indicate that a status check of node 125a is required, (ii) initializes status check interval timer 316 for a status check interval, where status check interval timer 316 counts toward a terminal time, (iii) clears Needed flag 215a to indicate that the status check of node 125a is not required, in response to a receipt of a message, e.g., message 116a, from node 125a during the status check interval; and (iv) sends a status check request 115a to node 125a in response to a determination that (a) status check interval timer 316 has reached its terminal time, and (b) Needed flag 215a indicates that the status check of node 125a is required.. [0039] The term "module" is used herein to denote a functional operation that may be embodied either as a stand-alone component or as an integrated configuration of a plurality of subordinate components. Thus, program module 415 may be implemented as a single module or as a plurality of modules that operate in cooperation with one another. Moreover, although program module 415 is described herein as being installed in memory 410, and therefore being implemented in software, it could be implemented in any of hardware (e.g., electronic circuitry), firmware, software, or a combination thereof.
[0040] While program module 415 is indicated as being already loaded into memory 410, it may be configured on a storage device 420 for subsequent loading into memory 410. Storage device 420 is a tangible computer-readable storage medium that stores program module 415 thereon. Examples of storage device 420 include a compact disk, a magnetic tape, a read only memory, an optical storage media, a hard drive or a memory unit consisting of multiple parallel hard drives, and a universal serial bus (USB) flash drive. Alternatively, storage device 420 can be a random access memory, or other type of electronic storage device, located on a remote storage system and coupled to network manager 105 via data network 110 or another network (not shown) such as the Internet.
[0041] The techniques described herein are exemplary, and should not be construed as implying any particular limitation on the present disclosure. It should be understood that various alternatives, combinations and modifications could be devised by those skilled in the art. For example, status check interval timer 316 can be implemented in either hardware or software, and steps associated with the processes described herein can be performed in any order, unless otherwise specified or dictated by the steps themselves. The present disclosure is intended to embrace all such alternatives, modifications and variances that fall within the scope of the appended claims.
[0042] The terms "comprises" or "comprising" are to be interpreted as specifying the presence of the stated features, integers, steps or components, but not precluding the presence of one or more other features, integers, steps or components or groups thereof. The terms "a" and "an" are indefinite articles, and as such, do not preclude embodiments having pluralities of articles.

Claims

WHAT IS CLAIMED IS:
1. A method comprising:
setting a flag to indicate that a status check of an apparatus is required;
initializing a timer for a status check interval, wherein said timer counts toward a terminal time;
clearing said flag to indicate that said status check is not required, in response to a receipt of a message from said apparatus during said status check interval; and
sending a status request to said apparatus in response to a determination that (a) said timer has reached said terminal time, and (b) said flag indicates that said status check is required.
2. A system comprising:
a processor; and
a memory that contains instructions that are readable by said processor to cause said processor to:
set a flag to indicate that a status check of an apparatus is required; initialize a timer for a status check interval, wherein said timer counts toward a terminal time;
clear said flag to indicate that said status check is not required, in response to a receipt of a message from said apparatus during said status check interval; and
send a status request to said apparatus in response to a determination that (a) said timer has reached said terminal time, and (b) said flag indicates that said status check is required.
3. A storage device comprising instructions that are readable by a processor to cause said processor to:
set a flag to indicate that a status check of an apparatus is required; initialize a timer for a status check interval, wherein said timer counts toward a terminal time;
clear said flag to indicate that said status check is not required, in response to a receipt of a message from said apparatus during said status check interval; and
send a status request to said apparatus in response to a determination that (a) said timer has reached said terminal time, and (b) said flag indicates that said status check is required.
PCT/US2012/064168 2012-11-08 2012-11-08 Confirming a status of an apparatus in a data communication network WO2014074097A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/US2012/064168 WO2014074097A1 (en) 2012-11-08 2012-11-08 Confirming a status of an apparatus in a data communication network

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/US2012/064168 WO2014074097A1 (en) 2012-11-08 2012-11-08 Confirming a status of an apparatus in a data communication network

Publications (1)

Publication Number Publication Date
WO2014074097A1 true WO2014074097A1 (en) 2014-05-15

Family

ID=50685027

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2012/064168 WO2014074097A1 (en) 2012-11-08 2012-11-08 Confirming a status of an apparatus in a data communication network

Country Status (1)

Country Link
WO (1) WO2014074097A1 (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107451796A (en) * 2017-08-07 2017-12-08 广州爱九游信息技术有限公司 Method, apparatus, equipment and the storage medium of aid in treatment cooperation service

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6212175B1 (en) * 1997-04-22 2001-04-03 Telxon Corporation Method to sustain TCP connection
US20060020686A1 (en) * 2004-07-22 2006-01-26 Liss Jonathan M Distributed messaging system and method for sharing network status data

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6212175B1 (en) * 1997-04-22 2001-04-03 Telxon Corporation Method to sustain TCP connection
US20060020686A1 (en) * 2004-07-22 2006-01-26 Liss Jonathan M Distributed messaging system and method for sharing network status data

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107451796A (en) * 2017-08-07 2017-12-08 广州爱九游信息技术有限公司 Method, apparatus, equipment and the storage medium of aid in treatment cooperation service
CN107451796B (en) * 2017-08-07 2021-09-10 阿里巴巴(中国)有限公司 Method, device, equipment and storage medium for auxiliary processing of cooperative service

Similar Documents

Publication Publication Date Title
CN106533805B (en) Micro-service request processing method, micro-service controller and micro-service architecture
CN105577722B (en) Point exchange method and device
CN108572898B (en) Method, device, equipment and storage medium for controlling interface
CN108540533B (en) Request answering method and device
CN105260655B (en) Method, device and system for starting protection of application program
US20210397483A1 (en) Evaluation device, evaluation method and evaluation program
CN110659142A (en) Message queue processing method and device, electronic equipment and storage medium
WO2019192133A1 (en) Electronic apparatus, data link risk pre-warning method, and storage medium
KR101768365B1 (en) Notification Failure Management Method and System for Subscription-Notification in M2M/IoT System
CN110333916B (en) Request message processing method, device, computer system and readable storage medium
CN113064740A (en) Message processing method and device
WO2014074097A1 (en) Confirming a status of an apparatus in a data communication network
US10567400B2 (en) Attack detection device, attack detection method, and non-transitory computer-readable recording medium
CN108241616B (en) Message pushing method and device
CN110413398B (en) Task scheduling method and device, computer equipment and storage medium
CN112804333A (en) Exception handling method, device and equipment for out-of-block node and storage medium
KR101696520B1 (en) Secure access system and operating method thereof
CN107005433B (en) Flow table entry timing processing method and device
CN114546926B (en) Core cluster synchronization, control method, data processing method, core, device and medium
CN113453371B (en) Method, base station, and computer storage medium for wireless communication
CN109361620B (en) Data sending method, device, equipment and storage medium
CN105264499B (en) Message treatment method, device and reception core in a kind of shared queue
JP2016024605A (en) Distributed processing method, processing server, and program
WO2022105560A1 (en) Service protection method, optical transport network device and storage medium
CN112308354A (en) System overload control method and device

Legal Events

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

Ref document number: 12888024

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 12888024

Country of ref document: EP

Kind code of ref document: A1