WO2003062991A2 - Method and computer system for protecting software components of an application against faults - Google Patents

Method and computer system for protecting software components of an application against faults Download PDF

Info

Publication number
WO2003062991A2
WO2003062991A2 PCT/US2003/001526 US0301526W WO03062991A2 WO 2003062991 A2 WO2003062991 A2 WO 2003062991A2 US 0301526 W US0301526 W US 0301526W WO 03062991 A2 WO03062991 A2 WO 03062991A2
Authority
WO
WIPO (PCT)
Prior art keywords
software component
software
system
fault
execution
Prior art date
Application number
PCT/US2003/001526
Other languages
French (fr)
Other versions
WO2003062991A3 (en
Inventor
Jeremy S. De Bonet
Original Assignee
Idetic, Inc.
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
Priority to US60/349,632 priority Critical
Priority to US34942402P priority
Priority to US34963202P priority
Priority to US34934402P priority
Priority to US60/349,424 priority
Priority to US60/349,344 priority
Priority to US10/342,113 priority patent/US7073178B2/en
Priority to US10/342,113 priority
Application filed by Idetic, Inc. filed Critical Idetic, Inc.
Publication of WO2003062991A2 publication Critical patent/WO2003062991A2/en
Publication of WO2003062991A3 publication Critical patent/WO2003062991A3/en

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14Error detection or correction of the data by redundancy in operation
    • G06F11/1402Saving, restoring, recovering or retrying
    • G06F11/1415Saving, restoring, recovering or retrying at system level
    • G06F11/1438Restarting or rejuvenating
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0793Remedial or corrective actions

Abstract

A system and method for protecting software components of a software system can be used to guard against faults which might occur during the execution of a software component. A software component which is particularly prone to faults may be designated for protection. Faults occurring during execution of these protected software components can be detected, execution of the protected software component can be halted, and the software system may be restored to the state it held before execution of the protected software component commenced. The software system can then resume executing in a normal manner. Furthermore, a default value for the protected software component may be assigned in the event that a fault is detected during execution of the protected software component.

Description

Method and Computer System for Isolating and Interrelating Components of an

Application

RELATED APPLICATIONS

This application claims priority under 35 U.S.C. § 119(e) to United States Provisional Patent Application No. 60/349,632, entitled "Method and System for Isolating and Protecting Software Components to Increase Reliability and Prevent Inadvertent Corruption" by de Bonet, filed on January 18, 2002, United States Provisional Patent Application No. 60/349,424, entitled "Network Proxy Platform that Simultaneously Supports Data Transformation, Storage, and Manipulation for Multiple Protocols" by de Bonet et al., filed on January 18, 2002, and United States Provisional Patent Application No. 60/349,344, entitled "A Modular Plug-In Transaction Processing Architecture" by de Bonet et al., filed January 18, 2002, which are hereby fully incorporated by reference herein. Additionally, United States Patent Application Serial No. , (Attorney Docket No. IDET1130-1 ) entitled "Method and System of Performing Transactions Using Shared Resources and Different Applications," by de Bonet et al., filed January 14, 2003, which is incorporated by reference herein.

REFERENCE TO APPENDIX

An Appendix is included in this application by way of attachment, the totality of which is hereby incorporated by reference for all purposes as an integral part of this application. The Appendix is entitled "Network Proxy Platform and Its Use" and includes 17 pages of text and 8 sheets of drawings.

TECHNICAL FIELD OF THE INVENTION

This invention relates in general to reducing the likelihood of inadvertent failures of software systems, and more particularly, to protecting software systems against inadvertent failures, errors, and system crashes by isolating and protecting software components within those software systems.

DESCRIPTION OF THE RELATED ART

Computer programs and software projects can be long and complicated structures, often developed not by a sole programmer, nor even a team of programmers, but many times by programmers from multiple groups, or in some cases from different companies.

Almost inevitably these programmers write defects into their code. This problem becomes exacerbated in relation to the number of programmers working on any particular software system. Typically, the more programmers working on a software system, the higher the frequency with which defects are introduced into the code making up that system. Frequently, these defects within individually developed software components can have a catastrophic impact on the running system as a whole.

Prior attempts at solving the defect problem simply utilized a higher level programming language to develop these software systems. Languages such as Java, Pascal, BASIC, and LISP substantially prevent system failures by excluding functionality, making certain operations which could cause an error or system crash nearly an impossibility to perform.

The approach taken by these high-level languages, however, has significant downsides. One downside is that the flexibility of the programming language itself is reduced. For example, a low-level, highly efficient language like C or C++ allows direct manipulation of pointers and memory structures while a higher-level language, such as Java, allows no such manipulation. A key corollary of this lack of functionality can be a loss of performance in higher- level languages due to these languages' need to check the internal validity of these types of operations.

Conversely, lower-level languages, such as C or C++, which do allow this type of low- level functionality, can be prone to crashing problems. Consequently, there is a need to give low-level, efficient programming languages some of the protective characteristics of higher-level languageswhile simultaneously retaining their speed and performance.

SUMMARY OF THE INVENTION

Embodiments of the present invention can provide a system and method for detecting and remedying an illegal operation or other fault in a software system that reduce or eliminate the disadvantages associated with previously-developed protection systems. In many embodiments, these systems and methods can involve executing a previously designated software component of a software system, detecting whether a fault occurred during execution of the component, and restoring the software system to the state it was in before execution of the software component if a fault is detected.

In one embodiment, faults may be of the type that would cause a system crash or system corruption.

In another embodiment, system functions can be used to catch illegal or other operations which are indicative of faults within the protected software component.

Regarding system or memory corruption, a memory pattern may be created, allowing the detection of faults resulting from "out of bounds" memory accesses.

In still another set of embodiments, a system function can be used to save a state of the software system before execution of a protected software component and return to this state if a fault is detected within the protected software component.

These and other aspects of the invention will be better appreciated and understood when considered in conjunction with the following description and the accompanying drawings. However, though the following description indicates various embodiments of the invention and numerous specific details thereof, it should be understood as given by way of illustration and not of limitation. Many substitutions, modifications, additions and rearrangements may be made within the scope of the invention, and the invention includes all such substitutions, modifications, additions and rearrangements.

BRIEF DESCRIPTION OF THE DRAWINGS

The drawings accompanying and forming part of this specification are included to depict certain aspects of the invention. A clearer understanding of the invention, and of the components and operation of systems provided with the invention, will become more readily apparent by referring to the exemplary, and therefore nonlimiting, embodiments illustrated in the drawings, wherein identical reference numerals designate the same components. The invention may be better understood by reference to one or more of these drawings in combination with the description presented herein. Note that the features illustrated in the drawings are not necessarily drawn to scale.

FIG. 1 includes an illustration of a computer system for use with the systems and methods described herein.

FIG. 2 includes an illustration of a computer system storage medium including software code having instructions in accordance with an embodiment described herein.

FIG. 3 includes a graphical depiction of one embodiment of the system of the present invention.

FIG. 4 includes a flow diagram illustrating one embodiment of the present invention.

FIG. 5 includes a depiction of an embodiment of the present invention which uses a memory to detect faults within a protected software component.

DESCRIPTION OF PREFERRED EMBODIMENTS

The invention and the various features and advantageous details thereof are explained more fully with reference to the nonlimiting embodiments that are illustrated in the accompanying drawings and detailed in the following description. Descriptions of well known starting materials, processing techniques, components and equipment are omitted so as not to unnecessarily obscure the invention in detail. The detailed description and the specific examples, while indicating preferred embodiments of the invention, are given by way of illustration only and not by way of limitation. After reading the specification, various substitutions, modifications, additions and rearrangements will become apparent to those skilled in the art from this disclosure which do not depart from the scope of the appended claims.

Embodiments of the present invention provide a system and method for protecting software systems from failure. Typically, a component of a software system which has a potential to be faulty, or if a fault could cause a catastrophic failure to the program, is singled out for protection. If a fault occurs during the execution of this particular component, the fault can be identified, corrective measures can be taken, and the software system can resume execution as if the component did not exist. Certain embodiments of the invention protect against a signal issued by the Central Processing Unit ("CPU") which would otherwise cause the software system to fail. Other embodiments protect against memory operations which may not have caused the system to crash, but would have nonetheless corrupted the memory system of the computer. Still other embodiments protect against faults which cause a portion of the software system to execute for longer than a pre-determined period. Moreover, once these types of errors are detected, corrective measures can be taken, and execution of the software system 5 can resume as though no error occurred in the protected code.

Additionally, the actions to be taken if a fault is detected during the execution of the protected code block can be defined. For example, in the event of a fault, the protection mechanism may emulate a return value for the faulty software component. This allows the remainder of the software system to act as if no fault occurred and the faulty o component returned a valid value.

As used herein, the terms "comprises," "comprising," "includes," "including," "has," "having" or any other variation thereof, are intended to cover a non-exclusive inclusion. For example, a method, process, article, or apparatus that comprises a list of elements is not necessarily limited to only those elements but may include other elements not 5 expressly listed or inherent to such method, process, article, or apparatus. Further, unless expressly stated to the contrary, "or" refers to an inclusive or and not to an exclusive or. For example, a condition A or B is satisfied by any one of the following: A is true (or present) and B is false (or not present), A is false (or not present) and B is true (or present), and both A and B are true (or present).

0 The term "software component" is intended to mean at least a portion of a computer program (i.e., a software application), or software system. An example includes a software module as used in object-oriented programming. Different software components may reside in the same computer program or in different software systems on the same computer or different computers.

5 Before discussing embodiments of the present invention, an exemplary hardware architecture for using embodiments of the present invention is described. FIG. 1 illustrates such an exemplary hardware architecture and includes computer system 100 comprising CPU 122. CPU 122 may comprise read-only memory ("ROM"), random access memory ("RAM"), or other types of volatile or non-volatile memory. CPU 122 is 0 bi-directionally coupled to monitor 142, keyboard 144, hard disk ("HD") 162, and printer

164. An electronic pointing device, such as mouse 146, may be coupled to CPU 122 directly (not shown) or via keyboard 144. Other electronic pointing devices can include a trackball, stylus, or the like and may replace or be used in conjunction with mouse 146. Note that FIG. 1 is a simplification of an exemplary hardware configuration. Computer system 100 may have more than one of the hardware components shown in FIG. 1. In addition, other peripheral devices (not shown) may be coupled to CPU 120 or other portion(s) of the computer system 100. Many other alternative hardware configurations are possible and known to skilled artisans.

CPU 122 is an example of a data processing system. HD 162, ROM, RAM, and other memories can include media that can be read by the CPU 122. Therefore, each of these types of memories includes a data processing system readable medium.

Portions of the methods described herein may be implemented in suitable software code that may reside within HD 162, ROM, RAM, or other memory. The instructions in an embodiment of the present invention may be contained on HD 162 or other memory.

FIG. 2 illustrates a combination of software code elements 204, 206, and 208 that are embodied within a data processing system readable medium 202 on HD 162.

Alternatively, the instructions may be stored as software code elements on a DASD array, magnetic tape, floppy diskette, optical storage device, or other appropriate data processing system readable medium or storage device.

In an illustrative embodiment of the invention, the computer-executable instructions may be lines of assembly code, compiled C, C++, Java, or other language code. Other architectures may be used. A computer program or its software components with such code may be embodied in more than one data processing system readable medium in more than one computer.

Communications using computer system 100 in FIG. 1 can be accomplished using electronic, optical, radio-frequency, or other signals. For example, when a user is at computer system 100, CPU 122 may convert the signals to a human understandable form when sending a communication to the user and may convert input from the user to appropriate electronic, optical, radio-frequency, or other signals to be used by, other computer systems (not shown).

Turning now to FIG. 3, a graphical representation of one embodiment of the present invention is depicted. A computer program or software system 300 may comprise many lines of source code, usually grouped into functional blocks shown as software components 310, 320, and 370. This code is usually written in one of the commonly known and utilized programming languages such as C, C++, Fortran, etc., or in less common cases, even lower-level languages such as machine or assembly code. Because of their size and complexity a software system 300 often cannot be developed by one person, and a team or group of teams may be delegated to work on a software system 300. Frequently, any or all software components 310, 320, and 370 within the software system 300 can be developed by different groups.

5 The development process of software system 300, combined with the power of many programming languages, leads to the incorporation of programming defects into any or all of the various software components 310, 320, and 370 which make up the software system 300. These defects may cause the software system 300 to crash during execution. For example, a software component 310, 320, or 370 may cause a 0 segmentation violation, attempt to divide a number by zero, put the software system into an infinite loop, or the like. Additionally, in certain cases these defects may not cause the software system 300 to crash, but instead, may cause the software system 300 to function improperly. For example, data residing in memory may be inadvertently overwritten by a software component 310, 320, or 370, or a software component 310, 5 320, or 370 may execute in an infinite loop, tantamount to halting execution of software system 300.

In order to remedy the detrimental effects of defects on the software system 300, an embodiment of the present invention allows a software component 320 which may need to be tested for faults to be designated as protected within block 350. During execution of o the software system 300, a software component 320 may be called any number of times by other software components 310 or 370 contained in the software system 300. Protective code layer 360 may designate a software component 320 as protected and save a state of a software system 300 before execution of a software component 320, and furthermore may associate a remedial software component 330 to be executed if a 5 fault is detected within a software component 320. The software component 320 is then executed.

If no faults occur during execution of the protected software component 320, the software system 300 may skip execution of any remedial code 330 associated with the protected software component 320 by protective code layer 360, and the software system 300 may o continue running normally starting with software component 370.

However, if a fault occurs during execution of a protected software component 320 which would normally crash the computer system on which software system 300 is executing, or which would impair the proper functioning of the software system 300, the protective code layer 360 can detect this error.

Upon detection of a fault in the protected software component 320, the protective code layer 360 may immediately terminate the execution of the protected software component 320. In one embodiment of the present invention, after execution of the protected software component 320 is halted, a designated software component 330 is executed which may take remedial action based on the fault detected.

In most cases, after execution of the protected software component 320 is halted by the protective code layer 360, the software system 300 may be returned to the state it held before execution of the protected software component 320. Restoring the state of the software system 300 is accomplished by the protective code layer 360. Before execution of the protected software component 320, the protective code layer 360 saves a copy of the state of the software system 300. If a fault is detected by the protective code layer 360 during execution of the protected software component 320, the protective code layer 360 restores the software system 300 to this pre-execution saved state. After the software system 300 is restored to the pre-execution state, normal execution of the software system 300 may continue 370.

FIG. 4 depicts a flow diagram of one method in accordance with an embodiment of the present invention, including: saving the state of a software system 405; executing a software component which was previously designated for protection 410; determining if a fault occurred during execution of the software component 430; restoring the system to the previously saved state if a fault was detected 440; and continuing execution of the software system 450.

Large software systems are usually composed of many discrete software components which may perform a variety of functions within the software system. Some of these software components may be more prone to errors than others. For example, in a software system comprising code in assembly code or the C or C++ programming languages software components which allocate memory, or utilize and manipulate pointers to memory, are more prone to causing faults which may corrupt data needed by the software system. In certain cases a software component in any of those languages may cause a fault that could result in the crash of the software system or the machine on which the software system is executing. Embodiments of the present invention involve designating these dangerous software components for protection.

One method of the present invention may include the optional act of designating a software component 320 for protection Designating a software component 320 within a software system 300 for protection may involve surrounding the software component 320 to be protected with extra code intended to be run before the protected software component 320 is executed. This protective code may save the state of the software system 300 and, in the event a fault is detected, associate code 330, which may also be a software component, to take remedial action to account for the fault detected within the protected software component 320. This protective code layer 360 may be embodied in a programming library, and a macro utilizing this programming library may be inserted into the software system 300 to designate which software component 320 is to be protected through the use of this library.

Before execution of the protected software component 320 the state of the software system is saved 405 to insure that if an error is detected during execution of protected software component 320, the software system can revert back to a former state. The entire state of an executing software system may be contained in certain elements of a computer system. Most often, this state is embodied in the local memory stack, the function pointer stack, and the program counter. By saving these elements, the state of a software system at any point in its execution may be retained.

Prior to execution of the protected software component 320, a copy of the current state of the software system is made 405. in other words, copies of the local memory stack, the function pointer stack, and the program counter are created. Typically, these copies are made using the standard C++ system function call "setjmp."

During execution of the software system, this protected software component 320 has the potential to be called many times by other software components 310 or 370 contained in the software system 320.

The method of the present invention can also comprise executing the protected software component 410. After executing a software component designated for protection 410 has commenced, the method can further comprise determining if a fault is detected. For the most part, faults detected 430 during the execution of a protected software component can be divided into three main categories. Faults which would cause the software system, or the machine on which the software system is executing, to crash, software components whose execution time is too long, and those faults which might not cause a crash but which may nonetheless cause corruption of data needed for the software system to function properly may be detected. Many embodiments of the present invention protect software systems against these types of faults.

In order to detect faults 430 during execution of a protected software component 320, signals generated by the CPU of the machine on which the software system 300 is executing are monitored. A software component is basically a series of instructions to be 5 executed on a CPU. During execution of these instructions presented to the CPU by a software component, the CPU generates signals in response to certain events. A subset of these signals generated by the CPU indicate that a critical fault has occurred, and a system crash is imminent. For example, on a standard UNIX, SUN Solaris, or Microsoft Windows based system, if a segmentation violation occurs the CPU will issue a 0 SIG_SEGV signal before crashing. Alternatively, if a floating point error occurs the CPU will issue a SIG_SPG signal before crashing, or if an illegal instruction is encountered, the CPU will issue a SIGJLL signal before crashing.

Many embodiments of the present invention may detect faults 430 which occur during the execution of a protected software component 320 by monitoring the signals issued by the 5 CPU in response to the instructions presented by a protected software component 320. Typically, this detection is done with the C or C++ function "signal," which allows signals issued by the CPU indicating a looming system crash to be caught and handled before the impending crash of the software system occurs.

Faults caused by overlong execution time of a protected software component 320 may o also be detected by embodiments of the present invention. These types of faults are typically caused by code within the protected software component 320 which places the software system into an infinite loop, or causes portions of code to execute for an unusually long time. Certain embodiments of the present invention detect a fault of this type by comparing the time taken to execute protected software component 320 with a 5 predetermined time period.

Another type of fault which may be detected are those faults which may not cause a crash of the software system, but which would nevertheless disrupt the functioning of the software system by corrupting data needed by the software system to execute properly. These faults typically occur when memory access occurs. For example, illegal o instructions overwriting memory to which the software component is not assigned. Turning briefly to FIG. 5, the method by which many embodiments of the present invention detect these types of memory faults is depicted. In one embodiment, memory 500 is divided into pages 510, 540, and 550, the size of which is determined on a computer system by computer system basis. A software component 320 has access only 5 to those memory pages 510 that are assigned to that software component 320. Often times, however, a software component 320 utilizes less memory than is contained in a given page size. In this case, a software component 320 may have access to read and write to memory contained in an entire page 510, though only a portion 520 of that page's memory may be actually assigned to that software component 320. If software o component 320 reads or writes portion 530, this can be detected as a fault. By reading or writing to portion 530 a software component 320 may corrupt data needed by other components of the software system 300 by writing to memory not assigned to it, yet contained in a memory page to which software component 320 has access. Conversely, a protected software component 320 may store required data in an area of memory to 5 which it is not assigned. At a later point, this data may be overwritten by another software component assigned to that portion of memory, causing a loss of data needed by the protected software component 320.

To catch faults of this type, many embodiments of the present invention employ the technique depicted in FIG. 5. Each page of memory 510 to which the protected software o component 320 has access can be divided into areas to which the protected software component 320 is assigned 520 and those areas to which it is not assigned 530. The areas of memory page 510 to which the protected software component 320 is not assigned 530 is filled with a particular pattern of bits before execution of the protected software component 320. After the protected software component 320 finishes execution, 5 this pattern in area 530 may be verified. If the protected software component 320 has changed memory in area 530, the change can be detected through a comparison of the patterns existing in memory area 530 before and after execution of the protected software component.

Returning now to FIG. 4, if a fault which would cause a crash, which would corrupt o memory, or which would cause software component to execute longer than a determined time period is detected 430, many embodiments of the present invention respond by restoring the software system 300 to a previous state 440.

As noted above, before execution of the protected software component 320 copies of the local memory stack, the function pointer stack, and the program counter are created. During execution of the protected software component 320, the local memory stack, the function pointer stack, and the program counter are modified freely. When a fault is detected 430, either by use of a CPU signal, or through a comparison of the patterns in memory, the state of the software system 300 usually must be restored to the state extant before execution of the protected software component commenced.

Usually this restoration is accomplished through the use of the standard C++ system function call "Ingjmp". This function disposes of the local memory stack, function pointer stack, and program counter currently in use by the software system, and replaces them with the copies made by the C++ function "setjmp" before execution of the protected software component 405. This serves to return the software system to the state existing before execution of the protected software component began.

Employing these techniques additionally allows various embodiments of the present invention to protect software components in a multi-thread environment, and, for protected software components to call or contain other protected software components, known as nesting in common parlance. A stack of states can be maintained for every thread currently executing in a software system. When a protected software component is called, a copy of the current state is made, usually using "setjmp," and this copy is pushed on the stack of states associated with the thread calling the protected software component. If a fault is detected during execution of the protected software component, the stack being currently utilized is disposed of, the saved state is popped off the top of the stack of saved states for that thread, usually using "Ingjmp," and the state existing before execution of the protected software component is restored. However, if no faults are detected during execution of the protected software component, the copy of the state saved on top of the stack of states is discarded.

Utilizing a stack of states coupled with the disposition of the saved states when a protected software component executes without fault also allows nesting of protected functions to be done with less overhead. If a software system contains a nested protected software component, during execution many states will be pushed on the stack of states. Disposing of each saved state with the successful completion of each protected software component allows the retained state associated with the currently executing software component to always reside at the top of the stack of saved states. One specific embodiment of the present invention can be described as: // this global structure keeps, independently for each thread,

// a stack of continuations global AssociativeArray<ThreadlD, StackOf<Continuations> > continuations;

macro ProtectCode(code_to_protect, code_on_failure)

{

// capture signals generated by the CPU or Kernel // when it detects certain illegal actions HandleSignal(SIG_FPE, CorruptionOccurred);

HandleSignal(SIG_SEG, CorruptionOccurred); HandleSignal(SIG_ILL, CorruptionOccurred);

// build a pattern to check for memory on the stack which // is too close to legal memory for the CPU to catch

// overwrites.

// (i.e. illegal memory within the same page as legal

// memory)

Byte sandbox[SANDBOX_SIZE]; FillSandboxWithPattem(sandbox);

// push this continuation point onto the stack Continuation cont=GetContinuation(); ThreadlD tid=GetThreadlD(); continuations. Get(tid).Push(cont);

II ***^ jnjS js ^ crjtjca| continuation point //

// If we are here for the first time, then

// continuation_called

// will be false. //

// If we get here because a corruption occurred, and // CallContinuationO was used to return to this point // then the flag continuation_called will be // true. Boolean continuation_called = SetContinuationPoint();

if (!continua1ion_called){

Call(code_to_protect);

// check the integrity of the sandbox if(!CheckSandboxPattern(sanbox)){

CorruptionOccurredO; }

// we successfully called the function

// and no corruption occurred

// so we can throw away the continuation continuations.Get(tid).Pop();

} else{

// corruption occurred so we call the

// code_on_failure to perform cleanup actions Call(code__on_failure);

}

}

function CorruptionOccurred()

{

// get the stored continuation ThreadlD tid=GetThreadlD(); Continuation cont; cont=continuations.Get(tid).Pop();

// resume to the continuation point (marked by *** above) CallContinuation(cont); }

Irrespective of whether a fault was detected during execution of a protected software component 320, execution of the software system 300 may continue 450. If no faults are detected this is a relatively straightforward process, and execution continues normally. If a fault is detected 430, however, the state may be restored, as described above, before execution of the software system 300 is resumed. Often times, resuming normal execution is problematic because the remainder of the software system 300 may expect the protected software component 320 to return a value or an exit code. While no return value or exit code whatsoever may be troublesome for the software system, most software systems are capable of dealing with a return value of false, indicating the called software component failed. Consequently, many embodiments of the present invention allow code 330 to be associated with a protected software component 320 such that upon detection of a fault in the protected software component 320, and before normal execution of the software system resumes, this remedial code can be executed to emulate a return value for the terminated protected software component 320. Usually, a return value of false is emulated. The failure of the protected software component can then be dealt with and execution of the software system may then resume normally.

In the foregoing specification, the invention has been described with reference to specific embodiments. However, one of ordinary skill in the art appreciates that various modifications and changes can be made without departing from the scope of the invention as set forth in the claims below. Accordingly, the specification and figures are to be regarded in an illustrative rather than a restrictive sense, and all such modifications are intended to be included within the scope of invention.

Benefits, other advantages, and solutions to problems have been described above with regard to specific embodiments. However, the benefits, advantages, solutions to problems, and any component(s) that may cause any benefit, advantage, or solution to occur or become more pronounced are not to be construed as a critical, required, or essential feature or component of any or all the claims.

APPENDIX NETWORK PROXY PLATFORM AND ITS USE

Reference is made in detail to exemplary embodiments of the network proxy platform and its use, examples of which are illustrated in the accompanying drawings. Wherever possible, the same reference numbers will be used throughout the drawings to refer to the same or like parts (elements).

A method and system can comprise a software architecture that allows different applications in the same or different communications protocols to interact with shared resources within a computer. More specifically, code for a computer program may be written to increase the amount of code that is generic to (i.e., shared by) more than one application or communications protocol and reduce the amount of code that handle application-specific or protocol-specific actions. In one embodiment, a transaction may be broken down into a set of discrete actions. The discrete actions may include functions that are common to more than one network application. These functions may be performed bythe shared resources.

For each action, code that is specific to a particular protocol or application may be written as part of a software plug-in module with function calls to functions of the shared resources. Each software plug-in module may substantially act similar to a manager for the action, where common tasks are delegated to the shared resources and the module performs specialized functions. Each protocol may have its own set of software plug-in modules for the discrete actions. New applications and support for new protocols can be added by developing a new set of plug-in modules instead of writing an entirely new program. New applications for the same protocol may be developed by replacing or editing as little as one plug-in module from a different application in the same protocol.

The software architecture can reduce development time, increase the likelihood that new applications may be developed quickly with fewer changes from an existing application, more protocols will be properly supported, and reduce the burden on hardware and software resources. A few terms are defined or clarified to aid in understanding the descriptions that follow. A network includes an interconnected set of server and client computers over a publicly available medium (e.g., the Internet) or over an internal (company-owned) system. A user at a client computer may gain access to the network using a network access provider. An Internet Service Provider ("ISP") is a common type of network access provider.

As used herein, the terms "comprises," "comprising," "includes," "including," "has," "having" or any other variation thereof, are intended to cover a non-exclusive inclusion. For example, a method, process, article, or apparatus that comprises a list of elements is not necessarily limited to only those elements but may include other elements not expressly listed or inherent to such method, process, article, or apparatus. Further, unless expressly stated to the contrary, "or" refers to an inclusive or and not to an exclusive or. For example, a condition A or B is satisfied by any one of the following: A is true (or present) and B is false (or not present), A is false (or not present) and B is true (or present), and both A and B are true (or present).

The term "software component" is intended to mean at least a portion of a computer program (i.e., a software application). An example includes a software plug-in module or the like. Different software components may reside in the same computer program or in different computer programs on the same computer or different computers.

Before discussing embodiments of the network proxy platform, an exemplary hardware architecture for using network proxy platform is described. FIG. 1 illustrates such an exemplary hardware architecture and includes client computer 120, proxy computer 140, and server computer 160. Client computer 120 and proxy computer 140 are bi-directionally coupled to network 11 , and proxy computer 140 and server computer 160 are bi-directionally coupled to network 13. Each of networks 11 and 13 may be an internal network or an external network (e.g., the Internet). In one embodiment, networks 11 and 13 may be the same network, such as the Internet. Computers 140 and 160 may be bi-directionally coupled to databases 14 and 16, respectively.

Client computer 120 can include a desktop computer, a laptop computer, a personal digital assistant, a cellular phone, or nearly other device capable of communicating over network 11. Other client computers (not shown) may also be bi- directionally coupled to network 11. The proxy computer 140 can be a server computer, but in another embodiment may be a client computer. Other server computers (not shown) similar to server computer 160 may be bi-directionally coupled to network 13.

In an alternative embodiment, each of proxy computer 140 and server computer 160 may be replaced by a plurality of computers (not shown) that may be interconnected to each other over a network or a combination of networks. For simplicity, a single system is shown for each of proxy computer 140 and server computer 160.

The client computer 120 can include central processing unit ("CPU") 122, readonly memory ("ROM") 124, random access memory ("RAM") 126, hard drive ("HD") or storage memory 128, and input/output device(s) ("I/O") 129. I/O 129 can include a keyboard, monitor, printer, electronic pointing device (e.g., mouse, trackball, stylus, etc.), or the like. Proxy computer 140 can include CPU 142, ROM 144, RAM 146, HD 148, and I/O 149, and server computer 160 can include CPU 162, ROM 164, RAM 166, HD 168, and I/O 169.

Each of the computers in FIG. 1 may have more than one CPU, ROM, RAM, HD, I/O, or other hardware components. For simplicity, each computer is illustrated as having one of each of the hardware components, even if more than one is used. Note that FIG. 1 is a simplification of an exemplary hardware configuration. Many other alternative hardware configurations are possible and known to skilled artisans.

Each of computers 120, 140, and 160 is an example of a data processing system.

ROM 124, 144, and 164; RAM 126, 146, and 166; HD 128, 148, and 168; and databases 14 and 16 can include media that can be read by CPU 122, 142, or 162. Therefore, each of these types of memories includes a data processing system readable medium. These memories may be internal or external to computers 120, 140, or 160.

Portions of the methods described herein may be implemented in suitable software code that may reside within ROM 124, 144, or 164, RAM 126, 146, or 166, or HD 128, 148, or 168. The instructions in an embodiment may be contained on a data storage device, such as HD 148. FIG. 2 illustrates a combination of software code elements 204, 206, and 208 that are embodied within a data processing system readable medium 202, on HD 148. Alternatively, the instructions may be stored as software code elements on a DASD array, magnetic tape, floppy diskette, optical storage device, or other appropriate data processing system readable medium or storage device.

In an illustrative embodiment, the computer-executable instructions may be lines of compiled assembly, C, C++, Java, or other language code. Other architectures may be used. For example, the functions of any one of the computers may be performed by a different computer shown in FIG. 1. Additionally, a computer program or its software components with such code may be embodied in more than one data processing system readable medium in more than one computer.

In the hardware configuration above, the various software components may reside on a single computer or on any combination of separate computers. In alternative embodiments, some or all of the software components may reside on the same computer. For example, one or more the software component(s) of the proxy computer 140 could reside on the client computer 120, the server computer 160, or both. In still another embodiment, the proxy computer 140 and database 14 may not be required if the functions performed by the proxy computer 140 are merged into client computer 120 or server computer 160. In such an embodiment, the client computer 120 and server computer 160 may be bi-directionally coupled to the same network (not shown in FIG. 1 ). Communications between any of the computers in FIG. 1 can be accomplished using electronic, optical, radio-frequency, or other signals. For example, when a user is at client computer 120, client computer 120 may convert the signals to a human understandable form when sending a communiøation to the user and may convert input from a human t!o appropriate electronic, optical, radio-frequency, or otfrer signals to be used by, computers 140 or 160. Similarly, when an operatoris at server computer 160, server computer, 160 may convert the signals to a human understandable form when sending a communication to the operator and may convert input from a human to appropriate electronic, optical, radio-frequency, or other signals to be used by computers 120, 140, or 160. Attention is now directed to the methodology of developing a software architecture for the software in accordance with one embodiment. The method can comprise breaking down a transaction into a set of discrete actions. The actual definitions used for separating the transaction into the discrete actions is variable and may be selected by skilled artisans in manners that best suit their particular transactions, hardware requirements, and software requirements. The method can also include determining which functions within the set of discrete actions are common to more than one application. As more are identified, the number of shared resources can increase and the amount of application-specific code can be decreased. Therefore, skilled artisans are encouraged to examine the software from many different levels of abstraction to discover potential shared resources that may otherwise be missed.

The method can further comprise generating software components for the discrete actions. A set of software plug-in modules can correspond to the different discrete actions for the transaction. Each application may have its own set of software plug-in modules. The amount of code within each software plug-in module should be kept relatively low if the identification of shared resources was performed properly. To the extent code for any shared resources does not currently exist, code for the shared resources should be generated to maximize its ability to be used by as many different plug-in modules as possible.

At least two of the software plug-in modules for different applications, whether they use the same or different protocols, can make function calls to any one or more of the shared resources. For different applications using the same protocol, only a request manipulation plug-in module, a content manipulation plug-in module, or both may be the only modules changed. Therefore, creating new application for the same protocol may be simplified because other plug-in modules used for the application may be copied from another application using the same protocol. These other plug-in modules may be substantially the same between the applications. By replacing or editing the request manipulation plug-in module, content manipulation plug-in module, or both, new applications may be developed very quickly.

Regarding applications in different protocols, each protocol may have a module that performs substantially the same action as any or all of the similar module(s) for the other protocol(s) though reducing this duplicative code by combining the common functionality is preferable.

Attention is now directed to the software architecture of the software in accordance with one embodiment. The software architecture is illustrated in FIGs. 3 and 4 and is directed towards an electronic transaction that can be performed over a network. A basic idea behind the architecture is to allow programming code for shared resources to be commonly used by as many different network applications as possible. Note that all of the resources may or may not be shared by all the applications. The programming code for each application-specific plug-in module may include code to connect the incoming communication in any supported application to the shared resources. By limiting the code within the plug-in modules, a user of the software architecture can reduce development time, increase the likelihood that more applications in the same or different protocols will be properly supported (especially proprietary protocols that may be used by only a limited number of computers or users), and reduce the burden on hardware and software resources for different applications because only relatively small plug-in modules may be used.

In FIG. 3, each row of boxes 3200, 3400, and 3600 represents different applications in the same or different protocols. For example, row 3200 may represent a first application using HTTP, row 3400 may represent a different application using HTTP, and row 3600 may represent yet another application in a different protocol, such as POP, SNMP, WAP, and the like. Note that the series of dots between rows 3400 and 3600 indicate that many other applications in the same or different protocols may be present. Additionally, the architecture may be configured to allow the addition of future applications. The software architecture easily supports at least three different and potentially many more protocols. Referring to row 3200, each of the boxes 3202 through 3214 represents different stages (actions) that may occur during an electronic transaction. For example, box 3202 may represent a request reception plug-in module, box 3204 may represent an authorization plug-in module, box 3206 may represent a request manipulation plug-in module, box 3208 may represent a content retrieval plug-in module, box 3210 may represents a content manipulation plug-in module, box 3212 may represent a content delivery plug-in module, and box 3214 may represent a post-response communication plug-in module (e.g., acknowledgement, billing, etc.). Each module may correspond to one or more of the discrete actions. Details about the individual plug-in modules are described later in this specification. Note that the other rows 3400 and 3600 include corresponding boxes for substantially the same types of actions except that they are designed for different applications. More specifically, box 3402 represents an incoming message reception plug-in module for a different application using the same protocol as box 3202, and box 3602 represents an incoming message reception plug-in module for yet another application using a different protocol compared to box 3202.

New applications that make use of already-supported protocols can be developed with a minimum of effort. This is achieved by creating a new row, which makes use of protocol specific plug-ins used in another row and combines them with other plug-ins developed for the specific application at hand. Some plug-in modules may be substantially the same for many different applications in the same protocol. In different protocols, the plug-in modules for at least some of the different applications may provide substantially the same functionality, although the code within those plug-in modules may be different compared to similar modules for the other protocols.

Within the software architecture, shared resources are illustrated as planes 3102, 3104, and 3106 that lie beneath each of the rows 3200, 3400, and 3600. Referring to FIG. 4, interfaces may be made to each of the shared resources for each plug-in module. Specifically referring to box 3214, functional connectivity 4102 links module 3214and shared resource 3102. Likewise, functional connectivity 4104 links module 3214 and shared resource 3104, and functional connectivity 4106 links module 3214 shared resource 3106. Links 4102, 4104, and 4106 can be achieved by function calls to the shared resources. Examples of the shared resources may include a content cache, a parameter cache, a connection pool, a domain name server cache, a clock, a counter, a database, a global variables space (e.g., a logging database), or the like. A list of potential shared resources is nearly limitless. Note that not all shared resources may be connected to all modules along a row. For example, modules 3202 and 3204 may not need access to the content cache because they may not receive or process content returned for a request. Each connection from a client may be handled independentiy on its own thread. However in other embodiments, fewer threads or a single thread can be used to operate all connections to a specific row that supports a particular application or protocol. Unless stated to the contrary, the method below is described from the perspective of proxy computer 140. FIG. 5 includes a flow diagram of a method of performing an electronic transaction that corresponds to the software plug-in modules that lie along any of rows 3200, 3400, and 3600. Note that all modules are not required and that functions of some modules may be combined with others (e.g., authorization may be part of processing an initial request). The process flow diagram will be briefly covered followed by a more detailed description of each module. 5 The method can comprise receiving a request from a client computer using a request reception plug-in module (block 502) and performing authorization using an authorization plug-in module (block 504). The method can also comprise manipulating a request using a request manipulation plug-in module (block 512). The method can further comprise retrieving content using a content retrieval plug-in module (block 522). The o method can yet further comprise manipulating returned content using a content manipulatbn plug-in module (block 532) and sending the modified content to the client computer using a content delivery plug-in module (block 534). The method can still further comprise processing post-response communications using a post-response plug- in module (block 542). 5 Note that not all of the activities described in the process flow diagram are required, that a limitation within a specific activity may not be required, and that further activities may be performed in addition to those illustrated. Also, some of the activities may be performed substantially simultaneously during with other activities. After reading this specification, skilled artisans will be capable of determining what activities can be o used for their specific needs.

Attention is now directed to the protocol-specific plug-in modules along the rows 3200, 3400, and 3600 and how they are related to the activities illustrated in FIG. 5. Although the discussion is directed to row 3200, the corresponding modules along other rows can provide similar functionality. Also, in the example below, client computer 120 is 5 sending a request for content to proxy computer 140, and server computer 160 is providing content in response to the request. The flow of information could be in the opposite direction (server computer 160 seeking information from client computer 120).

The method can comprise receiving a request from client computer 120 using request reception plug-in module 3202 (block 502 in FIG. 5). Request reception plug-in 0 module 3202 can be used when a request from client computer 120 is received or accessed by proxy computer 140. Module 3202 can initially generate an associative array from portions of the header of the request. Part or all of the associative array may be used by the other modules along the same row. The associative array may provide information that can be part of function calls to the shared resources. Any or all the data (including the associative array) may be passed from any prior plug-in module (e.g., module 3202) to any or all the subsequent plug-in modules along the same row (e.g., 3204, 3206, 3208, 3210, 3212, or 3214).

The method can also comprise performing authorization using authorization plug- in module 3204 (block 504). The authorization plug-in module 3204 is optional and can be used for determining whether a user at client computer 120 has proper authorization. The authorization modules may be based on an Internet Protocol ("IP") address or a name and a password. Module 3204 may send the IP address or name and password to a shared resource to determine if the user is allowed access.

The method can further comprise manipulating the request using request manipulatbn plug-in module 3206 (block 512). Request manipulatbn plug-in module 3206 may be used to modify, replace, or otherwise manipulate the request. For example, proxy computer 140 may have code to redirect a URL within a request to a different URL. More specifically, proxy computer 140 may make a function call to that shared resource using the requested URL. The shared resource may pass the different URL back to module 3206. Module 3206 may have the logic to put the different URL in the correct protocol, so that it will be understood by a computer that may receive the redirected request.

The method can yet further comprise retrieving content using content retrieval plug-in module 3208 (block 522). Content retrieval plug-in module 3208 may be used to send the request and receive or access content in response to the original request or manipulated request. More specifically, a request originating from client computer 120 may have been processed by proxy computer 140 before being received by server computer 160. Content from server computer 160, in response to the processed request from proxy computer 140, would be processed using module 3208. Similar to module 3202, the code may parse the content from server computer 160 into a header portion and a content portion and append that information onto a previously generated associative array.

The method can still further comprise manipulating returned content from the server computer using content manipulation plug-in module 3210 (block 532). Content manipulatbn plug-in module 3210 may be used to add or modify content before sending it to client computer 120. More specifically, proxy computer 140 may add advertisements or supplementary information from third parties to the content provided by server computer 160. In an alternative embodiment, part or all of the content originating from server computer 160 may be deleted or replaced with other content.

The method can comprise sending the modified content to the client computer using content delivery plug-in module 3212 (block 534). Content delivery plug-in module 3212 may be used to route the content, after manipulation, if any, to client computer 120. Some of the information in the associative array generated when the original request from client computer 120 was processed may be used by module 3212 when sending the outgoing content to client computer 120.

The method can also comprise processing post-response communications using post-response plug-in module 3214 (block 542). Post-response communication plug-in module 3214 may be used for acknowledgement, billing, or other purposes. For example, after content is successfully sent to client computer 120 from module 3212, module 3124 could then charge the user's credit card for that transaction. Alternatively, module 3214 may look for a signal that service to or from client computer 120 or server computer 160 is being terminated for the current transaction. Such post-response processing may be helpful in avoiding invoices or other bills sent to a user at client computer 120 if a product or service was either incomplete or defective or to properly reflect the connect time for a transaction.

Along similar lines, one of the planes as illustrated in FIG. 3 may include global space variables that may need to be used by other shared resources, proxy computer 140, or the plug-in modules. System statistics are examples of information that may be within a global variable space. This information may be useful to proxy computer 140 or another computer, such as client computer 120 or server computer 160, in monitoring activity. The statistics may include how many computers are connected to proxy computer 140, the amount of time each of those computers are connected to proxy computer 140, the amount of or time lapsed during transactions being processed through proxy computer 140, or the like.

These global variables may be used in conjunction with a module, such as authorization module 3204. If too many users are currently logged into proxy computer 140, authorization may be denied even if the computer attempting a connection to proxy computer 140 has proper security clearance. After another transaction by another client computer is terminated, a signal from module 3214 can be sent to the logging system within the shared resources. A new client computer may now gain access to the services provided by proxy computer 140 after the connection from the other transaction is terminated.

Attention is now directed to more specific activities that may be performed by a specific module, and how that specific module may interact with other modules for the same transaction using a specific application. The process flow diagram illustrated in FIGs. 6-8 is used to describe some of the specific activities. Again, unless stated to the contrary, the method is primarily described from the perspective of proxy computer 140. To aid in understanding the method in FIGs. 6-8, a specific example is used and occasionally referenced. In the example, an incoming communication may be a request from client computer 120 sent to proxy computer 140 for www.yahoo.com. The client computer 120 is communicating using HTTP, using a Netscape™ browser (of AOL Time Warner, Inc. of New York, New York), and has a MacOS X™ operating system (of Apple Computer, Inc. of Cupertino, California).

Referring to FIG. 6, the method can comprise receiving an incoming communication for a specific application (block 602). The communication can comprise a request, a message, or other form of communication. The communication can be sent by client computer 120 and received or accessed by proxy computer 140 via network 11. Proxy computer 140 can access or read at least a portion of the incoming communication and determine the specific application for the communication. In the example, the incoming communication is a request from client computer 120 sent to proxy computer 140 forwww.yahoo.com. The incoming communication will also contain other information within the header of the request. In the example, the other information can include the browser and operating system of client computer 120.

After determining the application for the communication, proxy computer 140 can determine which row 3200, 3400, 3600, or other or row of plug-in modules will be used for the transaction. At this point in the method, proxy computer 140 may activate any or all of the plug-in modules for the row corresponding to the specific application. In one embodiment, plug-in modules within each row may be activated only as they are first used. Referring to the example, the request is for an application corresponding to row 3200. Therefore, plug-in module 3202 may be activated. If the communication is for another application, plug-in module 3402 or 3602 may be activated for the particular application. The method can further comprise routing the incoming communication to a first software plug-in module for the specific application (block 604). Proxy computer 140 can route the request to request reception software plug-in module 3202 because the incoming request uses the application corresponding to row 3200.

The method can comprise parsing the incoming communication into a header portion and a content portion (block 622). The parsing can be performed by module 3202 to obtain information from the request.

The method can also comprise generating an associative array using information contained within the header portion (block 624). The associative array can include nearly any finite number of rows. Each row can comprise a key and a value. The key can comprise a parameter within the header portion, and the value can comprise a value for that parameter. In general, the header portion may include one or more lines of a command followed by a command argument. The command may be a key, and the command argument may be the corresponding value for the key. The associative array may be searched by the key or the value.

By knowing conventions used by each of the protocols for incoming communications and the characteristics of headers used for those protocols, formation of the associative array can be performed without complicated coding requirements. The associative array is flexible regarding tie number of rows and allows different sizes of associative arrays to be used for different protocols.

For HTTP, one of the lines within the header may include a line with "User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.1) Gecko." The key will be "User- Agent," and the value will be " Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.1 ) Gecko." For POP, a line may include "RETR 27," where 27 is an object identifier for is a particular item to be retrieved. The key will be "COMMAND," and the value will be "RETR." A second entry will be made with a key of "ARGUMENT" and a value of "27." For SNMP, a line may include "get 47.12.112.38," where 47.12.112.38 corresponds to an object identifier. The key will be "COMMAND", and the value will be "GET," and a second entry will have the key "ARGUMENT" and the value "47.12.112.38."

The content may or may not be part of the associative array. If it is, the associative array can include a key of "CONTENT" and the entire content data block as the value. For an image, the content may be a very large amount of data. Alternatively, the associative array may be paired with a data pointer that points to the data block, rather than incorporating it directly into the associative array.

Turning to the example, the associative array may include information as shown in Table 1 below. Descriptive names are used instead of actual names to aid in understanding the associative array. Also, the associative array may include many more rows. Because the associative array may be searched by key or value, the order of the rows is unimportant.

Table 1. Exemplary associative array

Figure imgf000030_0001

The method can also comprise generating a function call to at least one of the shared resources using data within the associative array (block 702 in FIG. 7). In the 5 example, proxy computer 140 can make a function call to a shared resource, more specifically to a clock (shared resource) and a logging system (another shared resource) to get the time and log the beginning of the transaction. The logging information may include the time and a transaction identifier. Note that some of the information within the associative array could be sent with the function call to the shared resource. o The method can further comprise receiving data from the function call (block 704).

In the example, the transaction identifier may be passed back to module 3202. The method can still further comprise processing data from the function call with other code within the first software module (block 706). Module 3202 may be more focused on processing the incoming message rather than processing data coming back from the 5 function call. Other modules, such as the content deliver plug-in module 3212, may perform such data processing. Note that the application-specific processing may occur before, during, or after function call(s), if any, are made to the shared resource(s).

A determination may be made whether the first software plug-in module is the last software plug-in module (diamond 722). If so, the method may end. Otherwise, the o method may continue with passing any or all of the data (including the associative array) from a prior software plug-in module to the next software plug-in module (block 802 in FIG. 8). In the example, the next software plug-in module is authorization module 3204. Authorization module 3204 may use some of the information that was collected or generated by module 3202. Passing the information reduces the load on hardware by not 5 sending a communication from proxy computer 140 to another computer (e.g., client computer 120) or making the same or similar function call to a shared resource for the same information.

The method can also comprise generating a function call to at least one of the shared resources using data within the associative array (block 822). Authorization module 3204 may make a function call to the parameter system to determine if the user has proper authorization, whether access can be granted (whether number of users currently connected to proxy computer has exceeded its limits), priority of connection (level or speed of service to be provided), etc. Module 3204 may pass user name and password when making the function call to the logging system. Module 3204 may also make a function call to the shared clock to obtain a time for the action.

The method can also comprise receiving dala from the function call (block 824). The data may include information regarding whether user at client computer 120 has proper security clearance, whether the connection could be made, priority of the connection, and the like. The method can further comprise processing data from the function call with other code within the current software plug-in module (block 826). An example may include sending a communication from proxy computer 140 to client computer 120 informing the user whether the connection was made. Alternatively, no further processing may occur with module 3204. A determination may be made whether the current software plug-in module is the last software plug-in module (diamond 842). If so, the method may end. Otherwise, the method may continue with block 802 in FIG. 8 and proceed in an iterative manner until the last software plug-in module is reached.

The remaining modules along row 3200 will be addressed to complete the example transaction to give a better understanding of actions within the modules and some function calls that those modules may make. More or fewer modules may be used. Also, more, fewer, or different function calls may be made bythe modules.

Data can be passed to request manipulation software plug-in module 3206. A function call can be made to a shared resource to determine if the request should be changed. The function call may pass information that a request for www.yahoo.com has been received or accessed. The shared resource may include logic to replace the original client request with www.google.com. The associative array may be changed to replace www.yahoo.com with www.google.com or be appended to note that the manipulated request is www.google.com. Module 3208 may perform the content retrieval. A function call can be made to a content cache (shared resource) at proxy computer 140 to determine if the content cache includes a network page forwww.google.com specifically formatted for a computer having a Netscape™ browser and a MacOS X™ operating system. Note that the browser and operating system information can be obtained from the associative array. If the content cache has the network page, it can be passed to module 3208. Otherwise, module 3208 may formulate an HTTP request to server computer 160 requesting the network page for the specific browser and operating system of client computer 120. After proxy computer 140 obtains the proper network page from server computer 160, module 3208 may send a function call to the content cache at proxy computer 140 to cache the network page. The proper network page and other information previously collected may be sent to module 3210.

Content manipulation module 3210 may delete, add, or replace some or all of the content within the proper network page returned. For example, when the proper Google network page is received or accessed, module 3210 may add advertisement(s) around the border(s) of the page. A function call can be made to a shared resource to determine which advertisement(s) should be added. The logging system may keep track of which advertisement is being added, whose advertisement it is, and how many times the advertisement has been added during the current billing cycle. The logging system, which is a shared resource, may access the counter (another shared resource) by itself. In other works, some or all of the shared resources may interact with each other without requiring an application-specific software plug-in module to intervene. The manipulated content and other information may be passed to module 3212.

Content delivery software plug-in module 3212 may take the Google network page formatted for a Netscape™ browser and MacOS X™ operating system and the advertisement(s) from module 3210 and prepare a communication using HTTP. The communication can be sentfrom proxy computer 140 to client computer 120. Function calls can be made to the logging system to note the actual content sent to client computer 120 and time sent. Any or all information collected or generated by modules 3202-3212 may be passed to module 3214.

Post-response communications module 3214 may be used to track usage or billing information. At the end of a transaction, module 3214 may make a function call to the clock to determine the current time, and make another function call to the logging system to determine how much time lapsed during the transaction and record any billing information. The billing information may be within a shared resource managed by an accounting department. Billing information for the user at client computer 120 may be passed from one of the shared resources to module 3214, which may return some of the information for the user at client computer 120. Proxy computer 140 may send a message to client computer 120 similar to "You were connected for 2.1 minutes and were charged $1.27. Thank you for using our service." Alternatively, no message may be sent and the method may end. Note that not all of the activities described in the process flow diagram in FIGs. 6-

8 are required, that a limitation within a specific activity may not be required, and that further activities may be performed in addition to those illustrated. Also, some of the activities may be performed substantially simultaneously during with other activities. After reading this specification, skilled artisans will be capable of determining what activities can be used for their specific needs. The power of creating new applications for the same protocol may be better understood with the flow diagram in FIG. 9 and an example. In one embodiment, different applications may be generated for different priorities of users for a network site. The communication protocol may use HTTP. The method can comprise developing a first set of plug-in modules for a first application (block 902). The set may correspond to row 3200 and be directed to premium users of a network site.

A new application may need to be developed for regular users of the network site. The communication protocol may also use HTTP. The method can comprise copying the first set of plug-in modules to form a second set of plug-in modules (block 922).

For the new application, only the request manipulation plug-in module, the content manipulatbn plug-in module, or both may be replaced. The remainder of the plug-in modules may be unchanged and be substantially the same as the remainder of the plug- in modules for the first application.

The method may comprise replacing a first request manipulation plug-in module with a second request manipulation plug-in module for a second application (block 924). For example, the premium user may have access to some network pages that the regular user may not. If the regular user requests a premium page, the second request manipulatbn module may direct the regular user to another network page for which the regular user has proper access.

The method may also comprise replacing a first content manipulation plug-in module with a second content manipulation plug-in module for the second application

(block 926). The premium user may have only 10 percent of his or her window occupied by advertisements, whereas the regular user may have 50 percent of his or her window occupied by advertisements. The second content manipulation module may reformat the retrieved content to allow for more advertising space. The second content manipulation module may also access the shared resources to obtain the advertisements and keep track of which advertisements were used. Device dependentoptimization of network pages (desktop computer vs. cellular phone, etc.) can be achieved by plugging in a module which transcodes content using settings developed for the particular device that made the initial request. After one or both of the request manipulatbn and content manipulation modules are replaced, the method can still further comprise executing the second application using the second set of plug-in modules (block 942).

Note that while the example focused more on replacing specific modules, in other embodiments, those modules may be generated by editing code within the corresponding modules within the first set for the first application. 5 After reading this specification, skilled artisans will appreciate that entirely different applications, using the same network protocol, can be developed by simply inserting new plug-in module(s) at the request manipulatbn location, the content request location, or both locations.

In other embodiments, the method and system may be used for nearly any other o network communications. As an example, client computer 120 may make a request for information within a database located at server computer 160. The request may be handled in a manner similar to a request for a network page. If the user does not have proper authorization to all information within a request, the request manipulation module may request only that information for which the user has property access or the content 5 manipulatbn module may add information stating that the user does not have proper access to some or all the information.

In another embodiment, the multiple-protocol software architecture and plug-in modules may be installed in client computer 120 or server computer 160. Not all modules in proxy computer 140 may be needed by client computer 120 or server computer 160. o Authorization modules 3204, 3404, and 3604 may not be used or can be coded to allow authorization (always authorized) at client computer 120. The content manipulation modules 3210, 3410, and 3610 may not be used bythe server computer 160. After reading this specification, skilled artisans are capable of determine which modules are needed and which ones can be eliminated or bypassed (module exists but passes 5 information through without performing any other significant activity).

The software components can be designed to maximize their ability use shared resources while minimizing the amount of code used for application-specific operations. Therefore, relatively smaller plug-in modules (compared to the shared resources) may be used to access the shared resources illustrated in the planes below the modules. In this o manner, less code needs to be written for a new protocol compared to the prior-art method of writing or copying and modifying an entire program for a specific protocol. For applications in the same protocol, the specific coding requirements may be much less. Furthermore, protocols are more likely to be supported because the coding requirements are less, and therefore, may be generated for protocols that have relatively fewer users 5 compared to other protocols. The method and system are significantly more efficient in both time and cost compared to existing prior-art methods dealing with the problem of many different applications in the same or different protocols.

Benefits, other advantages, and solutions to problems have been described above with regard to specific embodiments. However, the benefits, advantages, solutions to problems, and any element(s) that may cause any benefit, advantage, or solution to occur or become more pronounced are not to be construed as a critical, required, or essential feature or element of any or all the claims.

APPENDIX SHEET 1

Figure imgf000036_0002

Figure imgf000036_0003

Figure imgf000036_0001

FIG. 1 APPENDIX SHEET 2

Figure imgf000037_0001

FIG. 2 APPENDIX SHEET 3

Figure imgf000038_0001

FIG. 3

Figure imgf000038_0002
APPENDIX SHEET 4

Figure imgf000039_0001

FIG. 5 APPENDIX SHEET 5

Figure imgf000040_0001

FIG. 6 APPENDIX SHEET 6

Figure imgf000041_0001

FIG. 7 APPENDIX SHEET 7

Figure imgf000042_0001

FIG. 8 APPENDIX SHEET 8

Figure imgf000043_0001

FIG. 9

Claims

WHAT IS CLAIMED IS:
1. A method for protecting a software system comprising: executing a first software component of a software system wherein the first software component has been designated for protection; determining whether a fault occurred during execution of the first software component; and restoring the software system to a state before execution of the first software component if the fault is detected.
2. The method of claim 1, further comprising: continuing execution of the software system after restoring the software system if the fault is detected.
3. The method of claim 1 , further comprising: continuing execution of the software system if no fault is detected.
4. The method of claim 1 , further comprising: designating the first software componentfor protection; and designating the first software component, further comprises assigning a default return value for the software component if the fault is detected.
5. The method of claim 1 , wherein: the first software component comprises code in a programming language, wherein this programming language alows a programmer to use a pointer to a memory address.
6. The method of claim 1, wherein: determining whether a fault occurred is preformed by a system function.
7. The method of claim 1, wherein: determining whether a fault occurred is preformed using a pattern placed in a 5 memory.
8. The method of claim 1 , further comprising: saving the state before executing the first software component.
0 9. The method of claim 8, wherein: saving and restoring the state is preformed using a system function.
10. The method of claim 8, wherein: the software system utilizes threads; and 5 the state is saved for each thread.
11. The method of claim 1 , further comprising executing a second software component, wherein: the second software component has been designated for protection; and o the first software component is nested within the second software component.
12. The method of claim 1 , wherein determining the fault is preformed using an execution time of the first software component. 5
13. A data processing system readable medium, comprising code containing instructions translatable for: executing a first software component of a software system wherein the first software component has been designated for protection; determining whether a fault occurred during execution of the first software component; and restoring the software system to a state before execution of the first software component if the fault is detected.
14. The data processing system readable medium of claim 13, wherein the code further comprises instructions translatable for: continuing execution of the software system after restoring the software system if the fault is detected.
15. The data processing system readable medium of claim 13, wherein the code further comprises instructions translatable for: continuing execution of the software system if no fault is detected.
16. The data processing system readable medium of claim 13, wherein the code further comprises instructions translatable for: assigning a default return value for the first software component if the fault is detected.
17. The data processing system readable medium of claim 13, wherein: the software system comprises code in a programming language, wherein that programming language allows a programmer to use a pointer to a memory address.
18. The data processing system readable medium of claim 13, wherein: determining the fault is preformed by a system function.
19. The data processing system readable medium of claim 13, wherein: determining the fault is preformed using a pattern in a memory.
5 20. The data processing system readable medium of claim 13, further comprising: saving the state before executing the first software component.
21. The data processing system readable medium of claim 20, wherein: saving and restoring the state is preformed using a system function. 0
22. The data processing system readable medium of claim 20, wherein the software system utilizes threads; and the state is saved for every thread.
5 23. The data processing system readable medium of claim 12, wherein the software system further comprises a second software component wherein the second software component has been designated for protection; and the first software component is nested within the second software component.
o 24. The method of claim 13, wherein determining the fault is preformed using an execution time of the first software component.
25. A system for protecting a system during execution of a software component, comprising: a first software component; a second software component, wherein the second software component is 5 configured to: save a state of the system before execution of the first software component; determine if a fault occurs during the execution of the first software component; and 0 restore the system to the state if the fault occurs during execution of the first software component.
26. The system of claim 25, wherein: the second software component is further configured to return a default value if 5 the fault occurs during execution of the first software component
27. The system of claim 25, wherein: the system is configured to continue executing after the state is restored.
o 28. The system of claim 25 further comprising a third software component, wherein: the third software component has been designated for protection; and the first software component is nested within the third software component.
29. The system of claim 25, wherein: 5 the second software component determines if a fault occurs during the execution of the first software component using a memory pattern.
30. The system of claim 25, wherein: the second software component determines if a fault occurs during the execution of the first software component by monitoring an execution time of the first software component.
PCT/US2003/001526 2002-01-18 2003-01-17 Method and computer system for protecting software components of an application against faults WO2003062991A2 (en)

Priority Applications (8)

Application Number Priority Date Filing Date Title
US34942402P true 2002-01-18 2002-01-18
US34963202P true 2002-01-18 2002-01-18
US34934402P true 2002-01-18 2002-01-18
US60/349,424 2002-01-18
US60/349,344 2002-01-18
US60/349,632 2002-01-18
US10/342,113 US7073178B2 (en) 2002-01-18 2003-01-14 Method and system of performing transactions using shared resources and different applications
US10/342,113 2003-01-14

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
AU2003205209A AU2003205209A1 (en) 2002-01-18 2003-01-17 Method and computer system for protecting software components of an application against faults

Publications (2)

Publication Number Publication Date
WO2003062991A2 true WO2003062991A2 (en) 2003-07-31
WO2003062991A3 WO2003062991A3 (en) 2004-10-14

Family

ID=27617816

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2003/001526 WO2003062991A2 (en) 2002-01-18 2003-01-17 Method and computer system for protecting software components of an application against faults

Country Status (2)

Country Link
AU (1) AU2003205209A1 (en)
WO (1) WO2003062991A2 (en)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB1509193A (en) * 1974-04-17 1978-05-04 Nat Res Dev Computer systems
US5748882A (en) * 1992-09-30 1998-05-05 Lucent Technologies Inc. Apparatus and method for fault-tolerant computing
EP0965923A2 (en) * 1998-06-19 1999-12-22 Intellution Inc. System and method for secure software component containment

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB1509193A (en) * 1974-04-17 1978-05-04 Nat Res Dev Computer systems
US5748882A (en) * 1992-09-30 1998-05-05 Lucent Technologies Inc. Apparatus and method for fault-tolerant computing
EP0965923A2 (en) * 1998-06-19 1999-12-22 Intellution Inc. System and method for secure software component containment

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
COMPUT SURV JUN 1978, vol. 10, no. 2, June 1978 (1978-06), pages 123-165, XP002291908 *
RAFNEL B A: "A TRANSACTION APPROACH TO ERROR HANDLING" HEWLETT-PACKARD JOURNAL, HEWLETT-PACKARD CO. PALO ALTO, US, vol. 44, no. 3, 1 June 1993 (1993-06-01), pages 71-77, XP000369411 *

Also Published As

Publication number Publication date
WO2003062991A3 (en) 2004-10-14
AU2003205209A1 (en) 2003-09-02

Similar Documents

Publication Publication Date Title
JP4363676B2 (en) Computer system
US6330588B1 (en) Verification of software agents and agent activities
Glerum et al. Debugging in the (very) large: ten years of implementation and experience
US8966312B1 (en) System and methods for run time detection and correction of memory corruption
Maheshwari et al. How to build a trusted database system on untrusted storage
Salamat et al. Orchestra: intrusion detection using parallel execution and monitoring of program variants in user-space
JP4676744B2 (en) Security-related programming interface
US6591379B1 (en) Method and system for injecting an exception to recover unsaved data
Bartlett et al. Commercial fault tolerance: A tale of two systems
US5504859A (en) Data processor with enhanced error recovery
US7272748B1 (en) Method and apparatus to detect and recover from a stack frame corruption
US7661035B2 (en) Method and system for instruction tracing with enhanced interrupt avoidance
CN1740945B (en) Method and system for identifying potential unwanted software
KR960001748B1 (en) Computer system management method and memory system for a
US6513155B1 (en) Method and system for merging event-based data and sampled data into postprocessed trace output
US7617074B2 (en) Suppressing repeated events and storing diagnostic information
US7225361B2 (en) Detecting a stalled routine
AU687095B2 (en) File Backup System
US7127642B2 (en) System and method for self-diagnosing system crashes
US8510597B2 (en) Providing restartable file systems within computing devices
US7302613B2 (en) System and method for capturing kernel-resident information
US20130246038A1 (en) Emulator updating system and method
US5491808A (en) Method for tracking memory allocation in network file server
US6769077B2 (en) System and method for remotely creating a physical memory snapshot over a serial bus
US20020073402A1 (en) Method for inserting global breakpoints

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ OM PH PL PT RO RU SC SD SE SG SK SL TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PT SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase in:

Ref country code: JP

WWW Wipo information: withdrawn in national office

Country of ref document: JP