Multiplex communications – Pathfinding or routing – Switching a message which includes an address header
Reexamination Certificate
1999-06-04
2004-06-29
Marcelo, Melvin (Department: 2663)
Multiplex communications
Pathfinding or routing
Switching a message which includes an address header
C719S328000, C714S015000
Reexamination Certificate
active
06757289
ABSTRACT:
FIELD OF THE INVENTION
The invention generally relates networks and, more particularly, the invention relates to forwarding data across a computer network.
BACKGROUND OF THE INVENTION
The Internet utilizes many data forwarding devices (e.g., routers and switches) to forward data messages between network nodes. Among other things, such forwarding devices include both routing software and a corresponding routing hardware platform that cooperate to forward data messages to their appropriate destinations. Undesirably, routing software within current forwarding devices generally is preconfigured for use within one specific routing hardware platform only. In particular, a forwarding device (e.g., a router) manufactured by a given vendor has routing software that is specifically configured for use with no routing hardware platform other than that of the given vendor. Accordingly, such routing software from one vendor cannot be used on another vendor's forwarding device.
In many such prior art forwarding devices, failure of one executing application can cause the entire system to fail. Accordingly, the operating system in many such devices responsively restarts the entire forwarding device and each of its applications after it detects that one of the applications has failed. In addition to stalling data flow and other undesirable consequences, restarting the entire device can cause data packets to be dropped.
SUMMARY OF THE INVENTION
In accordance with one aspect of the invention, an apparatus and method of managing communication between a first application that has failed and an executing second application permits the first application to establish a path to the second application. To that end, a fail message (notifying the second application that the first application has failed) is forwarded toward the second application, and the first application is restarted. As noted above, the first application establishes a path to the second application after it is restarted. Once the path is established, the second application is notified that the first application is ready to communicate via the path.
In preferred embodiments, the first application notifies the second application that it is ready to communicate by forwarding a ready message to the second application. Moreover, in response to receipt of notification that the first application has failed, the second application may enter a non-communication state. When in this state, the second application does not forward messages toward the first application until notified that the first application is ready to communicate via the path. In other embodiments, the first application receives a ready message from the second application. The ready message notifies the first application that the second application is ready to communicate via the path. Accordingly, the first and second applications do not communicate via the path until after receipt of both the notification by the second application, and receipt of the notification message by the first application.
In preferred embodiments, the path includes a plurality of channels. Each channel may include an associated handler function, where each handler function processes messages in its assigned channel in a uniform manner. In preferred embodiments, the first application is monitored by a monitoring function that generates the fail message after it detects that the first application has failed. The monitoring function may be a part of an application program interface that provides a common interface for the first application and the second application. In preferred embodiments, the monitoring function restarts the application.
The path may be established by controlling the first application to access a configuration file identifying the path configuration data, and establishing the path based upon the accessed path configuration data. The first and second applications may be executing within a single computer system (e.g., a routing device). The second application preferably continues executing at least from the time that the first application failed, to the time that the path is re-established.
Preferred embodiments of the invention are implemented as a computer program product having a computer usable medium with computer readable program code thereon. The computer readable code may be read and utilized by the computer system in accordance with conventional processes.
REFERENCES:
patent: 5261089 (1993-11-01), Coleman et al.
patent: 5327558 (1994-07-01), Burke et al.
Notes on Writing Portable Programs in C; Dolence et al., Nov. 1990, 8thRevision, Mar. 3, 1995.
Berger Michael
Cain Bradley
DiBurro Larry
Lee Robert
Miller William
Marcelo Melvin
Nortel Networks Limited
Steubing McGuinness & Manaras LLP
LandOfFree
Apparatus and method for managing communication between a... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Apparatus and method for managing communication between a..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Apparatus and method for managing communication between a... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3357726