System, method and computer program product for monitoring and controlling network connections from a supervisory operating system

The present invention relates to computer networks and data processing systems, and in particular to systems, methods, and computer program products that monitor and control network connections from a management operating system.

Network computers that cooperate in arithmetic or realize communication systems such as SS7 have hardware failures in communication links, switches, hubs, and network hosts, and software failures in software that implements or uses communication protocols. easily influenced. As network speeds increase and quality demands from service providers increase, control bandwidth allocation, response to out-of-band events, and performance and security monitoring become crucial. However, with most network protocols, this type of functionality is not possible directly or efficiently. For example, TCP / IP, a widely used network protocol, is designed to tolerate timing fluctuations and therefore has no way to quickly recover from a network failure. In the operation of the network stack, the processing of timing events or out-of-band signals can be delayed by stack or operating system scheduling. There are also other drawbacks and disadvantages.

Non-Patent Document 1 describes the development of a virtual machine monitor (VMM) security kernel for the VAX architecture. The emphasis is on how to maintain the standard interfaces and applications of the VMS and ULTRIX-32 operating systems, while meeting the system hardware, microcode, and software to meet AI-level security requirements. Is it aimed at? The VAX security kernel supports multiple concurrent virtual machines on a single VAX system, providing sensitive data isolation and controlled sharing. However, computer networking has not been considered.

References related to other backgrounds include Patent Document 1 issued to Jacobs et al., Patent Document 2 issued to Agarwal et al., Patent Document 3 issued to Dingwall et al., And non-patent documents. 2 and are included.<patcit num="1"><text>U.S. Pat. No. 6,385,643</text></patcit><patcit num="2"><text>U.S. Pat. No. 5,958,010</text></patcit><patcit num="3"><text>U.S. Pat. No. 5,721,922</text></patcit><nplcit num="1"><text>Karger et al. "A Retrospective on the VAX VMM Security Kernel"</text></nplcit><nplcit num="2"><text>G. Bollella et al. "Support For Real-Time Computing Within General Purpose Operating System" === Copyright Notice === Part of this patent application contains material subject to copyright protection. The copyright holder does not object to the reproduction of this patent document or this patent disclosure by anyone, as long as it is done within the Patent and Trademark Office, but reserves all copyrights in all other cases. === Appendix for List of Computer Programs === Appendix for List of Computer Programs on Compact Discs Incorporating the Features of the Invention is the entire disclosure of the patent application claiming priority and specifying the source. It is filed with US Patent Application No. 10 / 226,106, which is a prior national application that is part of the specification of the present application. The files contained on this disc are: sourcecode apps ipv4 plugins 1net_ft.c, 7895, Aug 15 14:36; sourcecode apps ipv4 plugins Makefile, 713, Aug 15 14:36; sourcecode apps ipv4 plugins 1net_icmp.c, 13785, Aug 15 14:36; sourcecode apps ipv4 plugins 1net_udp.c, 11309, Aug 15 14:36; sourcecode apps ipv4 plugins 1net_tabldr.c, 999, Aug 15 14:36; sourcecode apps ipv4 1net_ipv4.c, 15626, Aug 15 14:36; sourcecode apps ipv4 Makefile, 541, Aug 15 14:36; sourcecode apps gpos lnet_gpos.c, 17258, Aug 15 14:36; sourcecode apps gpos Makefile, 466, Aug 15 14:36; sourcecode apps arp Makefile, 457, Aug 15 14:36; sourcecode apps arp lnet_arp.c, 10964, Aug 15 14:36; sourcecode scripts defconfig, 426, Aug 15 14:36; sourcecode scripts ft, 0, Aug 15 14:36; sourcecode scripts functions.sh, 7148, Aug 15 14:36; sourcecode scripts config.in, 1336, 35 Aug 15 14 : 36; sourcecode scripts test_udp, 3300, Aug 15 14:36; sourcecode scripts test_ip, 3271, Aug 15 14:36; sourcecode scripts Menuconfig, 30024, Aug 15 14:36; sourcecode scripts Configure, 12372, Aug 15 14:36 ; sourcecode scripts mkdep.c, 12136, Aug 15 14:36; sourcecode scripts Makefile, 1597, Aug 15 14:36; sourcecode scripts unload_arp, 659, Aug 15 14:36; sourcecode scripts load ip, 3008, Aug 15 14:36; sourcecode scripts test arp, 2077, Aug 15 14:36; sourcecode scripts load_arp, 1153, Aug 15 14:36; sourcecode scripts test_lnet, 3239, Aug 15 14:36; sourcecode scripts inslnet, 3885, Aug 15 14:36; sourcecode scripts localinfo, 372, Aug 15 14:36; sourcecode scripts hosts, 651, Aug 15 14:36; sourcecode scripts rrnlnet, 1124, Aug 15 14:36; sourcecode scripts ping, 2153, Aug 15 14:36; sourcecode scripts addip, 3173, Aug 15 14:36; sourcecode scripts unload_ip, 1137, Aug 15 14:36; sourcecode scripts msgbox.c, 2529, Aug 15 14:36; sourcecode scripts inputbox.c, 6179, Aug 15 14: 36; sourcecode scripts yesno.c, 3067, Aug 15 14:36; sourcecode scripts colors.h, 5384, Aug 15 14:36; sourcecode scripts checklist.c, 9584, Aug 15 14:36; sourcecode scripts menubox.c, 12716, Aug 15 14:36; sourcecode scripts dialog.h, 5936, Aug 15 14:36; sourcecode scripts textbox.c, 15584, Aug 15 14:36; sourcecode scripts util.c, 9604, Aug 15 14:36; sourcecode scripts lxdialog.c, 6023, Aug 15 14:36; sourcecode main lnet.c, 21899, Aug 15 14:36; sourcecode main Makefile, 172, Aug 15 14:36; sourcecode include lnet.h, 6253, Aug 15 14:36; sourcecode include lnet_udp.h, 3463, Aug 15 14:36; sourcecode include lnet icmp.h, 2856, Aug 15 14:36; sourcecode include lnet_arp .h, 1417, Aug 15 14:36; sourcecode include lnet_ipv4.h, 4172, Aug 15 14:36; sourcecode include lnet_hw.h, 1673, Aug 15 14:36; sourcecode include lnet_gpos.h, 1435, Aug 15 14:36; sourcecode doc api. txt, 7841, Aug 15 14:36; sourcecode doc ipv4.txt, 6923, Aug 15 14:36; sourcecode doc udp.txt, 4171, Aug 15 14:36; sourcecode doc arp.txt, 2664, Aug 15 14: 36; sourcecode doc icmp.txt, 4136, Aug 15 14:36; sourcecode doc gpos.txt, 5055, Aug 15 14:36; sourcecode doc faq.txt, 4855, Aug 15 14:36; sourcecode doc getting_started.txt, 3690, Aug 15 14:36; sourcecode doc configuration.txt, 1847, Aug 15 14:36; sourcecode doc scripts.txt, 2663, Aug 15 14:36; sourcecode doc Configure. help, 4154, Aug 15 14:36; sourcecode GNUmakefile, 4188, Aug 15 14:36; sourcecode drivers lnet_pcnet32.c, 21711, Aug 15 14:36; sourcecode drivers lnet_3c905.c, 34753, Aug 15 14:36; sourcecode drivers lnet_eeprolOO.c, 30847, Aug 15 14:36; sourcecode drivers Makefile, 624, Aug 15 14:36; sourcecode tests lnet_arp_test lnet_arp_test.c, 2039, Aug 15 14:36; sourcecode tests lnet_arp_test Makefile, 488, Aug 15 14 : 36; sourcecode tests lnet_ip_test lnet_ip_test.c, 10396, Aug 15 14:36; sourcecode tests lnet_ip_test Makefile, 483, Aug 15 14:36; sourcecode tests lnet_ping lnet_ping.c, 6487, Aug 15 14:36; sourcecode tests lneting Makefile, 465, Aug 15 14:36; sourcecode tests lnet_udp_test lnet_udp_test.c, 10254, Aug 15 14:36; sourcecode tests lnet_udp_test Makefile, 488, Aug 15 14:36; sourcecode tests lnet_test lnet_test.c, 9744, Aug 15 14:36; sourcecode tests lnet_test Makefile, 181, Aug 15 14:36; sourcecode skeletons lnet_ipv4_plugin .c, 4926, Aug 15 14:36; sourcecode skeletons lnet_driver.c, 22332, Aug 15 14:36; sourcecode skeletons lnet_decoupled_app.c, 5523, Aug 15 14:36; sourcecode skeletons lnet_simple_app.c, 4510, Aug 15 14:36; sourcecode skeletons Makefile, 284, Aug 15 14:36; sourcecode Rules.make, 188, Aug 15 14:36; sourcecode Copyright, 76, Aug 15 14:37.</text></nplcit>

<p> An object of the present invention is to allow a system to monitor and control a network environment.</p><p> Another object of the present invention is to enable a system to provide high availability, rapid failure recovery, out-of-band condition signaling, and / or other service quality assurance and security in a network environment.</p><p> Another object of the present invention is to allow a system to detect and prevent network-based attacks, such as denial of service attacks.</p>

<p> The above and other objects are achieved by the present invention. In one aspect, the methods of the invention include a processing system (eg, a general purpose computer, a purpose-built computer, a network router, a network switch, or other processing device) with at least two, referred to as a management operating system and a secondary operating system. Includes steps to provide an operating system. In one embodiment, the secondary operating system is a task managed by the management operating system. The management system may be a real-time operating system, but this is not a requirement.</p><p> The method further comprises providing network control software (NCS) to the management operating system. NCS is an application for the management operating system and is inserted between the hardware network device driver and the network client for the secondary operating system. Such network clients may communicate directly with NCS via the protocol stack of the secondary operating system or, for example, using shared memory or a pseudo-device interface. NCS can also communicate with clients in the secondary operating system by reading and modifying state information in the secondary operating system and in the client application software.</p><p> Since NCS is inserted between the hardware network device driver and the network client of the secondary operating system, NCS may be configured to monitor and control network behavior in the secondary operating system. For example, NCS monitors and / or controls the communication channels of secondary operating systems, provides fast failover, provides protection from network-based attacks, and reduces resource contention in critical services. It can be configured to provide the system.</p><p> In one embodiment, NCS may monitor and control the network environment. For example, NCS may collect information from a network client message stream and a protocol stack implemented in a secondary operating system. NCS can operate across the boundaries of the secondary operating system's protocol stack. For example, NCS can collect information about the timing of protocols implemented in secondary operating systems, even if the protocols themselves do not track this information. NCS can insert control information into and / or retrieve this information from the data stream, and NCS can operate various protocols within the secondary operating system. Even if they are logically unrelated, they may be associated and coordinated.</p><p> Further, in embodiments where the management operating system is a real-time operating system, NCS can act to enforce precise timing on the action of NCS through the real-time capabilities of the management operating system. For example, NCS may be configured to send periodic state updates to adjacent computer systems at precise intervals. In addition, NCS can inspect and modify the state of protocol stacks and network clients in secondary operating systems. For example, NCS may utilize the advanced TCP or T / TCP stack of the secondary operating system, but avoids wasting resources if NCS detects conditions that the TCP or T / TCP protocol cannot detect. Can intervene for.</p>

<p> One of the advantages of NCS applications is the ability to transparently add capabilities that enhance the existing network stack and applications of secondary operating systems. For example, instead of modifying a complex and highly tuned T / TCP protocol stack to try to prioritize transactions with a particular remote computer, use NCS, for example, from a low priority computer. You can enforce these priorities on the T / TCP stack of the secondary operating system by transparently discarding or delaying messages to the T / TCP stack.</p><p> Hereinafter, the above and other features and advantages of the present invention and the structures and steps of preferred embodiments of the present invention will be described with reference to the accompanying drawings.</p><p> The accompanying drawings, which are incorporated herein by reference and form a portion thereof, exemplify various embodiments of the present invention, further clarify the principles of the present invention with explanations, and prepare and use the present invention by those skilled in the art. Play a role in enabling. In the drawings, similar reference numerals indicate identical or functionally similar elements. In addition, the leftmost digit of the reference code identifies the drawing in which the reference code first appears.</p>

Although the invention can be practiced in many different embodiments, it is said herein that the disclosure is considered an example of the principles of the invention and the invention is not limited to the exemplified embodiments. Given that, exemplary embodiments will be described in detail.

FIG. 1 is a block diagram illustrating an embodiment of a computer system 101 according to the present invention. The computer system 101 includes a management operating system 104 and a secondary operating system 106. The secondary operating system 106 provides network services to application 140 (also known as a "network client") via one or more protocol stacks 150. For example, through the network service provided by the secondary operating system 106, the network client 140 can directly or indirectly connect to the same network (eg, network 170) as the data processing system 101 and other data processing systems, of course. You can send and receive data to and from network clients running on other data processing systems if you are connected to.

In one embodiment, the management operating system 104 runs a secondary operating system 106, but this is not a requirement. In addition, the interrupt control operation in the secondary operating system 106 may be replaced by software emulation, which allows the management operating system 104 to safely precede the secondary operating system after a very limited delay. The secondary operating system 106 does not have to be a traditional operating system, it can be, for example, a Java virtual machine. The dual kernel software operating system that can be used in the present invention is described in US Pat. No. 5,995,745 (Yodaiken), which is incorporated herein by reference in its entirety. It will be appreciated by those skilled in the art that other multi-kernel operating systems may be used and that the present invention is not limited to any particular one.

As illustrated in FIG. 1, the management operating system 104 is further provided with a network control system (NCS) 110. The NCS110 is used transparently from the perspective of the secondary operating system 106 to monitor and control network operation in the secondary operating system 106. The NCS110 can also monitor and control the network environment. The NCS110 is an application of the management operating system 104 and may run in the address space of the management operating system 104 or in a protected memory space. The network client 140 running at the top of the secondary operating system 106 uses one or more protocol stacks 150 of the secondary operating system 106 or, for example, shared memory or a pseudo-device interface (not shown). And can communicate directly with NCS110. The NCS110 can further communicate with one or more clients 140 by reading and modifying state information in the secondary operating system 106 and in the application software of the client 140. The NCS110 can be run according to a periodic schedule, by a timeout, or by the action of a trigger from a low level driver.

In one embodiment, the secondary operating system 106 is provided with one or more virtual network drivers (VND) 120 that emulate a network device driver. That is, the VND120 appears to the secondary operating system 106 and the protocol stack 150 as a network device driver, such as device driver 133. The virtual network driver 120 "sends" and "receives" packets under the control of NCS110. The virtual network driver 120 can provide an interface corresponding to a hardware device such as an Ethernet driver, or can provide a higher level interface. For example, the Message Passing Interface (MPI) can be implemented as a virtual network driver 120 on a supercomputing cluster.

The NCS110 can operate across the boundaries of the protocol stack 150. For example, the NCS110 can collect information about the timing of protocols implemented in the secondary operating system 106, even if the protocols themselves do not track this information, and the NCS110 can perform the behavior of various protocols with these protocols. They may be associated and coordinated, even if they are logically unrelated within the secondary operating system. In addition, the NCS 110 can insert control information into and / or retrieve this information from the message stream through the protocol stack 150.

Through the real-time capabilities of the management operating system 104, the NCS110 is capable of forcing precise timing on the action of NCS. For example, the NCS110 can send periodic state updates (eg, "keepalive messages") to adjacent computer systems at precise intervals. In addition, the NCS110 can inspect and modify the state of the protocol stack and application programs in the secondary operating system. For example, the NCS110 may take advantage of the advanced T / TCP stack of the secondary operating system, but if the NCS110 detects a condition that the T / TCP protocol cannot detect, it intervenes to prevent wasting resources. obtain.

In one embodiment, the NCS 110 may include an event handler 112, a thread 113, and a control database 180. The event handler 112 is an instruction set for executing one or more functions. The event handler 112 is called when a predetermined event occurs. For example, one event handler 112 may be called in response to device driver 133 receiving a data packet (eg, Ethernet frame) from network device 130, while another event handler may have virtual device driver 120 in the upper layer. Called in response to receiving a data packet from the protocol. The control database 180 allows the NCS 110 to define any "logical join". Examples of logical joins are TCP / IP connections, TCP / IP service types, any communication with packets labeled by a particular hardware address or IP number, or requests / responses with another site or group of sites. It is a communication link unique to a real-time driver such as a link. The control database 180 may be incorporated into the design of the NCS 110, may have a static data structure, or may be dynamically updated. The control database 180 may be complemented or entirely formed by a program running under the control of the secondary operating system 106. For example, the SS7 system may include an information system running in a secondary operating system that keeps track of which calls have higher priority. The SS7 system may update NCS110's control database 180 to register prioritized calls for bandwidth managed by NCS110.

One of the NCS110 applications is the ability to transparently add functionality to existing network stacks and applications. For example, using NCS110 instead of modifying a complex and highly tuned T / TCP protocol stack (or any other protocol stack) to try to prioritize transactions with a particular remote computer. You can enforce these priorities on the T / TCP stack of the secondary operating system, for example, by transparently dropping or delaying messages from lower priority computers to the T / TCP stack when needed.

Another example of the functionality that NCS110 may provide includes providing fast failover in a computing cluster. A computing cluster usually consists of a large number of computers connected to an exchange network, such as exchange Ethernet, Myranet, or a custom "fabric". Common applications for computing clusters include supercomputing applications and e-commerce.

These clusters need to be able to react quickly to failures by shifting tasks to alternative computers that are not affected by the failure. The NCS110 detects a failure immediately or shortly after it occurs and then takes appropriate corrective action, or alerts that a failure has occurred so that another process or administrator can take appropriate action. By setting, such a quick reaction can be enabled. In one example, control database 180 lists address information for several other computers that form a "failover group" in the cluster. The NCS110 may first calibrate the delay of messages on the network for these computers and then schedule the periodic exchange of packets between members of the failover group. As scheduled, NCS110 sends packets to other computers in the group to indicate that the computer system and secondary operating system to which the NCS is associated is alive and progressing. In addition, the NCS110 has detected that messages are passing through the control stack in the secondary operating system 106, that important processes are scheduled at an appropriate rate, and that software or hardware panic conditions are detected. You may monitor the secondary operating system 106, making sure it is not there. The NCS110 may also activate alerts to other members of the failover group, resetting the alert when it receives a packet from the corresponding member of the failover group, and taking any specified action when the alert expires. ..

In another embodiment of the invention, the computer system 101 implements a telephone exchange system such as the SS7 telephone switch. In this embodiment, the NCS 110 is configured to detect the reception of a control signal on a telephone switch and process the control signal immediately after reception, or pass the control signal to an appropriate module for processing. Therefore, the present invention ensures that non-critical messages can be carried to the protocol stack of secondary operating system 106 while affecting control signals in a timely manner. As a specific example, a control message indicating that the line is inaccessible is provided by NCS110 to redirect the data message over the secondary line in a transparent manner to the protocol stack in the secondary operating system 106. Immediate action can be triggered.

The present invention can also be used to prevent theft or denial of service (DOS) attacks. Further, the present invention can be used to provide a service quality system that can schedule services and reduce resource contention in critical services. Those skilled in the art will appreciate that these uses of the invention are merely exemplary and that there are other uses of the invention.

Referring to FIG. 2, a functional block diagram of an exemplary embodiment of the NCS 210 capable of performing fast failover, monitoring TCP connections, and preventing denial of service (DOS) attacks is illustrated. The NCS210 includes two event handlers (event handler 212 (a) and event handler 212 (b)) and two threads (thread 213 (a) and thread 213 (b)). Event handler 212 (a) is called after network device 130 receives a data packet from network 170. When the network device 130 receives a data packet from network 170, the received data packet is passed to network driver 133, which puts the received packet in queue 237 (also known as hd_rx_queue237) and event handler 212 (a). ) Is called. Event handler 212 (b) is called when network device 130 sends a data packet (eg, Ethernet frame) to network 170. Thread 213 (a) performs failover monitoring, and thread 213 (b) performs TCP monitoring.

FIG. 3 is a flow chart illustrating process 300, which is at least partially executed by VND (120) when stack 150 generates packets for transmission. Process 300 first puts the generated packets into queue 225 (also known as vnd_tx_queue225) in step 301. In step 302, VND120 increments a variable called tx_packet_count. In step 304, the VND120 determines if the packet is a critical packet. That is, the VND120 determines if the packet originates from a TCP port labeled as "critical". In one embodiment, a list of critical TCP ports is maintained in control database 180. If the packet is a critical packet, control moves to step 306, otherwise the process goes to step 312.

In step 306, the VND120 records the current time so that the NCS110 can track how long it has been in the queue before the TCP packet is finally sent. In step 308, VND120 determines if queue 235 (also known as hd_tx_queue235) has room. If it can afford, the VND120 removes one or more packets from the vnd_tx_queue225 and puts one or more of these packets into the hd_tx_queue235 (step 310), otherwise the VND120 sleeps for a configurable amount of time. (Step 314). After step 314, the process returns to step 308.

In step 312, VND120 determines if there is room in hd_tx_queue235. If there is room, the process proceeds to step 310, otherwise the bucket is removed from vnd_tx_queue225 and discarded (step 313).

FIG. 4 is a flowchart illustrating the process 400 executed by one embodiment of the event handler 212 (a). As described above, event handler 212 (a) is called after network device 130 receives a data packet from network 170. In process 400, first in step 402, the event handler determines each site in the failover group. This information may be stored in control database 180.

Each site in the failover group has an associated site record that contains three fields. The first field, called the "Address" field, stores the address of the site (the address can be a hardware address or a network address). The second address, called the "last_tx_time" field, stores the time when the system 101 last sent a data packet to the site. The third field, called the "last_rx_time" field, stores the time when the system 101 last received the data packet from the site.

In step 404, the event handler determines if the received packet came from a site in the failover group. The event handler can determine this by comparing the source address information contained in the data packet with the address field of each site record. If they match, the received packet is from a site in the failover group. If the received packet was sent from a site in the failover group, the process goes to step 406, otherwise the process goes to step 412.

In step 406, the event handler determines the current time and stores this time in the last_rx_time field of the site record associated with the site that is the source of the data packet. In step 408, the event handler determines if the data packet is a "reminder packet". If so, the process proceeds to step 410, otherwise the process proceeds to step 412. At step 410, the event handler sends a "living" message to the site that is the source of the data packet.

In step 412, the event handler inspects the packet to determine if it is encapsulating a TCP packet. If not encapsulated, the packet is passed to VND120, the process terminates, if encapsulated, the process proceeds to step 414, and the event handler says that the encapsulated TCP packet initiates a SYN packet, a TCP connection. Determine if the packet is used for. If it is a SYN packet, the process goes to step 416, otherwise the process goes to step 426.

In step 416, the event handler determines whether the TCP_DOS_WARNING flag is set to TRUE or the TCP_CONGESTION_WARNING flag is set to TRUE. If either flag is set to TRUE, the received SYN packet is dropped (step 418), otherwise the process proceeds to step 420. In step 420, the event handler passes the received SYN packet to VND120, which puts the packet in queue 227 (also known as vnd_rx_queue227) and increments open_syn_count by 1 (ie open_syn_count = open_syn_count + 1). In step 422, the event handler determines if open_syn_count is greater than a predetermined threshold. If it is large, the TCP_DOS_WARNING flag is set to TRUE (step 424), otherwise the process terminates.

At step 426, the event handler determines if the encapsulated TCP packet is an ACK packet. If it is an ACK packet, decrement open_syn_count by 1 and pass the received packet to VND120 (step 428), otherwise the process proceeds to step 430.

At step 430, the event handler determines if the TCP packet is addressed to a TCP port labeled "Critical". That is, the thread may determine the TCP destination port number of the packet and then check the list of critical ports to see if that port number is in the list. In one embodiment, the list of critical TCP ports is maintained in control database 180. If the TCP packet is addressed to a critical TCP port, the thread passes the packet to VND120 and updates port.last_rx_sequence (step 432), otherwise the process proceeds to step 434.

At step 434, the thread determines if the TCP_CONGESTION_WARNING flag is set to TRUE. If set, the packet is dropped (step 436), otherwise the packet is passed to VND120 (step 438).

FIG. 5 is a flowchart illustrating the process 500 executed by one embodiment of the event handler 212 (b). As mentioned above, event handler 212 (b) is executed when a packet is sent to network 170 by network device 130. In process 500, first in step 502, the event handler determines how much time the packet spent on queues 225 and 235 before it was finally sent. If the time on the queue is longer than a given threshold (also known as the acceptable TX_ENQUEUE time), the event handler sets the TX_ENQUEUE_TOO_SLOW flag to TRUE (step 504), otherwise the process proceeds to step 506. At step 506, the event handler determines if the packet is addressed to a site in the failover group. If so, the event handler sets the last_tx_time for that site to the current time (step 508), otherwise the process proceeds to step 510. Also, after step 508, the process proceeds to step 510.

At step 510, the event handler determines if the packet originated from a TCP port labeled as critical. If so, the event handler updates the last_tx_sequence for that port (step 511).

In step 512, the event handler queues any packets generated by NCS threads (eg, threads 213 (a) or 213 (b)) that are not in hd_tx_queue235. At step 514, the event handler determines if the TX_ENQUEUE_TOO_SLOW flag is set to FALSE. If so, the process continues to step 516, otherwise the process terminates.

In step 516, the event handler determines if vnd_tx_queue225 is empty. If it is empty, the process ends, otherwise it continues to step 518. In step 518, the event handler selects the longest packet in this queue in vnd_tx_queue. In step 520, the event handler determines (a) whether the selected packet is a TCP packet addressed to the critical TCP port and (b) whether the TCP_CONGESTION_WARNING flag is set to FALSE. If either (a) or (b) is true, the event handler puts the selected packet in hd_tx_queue235 (step 522), otherwise the packet is dropped (step 524). After steps 522 and 524, the process returns to step 516.

FIG. 6 is a flowchart illustrating process 600 performed by one embodiment of thread 213 (a). In process 600, first in step 602, the thread determines each site in the failover group. This information may be stored in control database 180.

Then, in step 604, the thread determines which sites in the failover group have not received data packets from system 101 within a predetermined time period. Threads can determine this in a number of ways. For example, it is possible to compare the current time with the last transmission time stored in the variable last_tx_time by event handler 212 (b). At step 606, the thread sends a "living" packet to each site determined in step 604. So, for example, if a thread determines that a data packet has not been sent to a particular site in the failover group in the last 30 seconds, the thread sends a "living" data packet to that site. This indicates that the system 101 is operational because the site receives at least "living" data packets from the system 101 every 30 seconds.

In step 608, the thread determines which sites are not the source of the data packets received by the system 101 within a predetermined time period and adds those sites to the "alert list". The thread can determine in a number of ways which sites the system 101 has not received data packets for within a given time period. For example, the current time can be compared to the time when the system last received a data packet from the site, which time is stored in the variable last_rx_time by event handler 212 (a). At step 610, the thread sends a "reminder" packet to each site in the alert list. So, for example, if system 101 has not received a data packet from a particular site in the last 30 seconds, the thread puts the site on the alert list and sends a "reminder" packet to that site.

In step 612, the thread determines a site or sites in the alert list that have been on the alert list for longer than a predetermined amount of time. At step 614, the thread removes the sites determined in step 612 from the alert list and failover group and notifies the failure handler that these sites appear to be non-functional. After step 614, control is passed to step 602.

FIG. 7 is a flowchart illustrating the process 700 executed by one embodiment of thread 213 (b). Process 700 runs indefinitely as long as the KEEP_TCP_CONTROL flag is TRUE. Process 700 first checks in step 701 if the KEEP_TCP_CONTROL flag is set to TRUE. If not set to TRUE, the process terminates, and if set, the process proceeds to step 702. In step 702, the thread initializes a variable called "wait_count" to zero. At step 704, the thread scans for TCP control blocks in the secondary OS 106. In step 706, the thread executes process 800 (see Figure 8) for each control block. After executing process 800 for each control block, the thread proceeds to step 708.

Then, referring to Figure 8, in process 800, in step 802, the thread first determines if the TCP port state is set to SYN_RECEIVED, and SYN_RECEIVED is receiving SYN packets on that port. , Means that no positive response has been made. If the TCP port state is set to SYN_RECEIVED, the thread increments wait_count (step 804), otherwise the process proceeds to step 806. In step 806, the thread determines if the TCP port is a critical TCP port. If so, the thread proceeds to step 808, otherwise process 800 terminates.

In step 808, the thread inspects the TCP control block to determine the sequence number of the last TCP packet sent by the TCP port associated with the TCP control block. This sequence number is called send_max. In step 810, the thread compares send_max to port.last_tx_sequence, a variable that stores the sequence number of the last TCP packet associated with the port sent to network 170. This information can be maintained by event handler 212 (b). If send_max is greater than the threshold and exceeds port.last_tx_sequence, set the TCP_CONGESTED_WARNING flag to TRUE (step 812). The difference between send_max and port.last_tx_sequence provides information about the number of TCP packets in the queue that should be sent to network 170. The TCP_CONGESTED_WARNING flag should be activated if there are too many in the queue.

At step 814, the thread inspects the TCP control block to determine the next sequence number that the TCP port will receive. This sequence number is called rcv_next. In step 816, the thread compares rcv_next to port.last_rx_sequence, a variable that stores the sequence number of the last TCP packet associated with the port received from network 170. This information can be maintained by event handler 212 (a). If rcv_next is greater than the threshold and below port.last_rx_sequence, set the TCP_CONGESTED_WARNING flag to TRUE (step 818). If not, the process proceeds to step 820. The difference between rcv_next and port.last_rx_sequence provides information about the number of TCP packets in queues 227 and 237. The TCP_CONGESTED_WARNING flag should be activated if there are too many packets in these queues.

At step 820, the thread determines if rcv_next is less than a predetermined threshold and above port.last_rx_sequence. If rcv_next is less than a given threshold and above port.last_rx_sequence, set the TCP_CONGESTED_WARNING flag to TRUE. This step is required for the end of the sequence number.

Referencing process 700 again, in step 708, the thread sets open_syn_count equal to wait_count. The thread then determines if open_syn_count is less than the first threshold (step 709). If it is small, set the TCP_DOS_WARNING flag to FALSE (step 710). In step 712, the thread determines if open_syn_count is greater than the second threshold, where the second threshold is greater than the first threshold. If it is large, set the TCP_DOS_WARNING flag to TRUE (step 714). At step 716, the thread sleeps for a set amount of time. After step 716, the process returns to step 701.

Although various embodiments / modifications of the present invention have been described above, it should be understood that these are presented as mere examples, not as limitations. Therefore, the scope and scope of the present invention is not limited by any of the exemplary embodiments described above, but is defined only by the claims and their equivalents.

<figref num="1">Functional block diagram of a system according to an embodiment of the present invention</figref><figref num="2">Functional block diagram of an exemplary embodiment of NCS capable of performing fast failover, monitoring TCP connections, and preventing denial of service (DOS) attacks in a system according to one embodiment of the present invention.</figref><figref num="3">A flowchart illustrating process 300 performed by VND when the stack generates packets for transmission in a system according to an embodiment of the present invention.</figref><figref num="4A">A flowchart illustrating process 400 executed by one embodiment of event handler 212 (a) in a system according to one embodiment of the present invention.</figref><figref num="4B">A flowchart illustrating process 400 executed by one embodiment of event handler 212 (a) in a system according to one embodiment of the present invention.</figref><figref num="5A">A flowchart illustrating process 500 executed by one embodiment of event handler 212 (b) in a system according to one embodiment of the present invention.</figref><figref num="5B">A flowchart illustrating process 500 executed by one embodiment of event handler 212 (b) in a system according to one embodiment of the present invention.</figref><figref num="6">A flowchart illustrating process 600 executed by one embodiment of thread 213 (a) in a system according to one embodiment of the present invention.</figref><figref num="7">A flowchart illustrating process 700 executed by one embodiment of thread 213 (b) in a system according to one embodiment of the present invention.</figref><figref num="8">A flowchart illustrating process 800 executed by one embodiment of thread 213 (a) in a system according to one embodiment of the present invention.</figref>