US20160142289A1 - Fault-tolerant communications in routed networks - Google Patents

Fault-tolerant communications in routed networks Download PDF

Info

Publication number
US20160142289A1
US20160142289A1 US15/002,717 US201615002717A US2016142289A1 US 20160142289 A1 US20160142289 A1 US 20160142289A1 US 201615002717 A US201615002717 A US 201615002717A US 2016142289 A1 US2016142289 A1 US 2016142289A1
Authority
US
United States
Prior art keywords
driver
fault tolerant
pathway
electronic device
protocol
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US15/002,717
Inventor
Michael T. Massa
Rudolf Opavsky
David Allen Dion
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Microsoft Technology Licensing LLC
Original Assignee
Microsoft Technology Licensing LLC
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 Microsoft Technology Licensing LLC filed Critical Microsoft Technology Licensing LLC
Priority to US15/002,717 priority Critical patent/US20160142289A1/en
Assigned to MICROSOFT CORPORATION reassignment MICROSOFT CORPORATION ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: MASSA, MICHAEL T., DION, DAVID A., OPAVSKY, RUDOLF
Assigned to MICROSOFT TECHNOLOGY LICENSING, LLC reassignment MICROSOFT TECHNOLOGY LICENSING, LLC ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: MICROSOFT CORPORATION
Publication of US20160142289A1 publication Critical patent/US20160142289A1/en
Abandoned legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/28Routing or path finding of packets in data switching networks using route fault recovery
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16Error detection or correction of the data by redundancy in hardware
    • G06F11/20Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/2002Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where interconnections or communication control functionality are redundant
    • G06F11/2005Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where interconnections or communication control functionality are redundant using redundant communication controllers
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00Digital computers in general; Data processing equipment in general
    • G06F15/16Combinations of two or more digital computers each having at least an arithmetic unit, a program unit and a register, e.g. for a simultaneous processing of several programs
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06Management of faults, events, alarms or notifications
    • H04L41/0654Management of faults, events, alarms or notifications using network fault recovery
    • 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
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/22Alternate routing
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/161Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/165Combined use of TCP and UDP protocols; selection criteria therefor
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/40Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass for recovering from a failure of a protocol instance or entity, e.g. service redundancy protocols, protocol state redundancy or protocol service redirection
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16Error detection or correction of the data by redundancy in hardware
    • G06F11/20Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/2002Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where interconnections or communication control functionality are redundant
    • G06F11/2007Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where interconnections or communication control functionality are redundant using redundant communication media

Definitions

  • multiple nodes may communicate with each other over a network. Should the network experience a failure, communication between the nodes may be disrupted.
  • the following examples provide computer network communication fault-tolerance via unique network stack architectures requiring minimal consideration by application software operating on networked nodes.
  • FIG. 1 is block diagram showing an example network stack architecture.
  • FIG. 2 is a block diagram showing a networked computing environment including two example nodes coupled via two networks.
  • FIG. 3 is a block diagram showing an example fault-tolerant communications driver, NETFT.
  • FIG. 4 is a block diagram showing an example fault-tolerant communications architecture including NETFT and an application.
  • FIG. 5 is a flow diagram showing data flowing through a fault-tolerant communications environment including a source node and a destination node coupled via Path A over network 1 and Path B over network 2 .
  • FIG. 6 is a flow diagram showing data flowing through the fault-tolerant communications environment shown in FIG. 5 with the addition of several possible communications failures.
  • FIG. 7 is a block diagram showing and another example of a fault-tolerant communications driver, NETFT.
  • FIG. 8 is a block diagram showing an example fault-tolerant communications architecture including NETFT and an application.
  • FIG. 9 is a flow diagram showing data flowing through a fault-tolerant communications environment including a source node and a destination node coupled via Path A over network 1 and Path B over network 2 .
  • FIG. 10 is a flow diagram showing data flowing through the fault-tolerant communications environment shown in FIG. 9 with the addition of several possible communications failures.
  • FIG. 11 is a block diagram showing an example computing environment in which the technology described above may be implemented.
  • FIG. 1 is block diagram showing an example network stack architecture 100 .
  • a network stack (“stack”) generally couples with software applications via network stack interfaces and/or other interfaces to provide network communications functionality to applications.
  • An application is typically said to be at (or coupled to) the “top” of the stack.
  • a network is typically said to be at (or coupled to) the “bottom” of the stack.
  • Various elements of a network stack may be referred to as at or near the top or bottom of the stack, or higher or lower in the stack relative to each other.
  • protocol driver 130 is higher in the stack than NIC 180 which is shown at the bottom of the stack in this particular figure.
  • Various depictions of a network stack may or may not include some stack elements, or may group, order or name the elements in various ways, depending on the purpose or focus of the depiction, as understood by those skilled in the art.
  • driver refers to a control program or the like that enables a node to operate with a particular device, such as a printer, network interface card, or other computer subsystem, or to operate with one or more programs such as network stacks, protocol drivers, and/or other computer software or firmware or the like.
  • a protocol driver typically operates with a network stack.
  • An application may pass a packet of data to a stack destined for an application operating on another node.
  • the data is said to flow “down” the stack and is sent out over a network.
  • Data received by a node is said to flow “up” the stack until it reaches the destined application.
  • Such networking systems are well known to those skilled in the art.
  • a stack is based on the Network Driver Interface Specification (“NDIS”) which defines a standard application programming interface (“API”) for network interface cards (“NICs”), such as NIC 180 , and abstracts the network hardware from network drivers.
  • NDIS also specifies a standard interface between layered network drivers, thereby abstracting lower-level drivers that manage hardware, such as a miniport driver, from upper-level drivers, such as protocol drivers.
  • Multiple NDIS-conforming protocol drivers may co-exist on a single node.
  • NDIS routes network traffic to the appropriate NIC via its associated driver as indicated by the traffic.
  • An illustration of NDIS is shown in FIG. 1 .
  • ODI Open Data-Link Interface
  • DLPI Data Link Provider Interface
  • UMI Uniform Driver Interface
  • NDIS and NDIS terminology is used with examples throughout this description, but other standards, technologies and/or architectures may be used in all of these examples with appropriate modifications, unless otherwise noted.
  • miniport driver 160 coupled to NIC 180 via NDIS 120 is miniport driver 160 .
  • a miniport driver typically interacts with NDIS via an NDIS miniport interface 162 .
  • the miniport driver 160 may be associated with NIC 180 and may manage its operations, including sending and receiving data through the NIC.
  • the miniport driver 160 typically interfaces with higher-level drivers, such as intermediate driver 140 and protocol driver 130 .
  • a miniport driver is considered a NIC driver.
  • NIC miniports generally perform those hardware-specific operations needed to manage a particular NIC with common or NIC-independent functionality provided by NDIS.
  • a node may include multiple NICs with each NIC generally having an associated NIC driver.
  • Protocol or transport driver 130 couples to NDIS 120 via an NDIS protocol interface 134 .
  • Protocol drivers or transport protocol drivers generally provide the functionality to create, send and receive packets of data that are sent from one node to another through the network stack and over a network.
  • a common reliable or guaranteed delivery transport protocol may be TCP/IP (Transmission Control Protocol/Internet Protocol).
  • UDP User Datagram Protocol
  • NDIS intermediate (“IM”) drivers 140 are shown between protocol drivers 130 and NDIS NIC miniports 160 in FIG. 1 . To protocol drivers IM drivers appear to be NDIS miniports while to NIC drivers they look like protocol drivers. Data packets flowing up or down the network stack pass through the IM driver 140 which may ignore, inspect, filter, forward, redirect and/or modify the data packets. An intermediate driver 140 may also be known as a filter driver.
  • FIG. 2 is a block diagram showing a networked computing environment 200 including two example nodes 210 and 260 coupled via two networks 202 and 282 .
  • Nodes 210 and 260 may each be personal computers (“PCs”), client computers, servers, hosts, laptops, portable devices, consumer electronic devices, or any of various other types of computing or processing devices, machines or systems.
  • PCs personal computers
  • client computers servers, hosts, laptops, portable devices, consumer electronic devices, or any of various other types of computing or processing devices, machines or systems.
  • Circles 212 , 214 , 262 , and 264 represent NICs associated with their respective nodes.
  • FIG. 11 is further described below with respect to FIG. 11 as network adapter 1113 .
  • node refers to any computing system, device, or process that is uniquely addressable, or otherwise uniquely identifiable, in a network (e.g., network 202 ) and that is operable to communicate with other nodes in the network.
  • a node may be a personal computer, a server computer, a hand-held or laptop device, a tablet device, a multiprocessor system, a microprocessor-based system, a set top box, a consumer electronic device, a network PC, a minicomputer, a mainframe computer, or the like.
  • a non-limiting example of a node 210 in the form of a computing system, is set forth below with respect to FIG. 11 .
  • Networks 202 and 282 may be the same network, may exist on the same or different subnets, may be logically or physically coupled or isolated from each other, may use similar or different networking technologies, etc.
  • networks 202 and 282 may be routed networks, that is, networks including routers that forward routable protocol packets.
  • Routable protocols are typically considered communications protocols used to route data from one network to another.
  • An example of a routable protocol is TCP/IP.
  • Sending a data packet in a routable fashion implies using a routable transport protocol to format and/or send the data packet.
  • Those skilled in the art will be familiar with routable protocols and routing network topologies, systems and architectures.
  • networks 202 and 282 may be independent of each other such that if there is a problem or failure with one network it is unlikely to affect the operational status of the other. In other examples, three or more networks may be used. In examples where greater degrees of fault-tolerance are desired a larger number of networks along with the associated connectivity of nodes to those networks, including a similar number of NICs installed on a node, may be employed.
  • NIC 212 associated with node 210 , is shown with an example address of 172.56.48.37 and is coupled to network 1 202 .
  • NIC 214 also associated with node 210 , is shown with an example address of 197.71.48.38 and is coupled to network 2 282 .
  • NIC 262 associated with node 260 , is shown with an example address of 172.56.48.38 and is also coupled to network 1 202 .
  • NIC 264 also associated with node 260 , is shown with an example address of 197.71.48.39 and is also coupled to network 2 282 .
  • These addresses may, in practice, be IPv4 or IPv6 addresses or the like, or any other type of network address typically related to the protocol being used.
  • Each node may include one or more NICs.
  • Arrows 201 and 203 also shown in FIG. 11 as arrow 1114 , represent a first communications route or pathway (“Path A”) over network 1 202 between nodes 210 and 260 .
  • Arrows 281 and 283 represent a second communications route or pathway (“Path B”) over network 2 282 between nodes 210 and 260 .
  • there may be one or more pathways over one or more networks between the two or more nodes in environment 200 .
  • the term “pathway” as used herein is defined as a communications route, or communications link, between nodes in a network. Such a route or link may be dynamic in that the exact route between nodes may change over time.
  • Blocks 216 and 266 represent an application and a network stack, including a fault-tolerant communications (“FT”) driver, provided on each of nodes 210 and 260 .
  • the FT driver of block 216 is shown with an example address of 10.0.0.1 and the FT driver of block 266 is shown with an example address of 10.0.0.2. These addresses are typically considered virtual addresses. These addresses may be IPv4 or IPv6 addresses or the like, or any other type of network or communications address. FT drivers may or may not have virtual addresses as shown in the various examples below.
  • a fault-tolerant network stack is a network stack including an FT driver, such as NETFT described below in connection with FIG. 3 , or the like.
  • An FT driver such as NETFT, operating in combination with a network stack typically allows nodes to communicate with each other via one or more communications paths, such as Path A and Path B, over one or more networks. Should any of these communications paths fail, the nodes may continue communicating given at least one operational pathway.
  • Such a pathway failure may result from failure of a NIC or failure of any element of a pathway, including connections, cabling or other communications media (including radio frequency (“RF”) or infrared (“IR”) and the like), routers, hubs, switches, firewalls, Internet Service Providers (“ISPs”), power failure to any node, device or system of the network, or the like.
  • RF radio frequency
  • IR infrared
  • ISPs Internet Service Providers
  • a communications failure may result in a plug-and-play (“PnP”) event.
  • PnP event may indicate the removal of a NIC from its node or to a media sense change.
  • a media sense disconnect typically results from a failure that causes the NIC to lose the signal or carrier on the network media, such as a network cable, RF or IR link or the like.
  • a media sense disconnect may be caused by disconnecting the network cable or carrier from the NIC or powering off the other end of the cable (a hub or switch, for example).
  • a media sense connect is typically the opposite, such as reconnecting the cable, re-powering on the hub or switch or the like.
  • connectivity events are generally local events in that they occur on or are proximate to the node itself. Such local connectivity events typically result in an event indication, such as a PnP event the like, on a node.
  • a communications failure may be detected by using heartbeat packets sent between nodes. Failure of such a heartbeat packet may indicate failure of a pathway between nodes. Heartbeat packets tend to be marked such that the FT driver can detect them upon receipt and remove them for the packet flow being passed up the network stack.
  • heartbeat packets may be implemented using route control protocol (“RCP”) by forming RCP packets. Such heartbeat packets may be used to validate the end-to-end operational status of a pathway. That is, by sending a heartbeat packet from node 210 over Path A to node 260 and by node 210 receiving a reply to the sent heartbeat packet from node 260 , it is generally considered that Path A is end-to-end operational.
  • RCP route control protocol
  • node 210 may have an operational NIC 212 and valid media sense, indicating that it is properly connected to the network, hut may still detect a heartbeat failure due to some network or system failure down the line.
  • FIG. 3 is a block diagram showing an example fault-tolerant communications driver, NETFT 300 .
  • NETFT 300 may be implemented as an NDIS miniport driver ( FIG. 1, 160 ) for use with an NDIS network stack and for providing network communications between nodes tolerant of pathway failures. That is, communications between two or more nodes may continue when each is using a NETFT despite failure of any component in the pathway as long as at least one pathway remains operational.
  • implementation of the FT driver as an NDIS miniport driver provides at least two benefits.
  • protocol reliability tends to be provided by any higher-level reliable protocol driver which is generally unaffected by the addition of link-level fault-tolerance provided by an FT driver.
  • the FT driver when using an FT driver in combination with a protocol driver such as a TCP/IP driver, the FT driver will typically detect failed pathways and route data packets over end-to-end operational pathways independent of any protocol driver. Should any packet loss occur due to switching pathways, the TCP/IP protocol driver, which generally sits above the FT driver in the stack, tends to detect such losses and perform any retry or resend operations to ensure that the reliable protocol succeeds in packet delivery.
  • a second benefit of placing the FT driver below the protocol driver in the stack is that typically no degradation of the routability of the protocol is introduced.
  • any tunneling operation that an FT driver performs on a data packet may employ a routable protocol, such as TCP or UDP, thus ensuring that such data is routable, in addition to being link-level fault tolerant.
  • a routable protocol such as TCP or UDP
  • NETFT as a part of a network stack, generally couples to a software application via NDIS or other network stack interfaces. Such a coupling generally enables applications to send and receive data packets over networks coupled to the bottom of the stack. In one example, applications tend to use a virtual address as the source address for their data packets, this virtual address being known to NETFT and mapped and communicated to other nodes on the network as described below. As shown in FIG. 3 , NETFT includes a miniport adapter 302 (also known as a processing element) a routing database 304 , and one or more route monitor adapters 306 and tunnel adapters 308 .
  • miniport adapter 302 also known as a processing element
  • routing database 304 also known as a routing database 304
  • route monitor adapters 306 and tunnel adapters 308 one or more route monitor adapters 306 and tunnel adapters 308 .
  • Tunnel adapter 308 typically represents one NIC on the local node (or, in some instances, a virtual NIC) and maintains a socket used to tunnel packets to NETFT on the target node. There is typically one tunnel adapter 308 associated with each NIC on the local node with each NIC being coupled to a network providing a pathway to another node. Each network may or may not be isolated from any other network.
  • a tunnel adapter 308 is typically associated with a tunneling protocol driver and tunnels data packets through a tunneling protocol to and from its associated NIC via NDIS interfaces.
  • a tunneling protocol is UDP.
  • other protocols such as TCP, IPX, or SPX, may be used for tunneling.
  • a tunnel adapter 308 may become inactive should the associated NIC or media connection become inactive.
  • a routing database 304 is typically a simple data structure, that may be located in system memory, that includes entries mapping a virtual address for one or more pathways to a similar NETFT on another node.
  • mappings are represented by route monitor adapters such as route monitor adapter 306 which are typically associated with a tunnel adapter such as tunnel adapter 308 .
  • a routing database such as routing database 304 will include one set of route adapters for each tunnel adapter, each route adapter being associated with a different target node reachable over the pathway associated with the tunnel adapter.
  • the database may map a destination virtual address to a physical address of a specific remote node.
  • a routing database 304 may also include priority information for each pathway. Such priority information may be used to indicate a preferred or primary pathway to another node and/or may include information about pathway speed or other characteristics.
  • a preferred pathway is the pathway calculated by NETFT to be used over other possible pathways, when possible, based on priority information and/or pathway status.
  • Priority information may alternatively indicate a round-robin load balancing algorithm for making use of multiple pathways to a target node to load-balance traffic over the pathways, or enable some other pathway prioritization scheme.
  • An example routing table database 304 mapping table is shown in Table 1.
  • table 1 shows an example mapping table as might be used by NETFT operating on node 216 .
  • Table 1 shows virtual destination address 10.0.0.2, the virtual address as shown for node 266 , mapped to physical address 172.56.48.38 associated with Path A to node 266 and physical address 197.71.48.39 associated with Path B to node 266 .
  • Path A is shown with first priority and Path B with second priority.
  • Table 1 is provided as an example and is not intended to be limiting.
  • mapping table When sending data from node 216 to node 266 , such a mapping table is typically used to tunnel a packet destined to virtual destination address 10.0.0.2 by forwarding the packet via a tunneling protocol, such as UDP, to physical destination address 172.56.48.38, thus tunneling the packet from node 216 over Path A to node 266 .
  • a tunneling protocol such as UDP
  • One such mapping table may be created in the routing database ( FIG. 3, 304 ) for each set of pathways established between two nodes.
  • Such a mapping table may be implemented in various forms, use various priority schemes and/or store other information including pathway operational status.
  • the mapping table structure, number of pathways, address formats, etc. shown in Table 1 are provided as examples and are not intended to be limiting.
  • the local node virtual address, remote node virtual addresses, and priority and other pathway information are typically provided to nodes by an out-of-band mechanism and passed to NETFT via its NDIS interfaces.
  • This out-of-band mechanism may be as simple as a systems administrator using a management application to specify the information, or it may be an automated system or the like. Such out-of-band mechanisms are well known to those skilled in the art.
  • miniport adapter 302 typically parses a data packet flowing down the network stack, examines the destination virtual address of the packet and uses information from the routing database 304 to determine which tunnel adapter 308 to tunnel the data packet through. Incoming packets, or data packets flowing up the stack, are forwarded up the stack toward their destination virtual address, the tunneling protocol having previously removed the tunneling packet headers. In particular, the tunnel adapter 308 inspects incoming packets and forwards heartbeat packets to a route monitor adapter 306 and forwards other packets up the stack via a miniport adapter 302 . Aspects of tunneling data packets using a tunneling protocol and how protocol headers are added and removed by protocol drivers is well known to those skilled in the art.
  • Route monitor adapter 306 typically represents a remote node accessible over a specific pathway identified by an associated tunnel adapter.
  • the route monitor adapter 306 will typically provide a physical address for the remote node, the physical address also corresponding to a specific pathway to the remote node. This physical address is typically used for mappings in a routing database 304 .
  • node 210 is shown coupled to node 260 over two pathways, one through network 1 202 (“Path A”) and the other through network 2 282 (“Path B”).
  • NETFT operating on node 210 may include a first route monitor adapter (“RMA-A”) providing remote node 260 's physical address 172.56.48.38 associated with its NIC 262 .
  • RMA-A may be associated with a first tunnel adapter (“TA-A”) on node 210 which may be associated with Path A.
  • NETFT on node 210 may also include a second route monitor adapter (“RMA-B”) providing remote node 260 's second physical address 197.71.48.39 associated with its NIC 264 .
  • RMA-B may be associated with a second tunnel adapter (“TA-B”) on node 210 which may be associated with Path B.
  • route monitor adapter 306 typically monitors the health of a pathway to a remote node and indicates a failed or non-operational pathway in the routing database 304 . Monitoring typically includes receiving any event indications and/or noting any heartbeat failures and updating the database 304 accordingly. In one example, an event indicating the failure of a NIC or media connection may result in the disabling of the tunnel adapter 308 . In another example, a heartbeat failure may result in the disabling of the route monitor adapter 306 associated with the specific remote node for which the heartbeat failed.
  • FIG. 4 is a block diagram showing an example fault-tolerant communications architecture 216 including NETFT 300 and an application 402 .
  • the application 402 sends data packets to NETFT 300 via the stack using a virtual source address 217 and a virtual destination address representing the destination node.
  • Such out-going data packets flow via path 480 from the application and through the network stack to the driver 300 .
  • the driver 300 typically determines which of the possible pathways each packet should take, generally using priority information and pathway operational status information stored in the routing database, and tunnels the packet to the target node over the selected pathway using the appropriate physical source address 422 or 424 .
  • Application 402 may send a data packet through NETFT 300 via the TCP protocol, as shown in FIG. 4 .
  • TCP Transmission Control Protocol
  • NETFT 300 may use the UDP protocol to tunnel packets to the target node.
  • TCP or any other protocol may be used for tunneling.
  • alternate examples may not make use of miniport adapters or NDIS drivers but may use other mechanisms or architectures to perform similar functions.
  • the various elements of the network stack and the like may operate in either a User Mode or a Kernel Mode, either as shown or otherwise, or on systems with or without equivalent modes of operation.
  • FIG. 5 is a flow diagram showing data flowing through a fault-tolerant communications environment 500 including a source node 216 and a destination node 266 coupled via Path A over network 1 202 and Path B over network 2 282 .
  • data is shown being sent from the application operating on node 216 to the application listening on the destination virtual address on node 266 .
  • the data packets flow down the network stack operating on node 216 using the TCP protocol into NETFT as shown by path 501 .
  • NETFT maps the data packets from the source virtual address being used by the application to Path A and tunnels the data through the UDP protocol using the Path A physical destination address for target node 266 , out NIC 1 of node 216 as further shown by path 501 and onto network 1 202 via link 201 .
  • the data then flows through network 1 202 , over link 203 and to node 266 , flowing up the network stack operating on node 266 as shown by path 503 .
  • the data then flows through the UDP protocol driver, the same protocol that was used on the sending side as the tunneling protocol, where the UDP protocol headers are stripped off the data packets which are then passed into NETFT operating on node 266 .
  • NETFT then forwards the data packets up the stack to the application which is listening on the destination virtual address. Responses tend to flow in the reverse order.
  • FIG. 6 is a flow diagram showing data flowing through the fault-tolerant communications environment 500 shown in FIG. 5 with the addition of several possible communications failures 610 , 612 , 620 , 622 , and 630 .
  • Failure 610 indicates a failure of NIC I operating on the sending node 216 . Such a failure may occur should NIC 1 be removed from the node, should the driver of NIC 1 fail, should NIC 1 itself fail, or the like.
  • the failure may be detected by NETFT via an event indication, such as a PnP event or the like, and/or a heartbeat failure. In such a situation Path A is typically considered to have failed and NETFT will select an alternate end-to-end-operational pathway.
  • An end-to-end operational pathway is typically a pathway that can successfully deliver data from the source node and application all the way to the destination node and application.
  • Failure 620 indicates a failure of the network media coupling with NIC 1 of node 216 .
  • This failure may be due to a cable being disconnected from NIC 1 , from the cable becoming disconnected from some device of network 1 202 , from the device the cable is connected to on the network side being powered down or failing, or the like.
  • This type of failure may also be detected by NETFT via an event indication, such as a PnP event or the like, and/or a heartbeat failure and an alternate pathway selected.
  • Failure 630 indicates a failure of some type within network 202 resulting in data packets failing to reach destination node 266 .
  • sending node 216 may still be coupled to network 202 with a proper media sense indication, yet Path A has become disrupted further down the network.
  • NETFT operating on sending node 216 may not detect the failure via an event indication if local indications show connectivity to the network 202 as good, but may detect the failure via Path A heartbeat failure.
  • Failure 622 of link 203 and failure 612 of NIC 1 operating on receiving node 266 tend to be similar to the corresponding failures shown for node 216 . But these failures, not being local to node 216 may not be detected via event indications but may be detected via heartbeat failure.
  • NETFT may be detected by NETFT operating on node 216 and result in it selecting an alternate end-to-end operational pathway, such as Path B over network 2 282 .
  • NETFT tunnels data down alternate path 681 and over network 2 282 to receiving node 266 .
  • NETFT operating on sending node 216 may detect the recovery and again make use of Path A.
  • any responses from node 266 back to node 216 may be tunneled in a similar fault-tolerant fashion by NETFT.
  • FIG. 7 is a block diagram showing and another example of a fault-tolerant communications driver, NETFT 700 .
  • This example is similar to the example shown in FIG. 3 hut includes variations as described below.
  • a software application may not need to use virtual addresses. Instead, an application may use a physical destination address to address data packets to the target node.
  • Protocol adapter 710 generally couples to miniport adapter 702 (also known as the processing element of the driver) and to a NIC miniport adapter (not shown). There is typically one protocol adapter for each NIC installed on the node, each protocol adapter being associated with a NIC via its NIC adapter. As each protocol adapter is associated with a NIC, it is also associated with the pathway coupled to the NIC. The protocol adapter 710 is operable to accept data packets from an application via the processing element 702 and pass the data packets to the associated NIC without the need for tunneling.
  • Processing element 702 typically parses a data packet flowing down the network stack, examines the physical destination address of the packet and uses information from the routing database 704 to determine if the packet can be forwarded over a protocol adapter 710 or needs to be tunneled over a tunnel adapter 308 to the target node. Generally, if the pathway indicated by the physical destination address is end-to-end operational, the data packet will be sent over that pathway. Otherwise and alternate pathway may be selected over which the packet may be tunneled.
  • routing database 704 maintains mappings of physical destination addresses and pathways, along with priority and other information as described above.
  • An example routing database 704 mapping table is shown in Table 2.
  • Table 2 shows an example mapping table as might be used by NETFT operating on node 216 .
  • Table 2 shows a mapping including physical destination address 172.56.48.38 associated with Path A to node 266 and the physical destination address 197.71.48.39 associated with Path B to node 266 .
  • Path A is shown with first priority and Path B with second priority.
  • mapping table When sending data from node 216 to node 266 , such a mapping table is typically used in forwarding (or tunneling if needed) a data packet being sent to physical destination address 172.56.48.38 of node 266 . If the pathway associated with the original destination address is operational, the data packet tends to be forwarded to the destination node without tunneling. If that pathway in not available, then the data packet is sent over the alternate pathway to physical destination address 197.71.48.39 of node 266 via tunneling.
  • Other aspects of NETFT 700 are generally similar to those of NETFT as described for FIG. 3 .
  • FIG. 8 is a block diagram showing an example fault-tolerant communications architecture 216 including NETFT 700 and an application 402 .
  • application 402 sends data packets to NETFT 700 via the stack using a physical source address and a physical destination address 801 representing the destination node.
  • Such out-going data packets flow via path 880 from the application and through the network stack to the driver 700 .
  • the driver 700 typically determines which of the possible pathways each packet should take, generally using priority information and pathway operational status information stored in the routing database, and either forwards the packet to the target node over pathway indicated by the original physical destination address or, if that pathway is not end-to-end operation, tunnels the packet over an alternate pathway as indicated in this example by route 882 and NIC 2 892 .
  • Application 402 may send a data packet through NETFT 700 via the TCP protocol, as shown in FIG. 8 .
  • TCP Transmission Control Protocol
  • NETFT 700 may use the UDP protocol to tunnel packets to the target node.
  • TCP or any other protocol may be used for tunneling.
  • other examples may not make use of NDIS drivers but may use other mechanisms or architectures to perform similar functions.
  • the various elements of the network stack and the like may operate in either a User Mode or a Kernel Mode, either as shown or otherwise, or on systems with or without equivalent modes of operation.
  • FIG. 9 is a flow diagram showing data flowing through a fault-tolerant communications environment 900 including a source node 816 and a destination node 966 coupled via Path A over network 1 202 and Path B over network 2 282 .
  • data is shown being sent from the application operating on node 216 to the application listening on the destination physical address on node 266 .
  • the data packets flow down the network stack operating on node 216 using the TCP protocol into NETFT as shown by path 901 . Assuming, as shown, that Path A is the selected pathway, NETFT forwards the data packets using the physical destination address provided by the application via NIC 1 of node 216 over Path A and network 1 202 via link 201 .
  • the data then flows through network 1 202 , over link 203 and to node 966 , flowing up the network stack operating on node 966 as shown by path 903 .
  • the data then flows through NETFT and the protocol driver (a protocol driver for the same protocol that was used on the sending side as the sending protocol) and up to the application. Responses tend to flow in the reverse order.
  • FIG. 10 is a flow diagram showing data flowing through the fault-tolerant communications environment 900 shown in FIG. 9 with the addition of several possible communications failures 1010 , 1012 , 1020 , 1022 , and 1030 . Other communications failures are also possible.
  • Failure 1010 indicates a failure of NIC 1 operating on the sending node 816 . Such a failure may occur should NIC 1 be removed from the node, its NIC driver fail, the NIC itself fail, or the like.
  • the failure may be detected by NETFT via an event indication, such as a PnP event or the like, and/or a heartbeat failure. In such a situation Path A is typically considered to have failed and NETFT will select an alternate end-to-end-operational pathway.
  • Failure 1020 indicates a failure of the network media coupling with NIC 1 of node 816 .
  • This failure may be due to a cable being disconnected from NIC 1 , from the cable becoming disconnected from some device of network 1 202 , from the device the cable is connected to on the network side being powered down or failing, or the like.
  • This type of failure may also be detected by NETFT via an event indication, such as a PnP event or the like, and/or a heartbeat failure and an alternate pathway selected.
  • Failure 1030 indicates a failure of some type within network 202 resulting in data packets failing to reach destination node 966 .
  • sending node 816 may still be coupled to network 202 with a proper media sense indication, yet Path A has become disrupted further down the network.
  • NETFT operating on sending node 816 may not detect the failure via an event indication, such as a PnP event or the like, if local indications show connectivity to the network 202 as good, but may detect the failure via Path A heartbeat failure.
  • Failure 1022 of link 203 and failure 1012 of NIC 1 operating on receiving node 966 tend to be similar to the corresponding failures shown for node 816 . But these failures, not being local to node 816 may not be detected via event indications but may be detected via heartbeat failure.
  • NETFT may be detected by NETFT operating on node 816 and result in it selecting an alternate end-to-end operational pathway, such as Path B over network 2 282 .
  • NETFT tunnels data down alternate path 1081 and over network 2 282 to receiving node 966 .
  • NETFT operating on sending node 816 may detect the recovery and again make use of Path A.
  • any responses from node 966 back to node 816 may be forwarded or tunneled, depending on the operational status of Path A and Path B, in a similar fault-tolerant fashion by its NETFT.
  • FIG. 11 is a block diagram showing an example computing environment 1100 in which the technology described above may be implemented.
  • a suitable computing environment may be implemented with numerous general purpose or special purpose systems. Examples of well known systems may include, but are not limited to, personal computers (“PC”), hand-held or laptop devices, microprocessor-based systems, multiprocessor systems, servers, workstations, consumer electronic devices, set-top boxes, and the like.
  • PC personal computers
  • hand-held or laptop devices microprocessor-based systems
  • multiprocessor systems multiprocessor systems
  • servers workstations
  • consumer electronic devices set-top boxes, and the like.
  • Computing environment 1100 generally includes a general-purpose computing system in the form of a computing device 1101 coupled to various peripheral devices 1102 , 1103 , 1104 and the like.
  • System 1100 may couple to various input devices 1103 , including keyboards and pointing devices, such as a mouse or trackball, via one or more I/O interfaces 1112 .
  • the components of computing device 1101 may include one or more processors (including central processing units (“CPU”), graphics processing units (“CPU”), microprocessors (“uP”), and the like) 1107 , system memory 1109 , and a system bus 1108 that typically couples the various components.
  • processors including central processing units (“CPU”), graphics processing units (“CPU”), microprocessors (“uP”), and the like
  • Processor 1107 typically processes or executes various computer-executable instructions to control the operation of computing device 1101 and to communicate with other electronic and/or computing devices, systems or environment (not shown) via various communications connections such as a network connection 1114 or the like.
  • System bus 1108 represents any number of several types of bus structures, including a memory bus or memory controller, a peripheral bus, a serial bus, an accelerated graphics port, a processor or local bus using any of a variety of bus architectures, and the like.
  • System memory 1109 may include computer readable media in the form of volatile memory, such as random access memory (“RAM”), and/or non-volatile memory, such as read only memory (“ROM”) or flash memory (“FLASH”).
  • RAM random access memory
  • ROM read only memory
  • FLASH flash memory
  • a basic input/output system (“BIOS”) may be stored in non-volatile or the like.
  • System memory 1109 typically stores data, computer-executable instructions and/or program modules comprising computer-executable instructions that are immediately accessible to and/or presently operated on by one or more of the processors 1107 .
  • Mass storage devices 1104 and 1110 may be coupled to computing device 1101 or incorporated into computing device 1101 via coupling to the system bus.
  • Such mass storage devices 1104 and 1110 may include a magnetic disk drive which reads from and/or writes to a removable, non-volatile magnetic disk (e.g., a “floppy disk”) 1105 , and/or an optical disk drive that reads from and/or writes to a non-volatile optical disk such as a CD ROM, DVD ROM 1106 .
  • a mass storage device, such as hard disk 1110 may include non-removable storage medium.
  • Other mass storage devices may include memory cards, memory sticks, tape storage devices, and the like.
  • Any number of computer programs, files, data structures, and the like may be stored on the hard disk 1110 , other storage devices 1104 , 1105 , 1106 and system memory 1109 (typically limited by available space) including, by way of example, operating systems, application programs, data files, directory structures, and computer-executable instructions.
  • Output devices such as display device 1102 may be coupled to computing device 1101 via an interface, such as video adapter 1111 .
  • Other types of output devices may include printers, audio outputs, tactile devices or other sensory output mechanisms, or the like.
  • Output devices may enable computing device 1101 to interact with human operators or other machines or systems.
  • a user may interface with computing environment 1100 via any number of different input devices 1103 such as a keyboard, mouse, joystick, game pad, data port, and the like.
  • input devices may be coupled to processor 1107 via input/output interfaces 1112 which may be coupled to system bus 1108 , and may be coupled by other interfaces and bus structures, such as a parallel port, game port, universal serial bus (“USB”), fire wire, infrared port, and the like.
  • input/output interfaces 1112 may be coupled to system bus 1108 , and may be coupled by other interfaces and bus structures, such as a parallel port, game port, universal serial bus (“USB”), fire wire, infrared port, and the like.
  • USB universal serial bus
  • Computing device 1101 may operate in a networked environment via communications connections to one or more remote computing devices through one or more local area networks (“LAN”), wide area networks (“WAN”), storage area networks (“SAN”), the Internet, radio links, optical links and the like.
  • Computing device 1101 may be coupled to a network via network adapter 1113 or the like, or, alternatively, via a modem, digital subscriber line (“DSL”) link, integrated services digital network (“ISDN”) link, Internet link, wireless link, or the like.
  • DSL digital subscriber line
  • ISDN integrated services digital network
  • Communications connection 1114 typically provides a coupling to communications media, such as a network.
  • Communications media typically provide computer-readable and computer-executable instructions, data structures, files, program modules and other data using a modulated data signal, such as a carrier wave or other transport mechanism.
  • modulated data signal typically means a signal that has one or more of its characteristics set or changed in such a mariner as to encode information in the signal.
  • communications media may include wired media, such as a wired network or direct-wired connection or the like, and wireless media, such as acoustic, radio frequency, infrared, or other wireless communications mechanisms.
  • a remote computer or storage device may store computer-readable and computer-executable instructions in the form of software applications and data.
  • a local computer may access the remote computer or storage device via the network and download part or all of a software application or data and may execute any computer-executable instructions.
  • the local computer may download pieces of the software or data as needed, or distributively process the software by executing some of the instructions at the local computer and some at remote computers and/or devices.
  • DSP digital signal processor
  • PLA programmable logic array
  • discrete circuits and the like.
  • DSP digital signal processor
  • electronic apparatus may include computing devices or consumer electronic devices comprising any software, firmware or the like, or electronic devices or circuits comprising no software, firmware or the like.
  • firmware typically refers to executable instructions, code or data maintained in an electronic device such as a ROM.
  • software generally refers to executable instructions, code, data, applications, programs, or the like maintained in or on any form of computer-readable media.
  • computer-readable media typically refers to system memory, storage devices and their associated media, communications media, and the like.

Abstract

A method for providing fault-tolerant network communications between a plurality of nodes for an application, including providing a plurality of initial communications pathways over a plurality of networks coupled between the plurality of nodes, receiving a data packet on a sending node from the application, the sending node being one of the plurality of nodes, the data packet being addressed by the application to an address on one of the plurality of nodes, and selecting a first selected pathway for the data packet from among the plurality of initial communications pathways where the first selected pathway is a preferred pathway.

Description

    RELATED APPLICATION(S)
  • This Application is a Continuation of and claims benefit from U.S. patent application Ser. No. 14/586,919, that was filed on Dec. 30, 2014, and that is a Continuation of U.S. patent application Ser. No. 13/540,548 (U.S. Pat. No. 8,958,325), that was filed on Jul. 2, 2012 (Issued Feb. 17, 2015), and that is a Continuation of U.S. patent application Ser. No. 12/884,101 (U.S. Pat. No. 8,369,208), that was filed on Sep. 16, 2010 (Issued Feb. 5, 2013), and that is a Continuation of U.S. patent application Ser. No. 11/275,185 (U.S. Pat. No. 7,821,930), that was filed on Dec. 16, 2005 (Issued Oct. 26, 2010), and that claims priority from U.S. Provisional Patent Application No. 60/716,122 that was filed on Sep. 12, 2005, each of which is incorporated herein by reference in its entirety.
  • BACKGROUND
  • In a computer networking environment, multiple nodes may communicate with each other over a network. Should the network experience a failure, communication between the nodes may be disrupted.
  • SUMMARY
  • The following presents a simplified summary of the disclosure in order to provide a basic understanding to the reader. This summary is not an extensive overview of the disclosure and it does not identify key or critical elements of the invention or delineate the scope of the invention. Its sole purpose is to present some concepts disclosed herein in a simplified form as a prelude to the more detailed description that is presented later.
  • The following examples provide computer network communication fault-tolerance via unique network stack architectures requiring minimal consideration by application software operating on networked nodes.
  • Many of the attendant features will be more readily appreciated as they become better understood by reference to the following detailed description considered in connection with the accompanying drawings.
  • DESCRIPTION OF THE DRAWINGS
  • The present description will be better understood from the following detailed description read in light of the accompanying drawings, wherein:
  • FIG. 1 is block diagram showing an example network stack architecture.
  • FIG. 2 is a block diagram showing a networked computing environment including two example nodes coupled via two networks.
  • FIG. 3 is a block diagram showing an example fault-tolerant communications driver, NETFT.
  • FIG. 4 is a block diagram showing an example fault-tolerant communications architecture including NETFT and an application.
  • FIG. 5 is a flow diagram showing data flowing through a fault-tolerant communications environment including a source node and a destination node coupled via Path A over network 1 and Path B over network 2.
  • FIG. 6 is a flow diagram showing data flowing through the fault-tolerant communications environment shown in FIG. 5 with the addition of several possible communications failures.
  • FIG. 7 is a block diagram showing and another example of a fault-tolerant communications driver, NETFT.
  • FIG. 8 is a block diagram showing an example fault-tolerant communications architecture including NETFT and an application.
  • FIG. 9 is a flow diagram showing data flowing through a fault-tolerant communications environment including a source node and a destination node coupled via Path A over network 1 and Path B over network 2.
  • FIG. 10 is a flow diagram showing data flowing through the fault-tolerant communications environment shown in FIG. 9 with the addition of several possible communications failures.
  • FIG. 11 is a block diagram showing an example computing environment in which the technology described above may be implemented.
  • Like reference numerals are used to designate like parts in the accompanying drawings.
  • DETAILED DESCRIPTION
  • The detailed description provided below in connection with the appended drawings is intended as a description of the present examples and is not intended to represent the only forms in which the present examples may be constructed or utilized. The description sets forth the functions of the examples and the sequence of steps for constructing and operating the examples. However, the same or equivalent functions and sequences may be accomplished by different examples.
  • Although the present examples are described and illustrated herein as being implemented in a computing and networking system, the system described is provided as an example and not a limitation. As those skilled in the art will appreciate, the present examples are suitable for application in a variety of different types of computing and networking systems.
  • FIG. 1 is block diagram showing an example network stack architecture 100. A network stack (“stack”) generally couples with software applications via network stack interfaces and/or other interfaces to provide network communications functionality to applications. An application is typically said to be at (or coupled to) the “top” of the stack. A network is typically said to be at (or coupled to) the “bottom” of the stack. Various elements of a network stack may be referred to as at or near the top or bottom of the stack, or higher or lower in the stack relative to each other. For example, in FIG. 1, protocol driver 130 is higher in the stack than NIC 180 which is shown at the bottom of the stack in this particular figure. Various depictions of a network stack may or may not include some stack elements, or may group, order or name the elements in various ways, depending on the purpose or focus of the depiction, as understood by those skilled in the art.
  • The term “driver” as used herein refers to a control program or the like that enables a node to operate with a particular device, such as a printer, network interface card, or other computer subsystem, or to operate with one or more programs such as network stacks, protocol drivers, and/or other computer software or firmware or the like. For example, a protocol driver typically operates with a network stack.
  • An application may pass a packet of data to a stack destined for an application operating on another node. In this case, the data is said to flow “down” the stack and is sent out over a network. Data received by a node is said to flow “up” the stack until it reaches the destined application. Such networking systems are well known to those skilled in the art.
  • In one example a stack is based on the Network Driver Interface Specification (“NDIS”) which defines a standard application programming interface (“API”) for network interface cards (“NICs”), such as NIC 180, and abstracts the network hardware from network drivers. NDIS also specifies a standard interface between layered network drivers, thereby abstracting lower-level drivers that manage hardware, such as a miniport driver, from upper-level drivers, such as protocol drivers. Multiple NDIS-conforming protocol drivers may co-exist on a single node. Also, if a node includes multiple NICs, perhaps because it is connected to more than one network, NDIS routes network traffic to the appropriate NIC via its associated driver as indicated by the traffic. An illustration of NDIS is shown in FIG. 1. Other networking stack standards, technologies and/or architectures, such as the Open Data-Link Interface (“ODI”), the Data Link Provider Interface (“DLPI”), the Uniform Driver Interface (“UDI”), or other technologies, may be used with the following examples as well with appropriate modifications, as would be understood by those skilled in the art. As a matter of convenience, NDIS and NDIS terminology is used with examples throughout this description, but other standards, technologies and/or architectures may be used in all of these examples with appropriate modifications, unless otherwise noted.
  • As shown in FIG. 1, coupled to NIC 180 via NDIS 120 is miniport driver 160. A miniport driver typically interacts with NDIS via an NDIS miniport interface 162. The miniport driver 160 may be associated with NIC 180 and may manage its operations, including sending and receiving data through the NIC. The miniport driver 160 typically interfaces with higher-level drivers, such as intermediate driver 140 and protocol driver 130. A miniport driver is considered a NIC driver. NIC miniports generally perform those hardware-specific operations needed to manage a particular NIC with common or NIC-independent functionality provided by NDIS. A node may include multiple NICs with each NIC generally having an associated NIC driver. Some examples in this description describe the use of miniport drivers but, as will be understood by those skilled in the art, any type of NIC driver or the like may be used in these examples, unless otherwise noted.
  • Protocol or transport driver 130 couples to NDIS 120 via an NDIS protocol interface 134. Protocol drivers or transport protocol drivers generally provide the functionality to create, send and receive packets of data that are sent from one node to another through the network stack and over a network. As known to those skilled in the art, a common reliable or guaranteed delivery transport protocol may be TCP/IP (Transmission Control Protocol/Internet Protocol). UDP (User Datagram Protocol) over IP may be a common unreliable or non-guaranteed delivery protocol. TCP, UDP and/or other protocols, such as IPX/SPX (Internet Packet Exchange/Sequenced Packet Exchange), may be used with the following examples unless otherwise noted.
  • NDIS intermediate (“IM”) drivers 140 are shown between protocol drivers 130 and NDIS NIC miniports 160 in FIG. 1. To protocol drivers IM drivers appear to be NDIS miniports while to NIC drivers they look like protocol drivers. Data packets flowing up or down the network stack pass through the IM driver 140 which may ignore, inspect, filter, forward, redirect and/or modify the data packets. An intermediate driver 140 may also be known as a filter driver.
  • FIG. 2 is a block diagram showing a networked computing environment 200 including two example nodes 210 and 260 coupled via two networks 202 and 282. Nodes 210 and 260 may each be personal computers (“PCs”), client computers, servers, hosts, laptops, portable devices, consumer electronic devices, or any of various other types of computing or processing devices, machines or systems. One non-limiting example of a type of computing system is described in detail below with respect to FIG. 11. Circles 212, 214, 262, and 264 represent NICs associated with their respective nodes. One non-limiting example of a type of NIC is further described below with respect to FIG. 11 as network adapter 1113.
  • As used herein, the term node refers to any computing system, device, or process that is uniquely addressable, or otherwise uniquely identifiable, in a network (e.g., network 202) and that is operable to communicate with other nodes in the network. For example, and without limitation, a node may be a personal computer, a server computer, a hand-held or laptop device, a tablet device, a multiprocessor system, a microprocessor-based system, a set top box, a consumer electronic device, a network PC, a minicomputer, a mainframe computer, or the like. A non-limiting example of a node 210, in the form of a computing system, is set forth below with respect to FIG. 11.
  • Networks 202 and 282 may be the same network, may exist on the same or different subnets, may be logically or physically coupled or isolated from each other, may use similar or different networking technologies, etc. In particular, networks 202 and 282 may be routed networks, that is, networks including routers that forward routable protocol packets. Routable protocols are typically considered communications protocols used to route data from one network to another. An example of a routable protocol is TCP/IP. Sending a data packet in a routable fashion implies using a routable transport protocol to format and/or send the data packet. Those skilled in the art will be familiar with routable protocols and routing network topologies, systems and architectures.
  • In one example, networks 202 and 282 may be independent of each other such that if there is a problem or failure with one network it is unlikely to affect the operational status of the other. In other examples, three or more networks may be used. In examples where greater degrees of fault-tolerance are desired a larger number of networks along with the associated connectivity of nodes to those networks, including a similar number of NICs installed on a node, may be employed.
  • NIC 212, associated with node 210, is shown with an example address of 172.56.48.37 and is coupled to network 1 202. NIC 214, also associated with node 210, is shown with an example address of 197.71.48.38 and is coupled to network 2 282. NIC 262, associated with node 260, is shown with an example address of 172.56.48.38 and is also coupled to network 1 202. NIC 264, also associated with node 260, is shown with an example address of 197.71.48.39 and is also coupled to network 2 282. These addresses may, in practice, be IPv4 or IPv6 addresses or the like, or any other type of network address typically related to the protocol being used.
  • Each node may include one or more NICs. Arrows 201 and 203, also shown in FIG. 11 as arrow 1114, represent a first communications route or pathway (“Path A”) over network 1 202 between nodes 210 and 260. Arrows 281 and 283 represent a second communications route or pathway (“Path B”) over network 2 282 between nodes 210 and 260. In practice, there may be one or more pathways over one or more networks between the two or more nodes in environment 200. The term “pathway” as used herein is defined as a communications route, or communications link, between nodes in a network. Such a route or link may be dynamic in that the exact route between nodes may change over time.
  • Blocks 216 and 266 represent an application and a network stack, including a fault-tolerant communications (“FT”) driver, provided on each of nodes 210 and 260. The FT driver of block 216 is shown with an example address of 10.0.0.1 and the FT driver of block 266 is shown with an example address of 10.0.0.2. These addresses are typically considered virtual addresses. These addresses may be IPv4 or IPv6 addresses or the like, or any other type of network or communications address. FT drivers may or may not have virtual addresses as shown in the various examples below.
  • A fault-tolerant network stack is a network stack including an FT driver, such as NETFT described below in connection with FIG. 3, or the like. An FT driver, such as NETFT, operating in combination with a network stack typically allows nodes to communicate with each other via one or more communications paths, such as Path A and Path B, over one or more networks. Should any of these communications paths fail, the nodes may continue communicating given at least one operational pathway. Such a pathway failure may result from failure of a NIC or failure of any element of a pathway, including connections, cabling or other communications media (including radio frequency (“RF”) or infrared (“IR”) and the like), routers, hubs, switches, firewalls, Internet Service Providers (“ISPs”), power failure to any node, device or system of the network, or the like.
  • In one example, a communications failure may result in a plug-and-play (“PnP”) event. A PnP event may indicate the removal of a NIC from its node or to a media sense change. A media sense disconnect, for example, typically results from a failure that causes the NIC to lose the signal or carrier on the network media, such as a network cable, RF or IR link or the like. A media sense disconnect may be caused by disconnecting the network cable or carrier from the NIC or powering off the other end of the cable (a hub or switch, for example). A media sense connect is typically the opposite, such as reconnecting the cable, re-powering on the hub or switch or the like. These types of events, also known as connectivity events, are generally local events in that they occur on or are proximate to the node itself. Such local connectivity events typically result in an event indication, such as a PnP event the like, on a node.
  • In another example, a communications failure may be detected by using heartbeat packets sent between nodes. Failure of such a heartbeat packet may indicate failure of a pathway between nodes. Heartbeat packets tend to be marked such that the FT driver can detect them upon receipt and remove them for the packet flow being passed up the network stack. In one example, heartbeat packets may be implemented using route control protocol (“RCP”) by forming RCP packets. Such heartbeat packets may be used to validate the end-to-end operational status of a pathway. That is, by sending a heartbeat packet from node 210 over Path A to node 260 and by node 210 receiving a reply to the sent heartbeat packet from node 260, it is generally considered that Path A is end-to-end operational. Should the heartbeat fail (no heartbeat reply received in response to the heartbeat sent), such a failure may indicate that Path A is not operational, perhaps due to failure of some element of network 1 202 such as a router, switch, connection, or the like, or due to the target node itself failing. In particular, node 210 may have an operational NIC 212 and valid media sense, indicating that it is properly connected to the network, hut may still detect a heartbeat failure due to some network or system failure down the line.
  • FIG. 3 is a block diagram showing an example fault-tolerant communications driver, NETFT 300. NETFT 300 may be implemented as an NDIS miniport driver (FIG. 1, 160) for use with an NDIS network stack and for providing network communications between nodes tolerant of pathway failures. That is, communications between two or more nodes may continue when each is using a NETFT despite failure of any component in the pathway as long as at least one pathway remains operational.
  • In one example, implementation of the FT driver as an NDIS miniport driver provides at least two benefits. First, because such an FT driver generally sits below any protocol drivers in the stack, protocol reliability tends to be provided by any higher-level reliable protocol driver which is generally unaffected by the addition of link-level fault-tolerance provided by an FT driver. For example, when using an FT driver in combination with a protocol driver such as a TCP/IP driver, the FT driver will typically detect failed pathways and route data packets over end-to-end operational pathways independent of any protocol driver. Should any packet loss occur due to switching pathways, the TCP/IP protocol driver, which generally sits above the FT driver in the stack, tends to detect such losses and perform any retry or resend operations to ensure that the reliable protocol succeeds in packet delivery.
  • A second benefit of placing the FT driver below the protocol driver in the stack is that typically no degradation of the routability of the protocol is introduced. When so configured, any tunneling operation that an FT driver performs on a data packet may employ a routable protocol, such as TCP or UDP, thus ensuring that such data is routable, in addition to being link-level fault tolerant. To “routeably tunnel” a data packet is to tunnel a data packet using a routable protocol.
  • NETFT, as a part of a network stack, generally couples to a software application via NDIS or other network stack interfaces. Such a coupling generally enables applications to send and receive data packets over networks coupled to the bottom of the stack. In one example, applications tend to use a virtual address as the source address for their data packets, this virtual address being known to NETFT and mapped and communicated to other nodes on the network as described below. As shown in FIG. 3, NETFT includes a miniport adapter 302 (also known as a processing element) a routing database 304, and one or more route monitor adapters 306 and tunnel adapters 308.
  • Tunnel adapter 308 typically represents one NIC on the local node (or, in some instances, a virtual NIC) and maintains a socket used to tunnel packets to NETFT on the target node. There is typically one tunnel adapter 308 associated with each NIC on the local node with each NIC being coupled to a network providing a pathway to another node. Each network may or may not be isolated from any other network. A tunnel adapter 308 is typically associated with a tunneling protocol driver and tunnels data packets through a tunneling protocol to and from its associated NIC via NDIS interfaces. One example of a tunneling protocol is UDP. Alternatively, other protocols, such as TCP, IPX, or SPX, may be used for tunneling. A tunnel adapter 308 may become inactive should the associated NIC or media connection become inactive.
  • A routing database 304, as implemented in NETFT, is typically a simple data structure, that may be located in system memory, that includes entries mapping a virtual address for one or more pathways to a similar NETFT on another node. In one example, mappings are represented by route monitor adapters such as route monitor adapter 306 which are typically associated with a tunnel adapter such as tunnel adapter 308. Generally a routing database such as routing database 304 will include one set of route adapters for each tunnel adapter, each route adapter being associated with a different target node reachable over the pathway associated with the tunnel adapter. When using TCP/IP, for example, the database may map a destination virtual address to a physical address of a specific remote node.
  • A routing database 304 may also include priority information for each pathway. Such priority information may be used to indicate a preferred or primary pathway to another node and/or may include information about pathway speed or other characteristics. A preferred pathway is the pathway calculated by NETFT to be used over other possible pathways, when possible, based on priority information and/or pathway status. Priority information may alternatively indicate a round-robin load balancing algorithm for making use of multiple pathways to a target node to load-balance traffic over the pathways, or enable some other pathway prioritization scheme.
  • An example routing table database 304 mapping table is shown in Table 1.
  • TABLE 1
    Destination Address Type Address Priority
    Virtual 10.0.0.2
    Physical: Path A 172.56.48.38 1
    Physical: Path B 197.71.48.39 2
  • Referring to table 1 and FIG. 2, table 1 shows an example mapping table as might be used by NETFT operating on node 216. Table 1 shows virtual destination address 10.0.0.2, the virtual address as shown for node 266, mapped to physical address 172.56.48.38 associated with Path A to node 266 and physical address 197.71.48.39 associated with Path B to node 266. Path A is shown with first priority and Path B with second priority. Table 1 is provided as an example and is not intended to be limiting.
  • When sending data from node 216 to node 266, such a mapping table is typically used to tunnel a packet destined to virtual destination address 10.0.0.2 by forwarding the packet via a tunneling protocol, such as UDP, to physical destination address 172.56.48.38, thus tunneling the packet from node 216 over Path A to node 266. One such mapping table may be created in the routing database (FIG. 3, 304) for each set of pathways established between two nodes. Such a mapping table may be implemented in various forms, use various priority schemes and/or store other information including pathway operational status. The mapping table structure, number of pathways, address formats, etc. shown in Table 1 are provided as examples and are not intended to be limiting.
  • The local node virtual address, remote node virtual addresses, and priority and other pathway information are typically provided to nodes by an out-of-band mechanism and passed to NETFT via its NDIS interfaces. This out-of-band mechanism may be as simple as a systems administrator using a management application to specify the information, or it may be an automated system or the like. Such out-of-band mechanisms are well known to those skilled in the art.
  • As shown in FIG. 3, miniport adapter 302 (also known as the processing element of the driver) typically parses a data packet flowing down the network stack, examines the destination virtual address of the packet and uses information from the routing database 304 to determine which tunnel adapter 308 to tunnel the data packet through. Incoming packets, or data packets flowing up the stack, are forwarded up the stack toward their destination virtual address, the tunneling protocol having previously removed the tunneling packet headers. In particular, the tunnel adapter 308 inspects incoming packets and forwards heartbeat packets to a route monitor adapter 306 and forwards other packets up the stack via a miniport adapter 302. Aspects of tunneling data packets using a tunneling protocol and how protocol headers are added and removed by protocol drivers is well known to those skilled in the art.
  • Route monitor adapter 306 typically represents a remote node accessible over a specific pathway identified by an associated tunnel adapter. The route monitor adapter 306 will typically provide a physical address for the remote node, the physical address also corresponding to a specific pathway to the remote node. This physical address is typically used for mappings in a routing database 304. There is typically one route monitor adapter for each distinct pathway to a remote node, each route monitor adapter being associated with a tunnel adapter representing a pathway. In one example, referring back to FIG. 2, node 210 is shown coupled to node 260 over two pathways, one through network 1 202 (“Path A”) and the other through network 2 282 (“Path B”). NETFT operating on node 210 may include a first route monitor adapter (“RMA-A”) providing remote node 260's physical address 172.56.48.38 associated with its NIC 262. RMA-A may be associated with a first tunnel adapter (“TA-A”) on node 210 which may be associated with Path A. NETFT on node 210 may also include a second route monitor adapter (“RMA-B”) providing remote node 260's second physical address 197.71.48.39 associated with its NIC 264. RMA-B may be associated with a second tunnel adapter (“TA-B”) on node 210 which may be associated with Path B.
  • Referring to FIG. 3, route monitor adapter 306 typically monitors the health of a pathway to a remote node and indicates a failed or non-operational pathway in the routing database 304. Monitoring typically includes receiving any event indications and/or noting any heartbeat failures and updating the database 304 accordingly. In one example, an event indicating the failure of a NIC or media connection may result in the disabling of the tunnel adapter 308. In another example, a heartbeat failure may result in the disabling of the route monitor adapter 306 associated with the specific remote node for which the heartbeat failed.
  • FIG. 4 is a block diagram showing an example fault-tolerant communications architecture 216 including NETFT 300 and an application 402. In this example, the application 402 sends data packets to NETFT 300 via the stack using a virtual source address 217 and a virtual destination address representing the destination node. Such out-going data packets flow via path 480 from the application and through the network stack to the driver 300. The driver 300 typically determines which of the possible pathways each packet should take, generally using priority information and pathway operational status information stored in the routing database, and tunnels the packet to the target node over the selected pathway using the appropriate physical source address 422 or 424.
  • Application 402 may send a data packet through NETFT 300 via the TCP protocol, as shown in FIG. 4. Alternatively UDP or any other protocol may be used. Also, as shown, NETFT 300 may use the UDP protocol to tunnel packets to the target node. Alternatively, TCP or any other protocol may be used for tunneling. Further, alternate examples may not make use of miniport adapters or NDIS drivers but may use other mechanisms or architectures to perform similar functions. Finally, the various elements of the network stack and the like may operate in either a User Mode or a Kernel Mode, either as shown or otherwise, or on systems with or without equivalent modes of operation.
  • FIG. 5 is a flow diagram showing data flowing through a fault-tolerant communications environment 500 including a source node 216 and a destination node 266 coupled via Path A over network 1 202 and Path B over network 2 282. In this example environment 500, data is shown being sent from the application operating on node 216 to the application listening on the destination virtual address on node 266. The data packets flow down the network stack operating on node 216 using the TCP protocol into NETFT as shown by path 501. Assuming, as shown, that Path A is the selected pathway, NETFT maps the data packets from the source virtual address being used by the application to Path A and tunnels the data through the UDP protocol using the Path A physical destination address for target node 266, out NIC 1 of node 216 as further shown by path 501 and onto network 1 202 via link 201. The data then flows through network 1 202, over link 203 and to node 266, flowing up the network stack operating on node 266 as shown by path 503. The data then flows through the UDP protocol driver, the same protocol that was used on the sending side as the tunneling protocol, where the UDP protocol headers are stripped off the data packets which are then passed into NETFT operating on node 266. NETFT then forwards the data packets up the stack to the application which is listening on the destination virtual address. Responses tend to flow in the reverse order.
  • FIG. 6 is a flow diagram showing data flowing through the fault-tolerant communications environment 500 shown in FIG. 5 with the addition of several possible communications failures 610, 612, 620, 622, and 630. Other communications failures are also possible. Failure 610 indicates a failure of NIC I operating on the sending node 216. Such a failure may occur should NIC 1 be removed from the node, should the driver of NIC 1 fail, should NIC 1 itself fail, or the like. The failure may be detected by NETFT via an event indication, such as a PnP event or the like, and/or a heartbeat failure. In such a situation Path A is typically considered to have failed and NETFT will select an alternate end-to-end-operational pathway. An end-to-end operational pathway is typically a pathway that can successfully deliver data from the source node and application all the way to the destination node and application.
  • Failure 620 indicates a failure of the network media coupling with NIC 1 of node 216. This failure may be due to a cable being disconnected from NIC 1, from the cable becoming disconnected from some device of network 1 202, from the device the cable is connected to on the network side being powered down or failing, or the like. This type of failure may also be detected by NETFT via an event indication, such as a PnP event or the like, and/or a heartbeat failure and an alternate pathway selected.
  • Failure 630 indicates a failure of some type within network 202 resulting in data packets failing to reach destination node 266. In this failure case, sending node 216 may still be coupled to network 202 with a proper media sense indication, yet Path A has become disrupted further down the network. Given such a failure, NETFT operating on sending node 216 may not detect the failure via an event indication if local indications show connectivity to the network 202 as good, but may detect the failure via Path A heartbeat failure.
  • Failure 622 of link 203 and failure 612 of NIC 1 operating on receiving node 266 tend to be similar to the corresponding failures shown for node 216. But these failures, not being local to node 216 may not be detected via event indications but may be detected via heartbeat failure.
  • Any of these failures, and other failures, may be detected by NETFT operating on node 216 and result in it selecting an alternate end-to-end operational pathway, such as Path B over network 2 282. In this example, as shown in FIG. 6, NETFT tunnels data down alternate path 681 and over network 2 282 to receiving node 266. Should the failure condition be corrected and end-to-end operational status restored on Path A, NETFT operating on sending node 216 may detect the recovery and again make use of Path A. Further, any responses from node 266 back to node 216 may be tunneled in a similar fault-tolerant fashion by NETFT.
  • FIG. 7 is a block diagram showing and another example of a fault-tolerant communications driver, NETFT 700. This example is similar to the example shown in FIG. 3 hut includes variations as described below. In this example, a software application may not need to use virtual addresses. Instead, an application may use a physical destination address to address data packets to the target node.
  • Protocol adapter 710 generally couples to miniport adapter 702 (also known as the processing element of the driver) and to a NIC miniport adapter (not shown). There is typically one protocol adapter for each NIC installed on the node, each protocol adapter being associated with a NIC via its NIC adapter. As each protocol adapter is associated with a NIC, it is also associated with the pathway coupled to the NIC. The protocol adapter 710 is operable to accept data packets from an application via the processing element 702 and pass the data packets to the associated NIC without the need for tunneling.
  • Processing element 702 typically parses a data packet flowing down the network stack, examines the physical destination address of the packet and uses information from the routing database 704 to determine if the packet can be forwarded over a protocol adapter 710 or needs to be tunneled over a tunnel adapter 308 to the target node. Generally, if the pathway indicated by the physical destination address is end-to-end operational, the data packet will be sent over that pathway. Otherwise and alternate pathway may be selected over which the packet may be tunneled.
  • In this example the routing database 704 maintains mappings of physical destination addresses and pathways, along with priority and other information as described above. An example routing database 704 mapping table is shown in Table 2.
  • TABLE 2
    Destination Address Type Address Priority
    Physical: Path A 172.56.48.38 1
    Physical: Path B 197.71.48.39 2
  • Referring to Table 2 and FIG. 2, Table 2 shows an example mapping table as might be used by NETFT operating on node 216. Table 2 shows a mapping including physical destination address 172.56.48.38 associated with Path A to node 266 and the physical destination address 197.71.48.39 associated with Path B to node 266. Path A is shown with first priority and Path B with second priority.
  • When sending data from node 216 to node 266, such a mapping table is typically used in forwarding (or tunneling if needed) a data packet being sent to physical destination address 172.56.48.38 of node 266. If the pathway associated with the original destination address is operational, the data packet tends to be forwarded to the destination node without tunneling. If that pathway in not available, then the data packet is sent over the alternate pathway to physical destination address 197.71.48.39 of node 266 via tunneling. Other aspects of NETFT 700 are generally similar to those of NETFT as described for FIG. 3.
  • FIG. 8 is a block diagram showing an example fault-tolerant communications architecture 216 including NETFT 700 and an application 402. In this example, application 402 sends data packets to NETFT 700 via the stack using a physical source address and a physical destination address 801 representing the destination node. Such out-going data packets flow via path 880 from the application and through the network stack to the driver 700. The driver 700 typically determines which of the possible pathways each packet should take, generally using priority information and pathway operational status information stored in the routing database, and either forwards the packet to the target node over pathway indicated by the original physical destination address or, if that pathway is not end-to-end operation, tunnels the packet over an alternate pathway as indicated in this example by route 882 and NIC 2 892.
  • Application 402 may send a data packet through NETFT 700 via the TCP protocol, as shown in FIG. 8. Alternatively UDP or any other protocol may be used. Also, as shown, NETFT 700 may use the UDP protocol to tunnel packets to the target node. Alternatively, TCP or any other protocol may be used for tunneling. Further, other examples may not make use of NDIS drivers but may use other mechanisms or architectures to perform similar functions. Finally, the various elements of the network stack and the like may operate in either a User Mode or a Kernel Mode, either as shown or otherwise, or on systems with or without equivalent modes of operation.
  • FIG. 9 is a flow diagram showing data flowing through a fault-tolerant communications environment 900 including a source node 816 and a destination node 966 coupled via Path A over network 1 202 and Path B over network 2 282. In this example environment 900, data is shown being sent from the application operating on node 216 to the application listening on the destination physical address on node 266. The data packets flow down the network stack operating on node 216 using the TCP protocol into NETFT as shown by path 901. Assuming, as shown, that Path A is the selected pathway, NETFT forwards the data packets using the physical destination address provided by the application via NIC 1 of node 216 over Path A and network 1 202 via link 201. The data then flows through network 1 202, over link 203 and to node 966, flowing up the network stack operating on node 966 as shown by path 903. The data then flows through NETFT and the protocol driver (a protocol driver for the same protocol that was used on the sending side as the sending protocol) and up to the application. Responses tend to flow in the reverse order.
  • FIG. 10 is a flow diagram showing data flowing through the fault-tolerant communications environment 900 shown in FIG. 9 with the addition of several possible communications failures 1010, 1012, 1020, 1022, and 1030. Other communications failures are also possible. Failure 1010 indicates a failure of NIC 1 operating on the sending node 816. Such a failure may occur should NIC 1 be removed from the node, its NIC driver fail, the NIC itself fail, or the like. The failure may be detected by NETFT via an event indication, such as a PnP event or the like, and/or a heartbeat failure. In such a situation Path A is typically considered to have failed and NETFT will select an alternate end-to-end-operational pathway.
  • Failure 1020 indicates a failure of the network media coupling with NIC 1 of node 816. This failure may be due to a cable being disconnected from NIC 1, from the cable becoming disconnected from some device of network 1 202, from the device the cable is connected to on the network side being powered down or failing, or the like. This type of failure may also be detected by NETFT via an event indication, such as a PnP event or the like, and/or a heartbeat failure and an alternate pathway selected.
  • Failure 1030 indicates a failure of some type within network 202 resulting in data packets failing to reach destination node 966. In this failure case, sending node 816 may still be coupled to network 202 with a proper media sense indication, yet Path A has become disrupted further down the network. Given such a failure, NETFT operating on sending node 816 may not detect the failure via an event indication, such as a PnP event or the like, if local indications show connectivity to the network 202 as good, but may detect the failure via Path A heartbeat failure.
  • Failure 1022 of link 203 and failure 1012 of NIC 1 operating on receiving node 966 tend to be similar to the corresponding failures shown for node 816. But these failures, not being local to node 816 may not be detected via event indications but may be detected via heartbeat failure.
  • Any of these failures, and other failures, may be detected by NETFT operating on node 816 and result in it selecting an alternate end-to-end operational pathway, such as Path B over network 2 282. In this example, as shown in FIG. 10, NETFT tunnels data down alternate path 1081 and over network 2 282 to receiving node 966. Should the failure condition be corrected and end-to-end operational status restored on Path A, NETFT operating on sending node 816 may detect the recovery and again make use of Path A. Further, any responses from node 966 back to node 816 may be forwarded or tunneled, depending on the operational status of Path A and Path B, in a similar fault-tolerant fashion by its NETFT.
  • FIG. 11 is a block diagram showing an example computing environment 1100 in which the technology described above may be implemented. A suitable computing environment may be implemented with numerous general purpose or special purpose systems. Examples of well known systems may include, but are not limited to, personal computers (“PC”), hand-held or laptop devices, microprocessor-based systems, multiprocessor systems, servers, workstations, consumer electronic devices, set-top boxes, and the like.
  • Computing environment 1100 generally includes a general-purpose computing system in the form of a computing device 1101 coupled to various peripheral devices 1102, 1103, 1104 and the like. System 1100 may couple to various input devices 1103, including keyboards and pointing devices, such as a mouse or trackball, via one or more I/O interfaces 1112. The components of computing device 1101 may include one or more processors (including central processing units (“CPU”), graphics processing units (“CPU”), microprocessors (“uP”), and the like) 1107, system memory 1109, and a system bus 1108 that typically couples the various components. Processor 1107 typically processes or executes various computer-executable instructions to control the operation of computing device 1101 and to communicate with other electronic and/or computing devices, systems or environment (not shown) via various communications connections such as a network connection 1114 or the like. System bus 1108 represents any number of several types of bus structures, including a memory bus or memory controller, a peripheral bus, a serial bus, an accelerated graphics port, a processor or local bus using any of a variety of bus architectures, and the like.
  • System memory 1109 may include computer readable media in the form of volatile memory, such as random access memory (“RAM”), and/or non-volatile memory, such as read only memory (“ROM”) or flash memory (“FLASH”). A basic input/output system (“BIOS”) may be stored in non-volatile or the like. System memory 1109 typically stores data, computer-executable instructions and/or program modules comprising computer-executable instructions that are immediately accessible to and/or presently operated on by one or more of the processors 1107.
  • Mass storage devices 1104 and 1110 may be coupled to computing device 1101 or incorporated into computing device 1101 via coupling to the system bus. Such mass storage devices 1104 and 1110 may include a magnetic disk drive which reads from and/or writes to a removable, non-volatile magnetic disk (e.g., a “floppy disk”) 1105, and/or an optical disk drive that reads from and/or writes to a non-volatile optical disk such as a CD ROM, DVD ROM 1106. Alternatively, a mass storage device, such as hard disk 1110, may include non-removable storage medium. Other mass storage devices may include memory cards, memory sticks, tape storage devices, and the like.
  • Any number of computer programs, files, data structures, and the like may be stored on the hard disk 1110, other storage devices 1104, 1105, 1106 and system memory 1109 (typically limited by available space) including, by way of example, operating systems, application programs, data files, directory structures, and computer-executable instructions.
  • Output devices, such as display device 1102, may be coupled to computing device 1101 via an interface, such as video adapter 1111. Other types of output devices may include printers, audio outputs, tactile devices or other sensory output mechanisms, or the like. Output devices may enable computing device 1101 to interact with human operators or other machines or systems. A user may interface with computing environment 1100 via any number of different input devices 1103 such as a keyboard, mouse, joystick, game pad, data port, and the like. These and other input devices may be coupled to processor 1107 via input/output interfaces 1112 which may be coupled to system bus 1108, and may be coupled by other interfaces and bus structures, such as a parallel port, game port, universal serial bus (“USB”), fire wire, infrared port, and the like.
  • Computing device 1101 may operate in a networked environment via communications connections to one or more remote computing devices through one or more local area networks (“LAN”), wide area networks (“WAN”), storage area networks (“SAN”), the Internet, radio links, optical links and the like. Computing device 1101 may be coupled to a network via network adapter 1113 or the like, or, alternatively, via a modem, digital subscriber line (“DSL”) link, integrated services digital network (“ISDN”) link, Internet link, wireless link, or the like.
  • Communications connection 1114, such as a network connection, typically provides a coupling to communications media, such as a network. Communications media typically provide computer-readable and computer-executable instructions, data structures, files, program modules and other data using a modulated data signal, such as a carrier wave or other transport mechanism. The term “modulated data signal” typically means a signal that has one or more of its characteristics set or changed in such a mariner as to encode information in the signal. By way of example, and not limitation, communications media may include wired media, such as a wired network or direct-wired connection or the like, and wireless media, such as acoustic, radio frequency, infrared, or other wireless communications mechanisms.
  • Those skilled in the art will realize that storage devices utilized to provide computer-readable and computer-executable instructions and data can be distributed over a network. For example, a remote computer or storage device may store computer-readable and computer-executable instructions in the form of software applications and data. A local computer may access the remote computer or storage device via the network and download part or all of a software application or data and may execute any computer-executable instructions. Alternatively, the local computer may download pieces of the software or data as needed, or distributively process the software by executing some of the instructions at the local computer and some at remote computers and/or devices.
  • Those skilled in the art ill also realize that, by utilizing conventional techniques, all or portions of the software's computer-executable instructions may be carried out by a dedicated electronic circuit such as a digital signal processor (“DSP”), programmable logic array (“PLA”), discrete circuits, and the like. The term “electronic apparatus” may include computing devices or consumer electronic devices comprising any software, firmware or the like, or electronic devices or circuits comprising no software, firmware or the like.
  • The term “firmware” typically refers to executable instructions, code or data maintained in an electronic device such as a ROM. The term “software” generally refers to executable instructions, code, data, applications, programs, or the like maintained in or on any form of computer-readable media. The term “computer-readable media” typically refers to system memory, storage devices and their associated media, communications media, and the like.

Claims (20)

1. A first electronic device comprising:
a first network adapter;
a second network adapter;
a fault tolerant driver paired with the first network adapter;
a first protocol driver coupled to the fault tolerant driver;
a second protocol driver coupled to the fault tolerant driver and paired with the second network adapter, the first electronic device configured to provide fault tolerant communications, via the fault tolerant driver, with a second electronic device based on fault tolerant sending and fault tolerant receiving;
the fault tolerant sending comprising:
receiving, by the fault tolerant driver, out-going data via the first protocol driver;
selecting, by the fault tolerant driver based on a condition, a first pathway or a second pathway;
first routing, by the fault tolerant driver through the first pathway to the second electronic device via the first protocol driver and the first network adapter in response to selecting the first pathway, the out-going data; and
second routing, by the fault tolerant driver via the second pathway to the second electronic device via the first protocol driver, the second protocol driver, and the second network adapter in response to selecting the second pathway, the out-going data; and
the fault tolerant receiving comprising:
first forwarding, by the fault tolerant driver to the first protocol driver in response to the fault tolerant driver receiving in-coming data from the second electronic device through the first pathway via the first network adapter, at least a portion of the in-coming data; and
second forwarding, by the fault tolerant driver to the first protocol driver in response to the fault tolerant driver receiving in-coming data from the second electronic device through the second pathway via the second network adapter and the second protocol driver, at least a portion of the received in-coming data.
2. The first electronic device of claim 1 where the out-going data is provided by an application to the protocol driver.
3. The first electronic device of claim 2 where the out-going data as provided by the application to the protocol driver is addressed by the application to the second electronic device using on a physical address of the second electronic device.
4. The first electronic device of claim 1 where the condition indicates a failure of a pathway.
5. The first electronic device of claim 4 where the failure is detected based on one or more heartbeat packets.
6. The first electronic device of claim 1 where the condition indicates a preferred pathway.
7. The first electronic device of claim 6 where the fault tolerant driver is configured to determine the preferred pathway.
8. A first electronic device comprising:
a first network adapter;
a second network adapter;
a fault tolerant driver paired with the first network adapter;
a first protocol driver coupled to the fault tolerant driver;
a second protocol driver coupled to the fault tolerant driver and paired with the second network adapter, the first electronic device configured to provide fault tolerant communications, via the fault tolerant driver, with a second electronic device based on fault tolerant sending comprising:
receiving, by the fault tolerant driver, out-going data via the first protocol driver;
selecting, by the fault tolerant driver based on a condition, a first pathway or a second pathway;
first routing, by the fault tolerant driver through the first pathway to the second electronic device via the first protocol driver and the first network adapter in response to selecting the first pathway, the out-going data; and
second routing, by the fault tolerant driver via the second pathway to the second electronic device via the first protocol driver, the second protocol driver, and the second network adapter in response to selecting the second pathway, the out-going data.
9. The first electronic device of claim 8 where the out-going data is provided by an application to the protocol driver.
10. The first electronic device of claim 9 where the out-going data as provided by the application to the protocol driver is addressed by the application to the second electronic device using on a physical address of the second electronic device.
11. The first electronic device of claim 8 where the condition indicates a failure of a pathway.
12. The first electronic device of claim 11 where the failure is detected based on one or more heartbeat packets.
13. The first electronic device of claim 8 where the condition indicates a preferred pathway.
14. The first electronic device of claim 8 where the provided fault tolerant communications is further based on fault tolerant receiving comprising:
first forwarding, by the fault tolerant driver to the first protocol driver in response to the fault tolerant driver receiving in-coming data from the second electronic device through a first pathway via the first network adapter, at least a portion of the in-coming data; and
second forwarding, by the fault tolerant driver to the first protocol driver in response to the fault tolerant driver receiving in-coming data from the second electronic device through a second pathway via the second network adapter and the second protocol driver, at least a portion of the received in-coming data.
15. A first electronic device comprising:
a first network adapter;
a second network adapter;
a fault tolerant driver paired with the first network adapter;
a first protocol driver coupled to the fault tolerant driver;
a second protocol driver coupled to the fault tolerant driver and paired with the second network adapter, the first electronic device configured to provide fault tolerant communications, via the fault tolerant driver, with a second electronic device based on fault tolerant receiving comprising:
first forwarding, by the fault tolerant driver to the first protocol driver in response to the fault tolerant driver receiving in-coming data from the second electronic device through a first pathway via the first network adapter, at least a portion of the in-coming data; and
second forwarding, by the fault tolerant driver to the first protocol driver in response to the fault tolerant driver receiving in-coming data from the second electronic device through a second pathway via the second network adapter and the second protocol driver, at least a portion of the received in-coming data.
16. The first electronic device of claim 15 where some of the at least a portion of the received in-coming data is passed by the first protocol driver to an application.
17. The first electronic device of claim 15 where the provided fault tolerant communications is further based on fault tolerant sending comprising:
receiving, by the fault tolerant driver, out-going data via the first protocol driver;
selecting, by the fault tolerant driver based on a condition, the first pathway or the second pathway;
first routing, by the fault tolerant driver through the first pathway to the second electronic device via the first protocol driver and the first network adapter in response to selecting the first pathway, the out-going data; and
second routing, by the fault tolerant driver via the second pathway to the second electronic device via the first protocol driver, the second protocol driver, and the second network adapter in response to selecting the second pathway, the out-going data.
18. The first electronic device of claim 17 where the condition indicates a failure of a pathway.
19. The first electronic device of claim 17 where the condition indicates a preferred pathway.
20. The first electronic device of claim 19 where the fault tolerant driver is configured to determine the preferred pathway.
US15/002,717 2005-09-12 2016-01-21 Fault-tolerant communications in routed networks Abandoned US20160142289A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US15/002,717 US20160142289A1 (en) 2005-09-12 2016-01-21 Fault-tolerant communications in routed networks

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
US71612205P 2005-09-12 2005-09-12
US11/275,185 US7821930B2 (en) 2005-09-12 2005-12-16 Fault-tolerant communications in routed networks
US12/884,101 US8369208B2 (en) 2005-09-12 2010-09-16 Fault-tolerant communications in routed networks
US13/540,548 US8958325B2 (en) 2005-09-12 2012-07-02 Fault-tolerant communications in routed networks
US14/586,919 US9253293B2 (en) 2005-09-12 2014-12-30 Fault-tolerant communications in routed networks
US15/002,717 US20160142289A1 (en) 2005-09-12 2016-01-21 Fault-tolerant communications in routed networks

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
US14/586,919 Continuation US9253293B2 (en) 2005-09-12 2014-12-30 Fault-tolerant communications in routed networks

Publications (1)

Publication Number Publication Date
US20160142289A1 true US20160142289A1 (en) 2016-05-19

Family

ID=37854967

Family Applications (7)

Application Number Title Priority Date Filing Date
US11/275,185 Expired - Fee Related US7821930B2 (en) 2005-09-12 2005-12-16 Fault-tolerant communications in routed networks
US12/884,096 Active US8169894B2 (en) 2005-09-12 2010-09-16 Fault-tolerant communications in routed networks
US12/884,101 Active US8369208B2 (en) 2005-09-12 2010-09-16 Fault-tolerant communications in routed networks
US13/540,548 Active US8958325B2 (en) 2005-09-12 2012-07-02 Fault-tolerant communications in routed networks
US13/540,527 Abandoned US20120272092A1 (en) 2005-09-12 2012-07-02 Fault-tolerant communications in routed networks
US14/586,919 Active US9253293B2 (en) 2005-09-12 2014-12-30 Fault-tolerant communications in routed networks
US15/002,717 Abandoned US20160142289A1 (en) 2005-09-12 2016-01-21 Fault-tolerant communications in routed networks

Family Applications Before (6)

Application Number Title Priority Date Filing Date
US11/275,185 Expired - Fee Related US7821930B2 (en) 2005-09-12 2005-12-16 Fault-tolerant communications in routed networks
US12/884,096 Active US8169894B2 (en) 2005-09-12 2010-09-16 Fault-tolerant communications in routed networks
US12/884,101 Active US8369208B2 (en) 2005-09-12 2010-09-16 Fault-tolerant communications in routed networks
US13/540,548 Active US8958325B2 (en) 2005-09-12 2012-07-02 Fault-tolerant communications in routed networks
US13/540,527 Abandoned US20120272092A1 (en) 2005-09-12 2012-07-02 Fault-tolerant communications in routed networks
US14/586,919 Active US9253293B2 (en) 2005-09-12 2014-12-30 Fault-tolerant communications in routed networks

Country Status (12)

Country Link
US (7) US7821930B2 (en)
EP (1) EP1932289A4 (en)
JP (1) JP4794629B2 (en)
KR (1) KR20080055805A (en)
CN (1) CN101263686B (en)
AU (1) AU2006291046B2 (en)
BR (1) BRPI0615816A2 (en)
CA (1) CA2618227A1 (en)
MX (1) MX2008003407A (en)
NO (1) NO20080708L (en)
RU (1) RU2420897C2 (en)
WO (1) WO2007033179A2 (en)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180309663A1 (en) * 2017-04-20 2018-10-25 Fujitsu Limited Information processing apparatus, information processing system, and information processing method
US10715350B2 (en) 2016-09-19 2020-07-14 Simmonds Precision Products, Inc. Automatic addressing of networked nodes

Families Citing this family (46)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7821930B2 (en) 2005-09-12 2010-10-26 Microsoft Corporation Fault-tolerant communications in routed networks
US8467390B2 (en) * 2006-12-14 2013-06-18 Oracle America, Inc. Method and system for network stack tuning
US20090073990A1 (en) * 2007-09-14 2009-03-19 Hewlett-Packard Development Company, L.P. Method of replacing a router in a layer 3 network
US20110040911A1 (en) * 2009-08-13 2011-02-17 Anil Vasudevan Dual interface coherent and non-coherent network interface controller architecture
US9220151B2 (en) 2010-06-02 2015-12-22 Koninklijke Philips N.V. Method for controlling a lighting system, and lighting system
EP2426858B1 (en) * 2010-09-01 2012-10-31 Alcatel Lucent Method and apparatus for restoring a connection through a provider network upon request
US20130028257A1 (en) * 2011-07-27 2013-01-31 Raytheon Company Message Gateway and Methods for Using the Same
RU2460123C1 (en) * 2011-08-09 2012-08-27 Федеральное государственное военное образовательное учреждение высшего профессионального образования "Военная академия связи имени маршала Советского Союза С.М. Буденного" Министерства Обороны Российской Федерации (Минобороны России) Method for comparative evaluation of communication network structures
CN102291311B (en) * 2011-08-30 2017-03-29 中兴通讯股份有限公司 Ethernet interface guard method and network equipment
JP6035726B2 (en) * 2011-11-02 2016-11-30 富士通株式会社 Connection control apparatus, storage system, and connection control apparatus control method
WO2013086456A1 (en) * 2011-12-08 2013-06-13 Arteris SAS Differential formatting between normal and retry data transmission
CN102447632A (en) * 2011-12-30 2012-05-09 四川川大智胜软件股份有限公司 Network transmission method having data error tolerance capability
WO2014144182A2 (en) * 2013-03-15 2014-09-18 Terascala, Inc. A data transfer method and apparatus
WO2014142973A1 (en) * 2013-03-15 2014-09-18 Hewlett-Packard Development Company, L.P. Network device architecture adjustments
WO2014182475A1 (en) * 2013-05-07 2014-11-13 Bally Gaming, Inc. System, apparatus and method for dynamically adjusting a video presentation based upon age
US9948545B2 (en) * 2013-06-13 2018-04-17 Tsx Inc. Apparatus and method for failover of device interconnect using remote memory access with segmented queue
WO2015085480A1 (en) * 2013-12-10 2015-06-18 华为技术有限公司 Method and device for processing failure in operator shared network
CN104980348A (en) * 2014-04-04 2015-10-14 中兴通讯股份有限公司 Business chain routing method, business chain routing system and device in system
US9838858B2 (en) 2014-07-08 2017-12-05 Rapidsos, Inc. System and method for call management
WO2016044540A1 (en) 2014-09-19 2016-03-24 Rapidsos, Inc. Method and system for emergency call management
CN108476260A (en) 2015-11-02 2018-08-31 快速求救公司 The method and system of Situation Awareness for emergency response
WO2017106775A1 (en) 2015-12-17 2017-06-22 Rapidsos, Inc. Devices and methods for efficient emergency calling
US9998507B2 (en) * 2015-12-22 2018-06-12 Rapidsos, Inc. Systems and methods for robust and persistent emergency communications
US9986404B2 (en) 2016-02-26 2018-05-29 Rapidsos, Inc. Systems and methods for emergency communications amongst groups of devices based on shared data
CA3021803A1 (en) 2016-04-26 2017-11-02 Rapidsos, Inc. Systems and methods for emergency communications
AU2017262647A1 (en) 2016-05-09 2018-12-20 Rapidsos, Inc. Systems and methods for emergency communications
US10841206B2 (en) * 2016-05-31 2020-11-17 128 Technology, Inc. Flow modification including shared context
US10861320B2 (en) 2016-08-22 2020-12-08 Rapidsos, Inc. Predictive analytics for emergency detection and response management
US10425511B2 (en) * 2017-01-30 2019-09-24 128 Technology, Inc. Method and apparatus for managing routing disruptions in a computer network
US10362631B2 (en) * 2017-04-03 2019-07-23 Level 3 Communications, Llc Last resource disaster routing in a telecommunications network
WO2018200418A1 (en) 2017-04-24 2018-11-01 Rapidsos, Inc. Modular emergency communication flow management system
EP3721402A4 (en) 2017-12-05 2021-08-04 Rapidsos Inc. Social media content for emergency management
US10924331B2 (en) * 2018-01-05 2021-02-16 WeRide Corp. Controller area network communication system
US10820181B2 (en) 2018-02-09 2020-10-27 Rapidsos, Inc. Emergency location analysis system
US20190320310A1 (en) 2018-04-16 2019-10-17 Rapidsos, Inc. Emergency data management and access system
US10805786B2 (en) 2018-06-11 2020-10-13 Rapidsos, Inc. Systems and user interfaces for emergency data integration
US11917514B2 (en) 2018-08-14 2024-02-27 Rapidsos, Inc. Systems and methods for intelligently managing multimedia for emergency response
US10977927B2 (en) 2018-10-24 2021-04-13 Rapidsos, Inc. Emergency communication flow management and notification system
WO2020172612A1 (en) 2019-02-22 2020-08-27 Rapidsos, Inc. Systems & methods for automated emergency response
EP3949467A4 (en) 2019-03-29 2023-01-25 Rapidsos Inc. Systems and methods for emergency data integration
US11146680B2 (en) 2019-03-29 2021-10-12 Rapidsos, Inc. Systems and methods for emergency data integration
US11228891B2 (en) 2019-07-03 2022-01-18 Rapidsos, Inc. Systems and methods for emergency medical communications
JP7339037B2 (en) * 2019-07-10 2023-09-05 ファナック株式会社 Control device, diagnostic method and diagnostic program
CN110336744B (en) * 2019-08-09 2021-05-04 合肥工业大学 Fault-tolerant routing method for sensing regional fault in wireless network on chip
RU2720553C1 (en) * 2019-10-18 2020-05-12 Федеральное государственное бюджетное учреждение науки Институт проблем управления им. В.А. Трапезникова Российской академии наук Method of organizing a system network in the form of a fail-safe non-blocking three-dimensional sparse p-ary hypercube
US11330664B1 (en) 2020-12-31 2022-05-10 Rapidsos, Inc. Apparatus and method for obtaining emergency data and providing a map view

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020032780A1 (en) * 2000-04-24 2002-03-14 Microsoft Corporation Systems and methods for uniquely and persistently identifying networks
US20030010128A1 (en) * 2001-04-23 2003-01-16 Buell Walter F. Method and system for processing laser vibrometry data employing bayesian statistical processing techniques
US20060023676A1 (en) * 1995-06-01 2006-02-02 Padcom, Inc. Port routing
US20060203804A1 (en) * 2000-08-31 2006-09-14 Padcom, Inc. Method and apparatus for routing data over multiple wireless networks
US7581048B1 (en) * 2001-06-29 2009-08-25 Emc Corporation Method and apparatus for providing continuous communication between computers

Family Cites Families (42)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5774640A (en) * 1991-10-21 1998-06-30 Tandem Computers Incorporated Method and apparatus for providing a fault tolerant network interface controller
US6314525B1 (en) * 1997-05-13 2001-11-06 3Com Corporation Means for allowing two or more network interface controller cards to appear as one card to an operating system
US6647508B2 (en) 1997-11-04 2003-11-11 Hewlett-Packard Development Company, L.P. Multiprocessor computer architecture with multiple operating system instances and software controlled resource allocation
JP2002501251A (en) * 1998-01-22 2002-01-15 イナリ、インコーポレイテッド Method and apparatus for a universal data exchange gateway
JP3787029B2 (en) * 1998-03-03 2006-06-21 富士通株式会社 COMMUNICATION DEVICE, COMMUNICATION MEASURE SELECTION METHOD, AND COMPUTER-READABLE MEDIUM
FI105978B (en) 1998-05-12 2000-10-31 Nokia Mobile Phones Ltd Method of connecting a wireless data terminal in a data transmission network and a wireless data terminal
US6988274B2 (en) 1998-06-12 2006-01-17 Microsoft Corporation Method, system, and computer program product for representing and connecting an underlying connection-oriented device in a known format
US6130890A (en) * 1998-09-11 2000-10-10 Digital Island, Inc. Method and system for optimizing routing of data packets
US6272113B1 (en) * 1998-09-11 2001-08-07 Compaq Computer Corporation Network controller system that uses multicast heartbeat packets
US6308282B1 (en) * 1998-11-10 2001-10-23 Honeywell International Inc. Apparatus and methods for providing fault tolerance of networks and network interface cards
US6567377B1 (en) * 1999-03-18 2003-05-20 3Com Corporation High performance load balancing of outbound internet protocol traffic over multiple network interface cards
US6392990B1 (en) * 1999-07-23 2002-05-21 Glenayre Electronics, Inc. Method for implementing interface redundancy in a computer network
US6874147B1 (en) * 1999-11-18 2005-03-29 Intel Corporation Apparatus and method for networking driver protocol enhancement
CA2401635A1 (en) * 2000-02-25 2001-08-30 Honeywell International Inc. Multiple network fault tolerance via redundant network control
US6728780B1 (en) * 2000-06-02 2004-04-27 Sun Microsystems, Inc. High availability networking with warm standby interface failover
US6609213B1 (en) * 2000-08-10 2003-08-19 Dell Products, L.P. Cluster-based system and method of recovery from server failures
US7386610B1 (en) * 2000-09-18 2008-06-10 Hewlett-Packard Development Company, L.P. Internet protocol data mirroring
US6665812B1 (en) * 2000-12-22 2003-12-16 Emc Corporation Storage array network backup configuration
US20040213220A1 (en) * 2000-12-28 2004-10-28 Davis Arlin R. Method and device for LAN emulation over infiniband fabrics
US6868083B2 (en) * 2001-02-16 2005-03-15 Hewlett-Packard Development Company, L.P. Method and system for packet communication employing path diversity
JP2003008581A (en) * 2001-06-26 2003-01-10 Yokogawa Electric Corp Communication controller
US7020796B1 (en) * 2001-07-27 2006-03-28 Ciena Corporation High availability communication system
JP2003234749A (en) * 2001-12-03 2003-08-22 Oki Electric Ind Co Ltd Communication route switching method between lan, route switching program, gateway and terminal
US20040078625A1 (en) * 2002-01-24 2004-04-22 Avici Systems, Inc. System and method for fault tolerant data communication
US7492787B2 (en) * 2002-03-29 2009-02-17 Fujitsu Limited Method, apparatus, and medium for migration across link technologies
JP2003348134A (en) * 2002-05-28 2003-12-05 Nec Soft Ltd Communication path selecting system
JP2004031287A (en) * 2002-06-28 2004-01-29 Pioneer Electronic Corp Plasma display panel
US7254109B2 (en) * 2002-07-12 2007-08-07 Baypackets, Inc. Fault tolerant correlation engine method and system for telecommunications networks
US20040062195A1 (en) * 2002-09-30 2004-04-01 Intel Corporation Algorithm for dynamic provisioning of fail-over support in generalized multi-protocol label switching enabled networks
US7191235B1 (en) * 2002-11-26 2007-03-13 Cisco Technology, Inc. System and method for communicating data in a loadbalancing environment
CN1813454B (en) * 2003-04-28 2012-09-05 钱特利网络公司 System and method for mobile unit session management across a wireless communication network
US7861002B2 (en) * 2003-05-22 2010-12-28 Adtran, Inc. Network router that efficiently switches between a primary data path and a backup data path
JP2005057472A (en) * 2003-08-04 2005-03-03 Nippon Telegr & Teleph Corp <Ntt> Communication method and system
JP2005327186A (en) * 2004-05-17 2005-11-24 Nec Corp Multiple path information management method and device for computer system
US7990849B2 (en) * 2004-06-17 2011-08-02 Hewlett-Packard Development Company, L.P. Automated recovery from a split segment condition in a layer2 network for teamed network resources of a computer system
US9491084B2 (en) * 2004-06-17 2016-11-08 Hewlett Packard Enterprise Development Lp Monitoring path connectivity between teamed network resources of a computer system and a core network
US7808906B2 (en) * 2004-07-23 2010-10-05 Citrix Systems, Inc. Systems and methods for communicating a lossy protocol via a lossless protocol using false acknowledgements
JP4148931B2 (en) * 2004-08-16 2008-09-10 富士通株式会社 Network system, monitoring server, and monitoring server program
US7668962B2 (en) * 2005-02-07 2010-02-23 Symantec Operating Corporation System and method for connection failover using redirection
US7872965B2 (en) * 2005-08-01 2011-01-18 Hewlett-Packard Development Company, L.P. Network resource teaming providing resource redundancy and transmit/receive load-balancing through a plurality of redundant port trunks
US8036105B2 (en) * 2005-08-08 2011-10-11 International Business Machines Corporation Monitoring a problem condition in a communications system
US7821930B2 (en) 2005-09-12 2010-10-26 Microsoft Corporation Fault-tolerant communications in routed networks

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060023676A1 (en) * 1995-06-01 2006-02-02 Padcom, Inc. Port routing
US20020032780A1 (en) * 2000-04-24 2002-03-14 Microsoft Corporation Systems and methods for uniquely and persistently identifying networks
US20060203804A1 (en) * 2000-08-31 2006-09-14 Padcom, Inc. Method and apparatus for routing data over multiple wireless networks
US20030010128A1 (en) * 2001-04-23 2003-01-16 Buell Walter F. Method and system for processing laser vibrometry data employing bayesian statistical processing techniques
US7581048B1 (en) * 2001-06-29 2009-08-25 Emc Corporation Method and apparatus for providing continuous communication between computers

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10715350B2 (en) 2016-09-19 2020-07-14 Simmonds Precision Products, Inc. Automatic addressing of networked nodes
US20180309663A1 (en) * 2017-04-20 2018-10-25 Fujitsu Limited Information processing apparatus, information processing system, and information processing method

Also Published As

Publication number Publication date
US20070058528A1 (en) 2007-03-15
WO2007033179A3 (en) 2007-05-18
US9253293B2 (en) 2016-02-02
RU2008109226A (en) 2009-10-10
JP2009508443A (en) 2009-02-26
US8369208B2 (en) 2013-02-05
US8169894B2 (en) 2012-05-01
WO2007033179A2 (en) 2007-03-22
JP4794629B2 (en) 2011-10-19
US8958325B2 (en) 2015-02-17
US20120272092A1 (en) 2012-10-25
US20120272093A1 (en) 2012-10-25
US7821930B2 (en) 2010-10-26
KR20080055805A (en) 2008-06-19
CA2618227A1 (en) 2007-03-22
CN101263686B (en) 2014-11-12
US20150113165A1 (en) 2015-04-23
AU2006291046A1 (en) 2007-03-22
AU2006291046B2 (en) 2010-03-04
MX2008003407A (en) 2008-03-27
BRPI0615816A2 (en) 2011-05-24
CN101263686A (en) 2008-09-10
EP1932289A4 (en) 2013-04-10
NO20080708L (en) 2008-04-14
US20110004782A1 (en) 2011-01-06
US20110004783A1 (en) 2011-01-06
RU2420897C2 (en) 2011-06-10
EP1932289A2 (en) 2008-06-18

Similar Documents

Publication Publication Date Title
US9253293B2 (en) Fault-tolerant communications in routed networks
US5923854A (en) Virtual internet protocol (IP) addressing
TWI383616B (en) Method and system for assigning a plurality of macs to a plurality of processors
JP5660211B2 (en) Communication path control system and communication path control method
US7693045B2 (en) Verifying network connectivity
US8493839B2 (en) Method and system of teamed network adapters with offloaded connections
US20140334290A1 (en) Implementing redundancy on infiniband (ib) networks
US7864666B2 (en) Communication control apparatus, method and program thereof
JP2006129446A (en) Fault tolerant network architecture
CN101129032A (en) Hardware abstraction layer
US20130051232A1 (en) Managing data on infiniband (ib) networks
JP5765623B2 (en) Network system
CN106059946B (en) Message forwarding method and device
Cisco Router Products Release Notes for Software Release 9.14
Cisco Router Products Release Notes for Software Release 9.14
Cisco Router Products Release Notes for Software Release 9.14
Cisco Router Products Release Notes for Software Release 9.14
Cisco Router Products Release Notes for Software Release 9.14
Cisco Router Products Release Notes for Software Release 9.14
Cisco Router Products Release Notes for Software Release 9.14

Legal Events

Date Code Title Description
AS Assignment

Owner name: MICROSOFT CORPORATION, WASHINGTON

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:MASSA, MICHAEL T.;OPAVSKY, RUDOLF;DION, DAVID A.;SIGNING DATES FROM 20060111 TO 20060120;REEL/FRAME:037716/0394

Owner name: MICROSOFT TECHNOLOGY LICENSING, LLC, WASHINGTON

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:MICROSOFT CORPORATION;REEL/FRAME:037716/0495

Effective date: 20141014

STPP Information on status: patent application and granting procedure in general

Free format text: FINAL REJECTION MAILED

STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION