Process Mirroring

NTDEV
1

Hi
The Project I work on has a set of applications. One
of those apps is very critical to the system. So I
plan to mirror this app alone on multiple machines.

Currently my idea is to run the app on two machines
simultaneously by attaching to it as a debugger on
both machines, saving their context+xyz during each
instruction and synchronizing with the debugger app on
other machine. In the event of failure of the critical
process I hope to restart the app at the point at
which it failed using the saved context info.

The assumptions I make here (for now) are
1)the critical app doesn’t interact with user or any
other process
2)performance is not a issue

Please advice me whether this is feasible? Also is
there any better way of doing it. Also is there any
third party product that does this, so that may be I
can try that.

Thanks,
Sajeev.

*NEW* Connect to Yahoo! Messenger through your mobile phone *NEW*
Visit http://in.mobile.yahoo.com/smsmgr_signin.html

You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

2

It is feasible but hopelessly slow. It these are your own applications,
the more traditional approach is to save state information on a somewhat
coarser granularity - like before performing an observable change (a
write operation to disk, for example.) The saved state constitutes a
checkpoint that the mirror application can resume operations from if the
primary fails. The point is that a lot of the execution of a program
does not really matter - it changes no externally visible state - and as
such it can be repeated on failure.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of sajeev sas
Sent: Saturday, October 20, 2001 3:14 AM
To: NT Developers Interest List
Subject: [ntdev] Process Mirroring

Hi
The Project I work on has a set of applications. One
of those apps is very critical to the system. So I
plan to mirror this app alone on multiple machines.

Currently my idea is to run the app on two machines
simultaneously by attaching to it as a debugger on both
machines, saving their context+xyz during each instruction
and synchronizing with the debugger app on other machine. In
the event of failure of the critical process I hope to
restart the app at the point at which it failed using the
saved context info.

The assumptions I make here (for now) are
1)the critical app doesn’t interact with user or any
other process
2)performance is not a issue

Please advice me whether this is feasible? Also is
there any better way of doing it. Also is there any
third party product that does this, so that may be I
can try that.

Thanks,
Sajeev.

*NEW* Connect to Yahoo! Messenger through your mobile phone *NEW*
Visit http://in.mobile.yahoo.com/smsmgr_signin.html

You are currently subscribed to ntdev as:
xxxxx@hollistech.com To unsubscribe send a blank email to
leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

3

Hi Mark,
Though it’s my application, one of the requirements is
to avoid changing the code so as to make it as generic
as possible.

Deviating from my old approach, Instead of always
running two copies of the same process, another
approach is to inject a dll into the target process
and by using a timer save the context+other info in a
shared buffer. This can be used to recreate the
process if it crashed. In this approach only one copy
of the process is running at a time and also context
saving doesn’t happen for every instruction.

Thanks,
Sajeev.

— Mark Roddy wrote: > It is
feasible but hopelessly slow. It these are
> your own applications,
> the more traditional approach is to save state
> information on a somewhat
> coarser granularity - like before performing an
> observable change (a
> write operation to disk, for example.) The saved
> state constitutes a
> checkpoint that the mirror application can resume
> operations from if the
> primary fails. The point is that a lot of the
> execution of a program
> does not really matter - it changes no externally
> visible state - and as
> such it can be repeated on failure.
>
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com] On Behalf
> Of sajeev sas
> > Sent: Saturday, October 20, 2001 3:14 AM
> > To: NT Developers Interest List
> > Subject: [ntdev] Process Mirroring
> >
> >
> > Hi
> > The Project I work on has a set of applications.
> One
> > of those apps is very critical to the system. So I
> > plan to mirror this app alone on multiple
> machines.
> >
> > Currently my idea is to run the app on two
> machines
> > simultaneously by attaching to it as a debugger on
> both
> > machines, saving their context+xyz during each
> instruction
> > and synchronizing with the debugger app on other
> machine. In
> > the event of failure of the critical process I
> hope to
> > restart the app at the point at which it failed
> using the
> > saved context info.
> >
> > The assumptions I make here (for now) are
> > 1)the critical app doesn’t interact with user or
> any
> > other process
> > 2)performance is not a issue
> >
> > Please advice me whether this is feasible? Also is
> > there any better way of doing it. Also is there
> any
> > third party product that does this, so that may be
> I
> > can try that.
> >
> > Thanks,
> > Sajeev.
> >
> >
>

> > NEW Connect to Yahoo! Messenger through your
> mobile phone NEW
> > Visit
> http://in.mobile.yahoo.com/smsmgr_signin.html
> >
> > —
> > You are currently subscribed to ntdev as:
> > xxxxx@hollistech.com To unsubscribe send a blank
> email to
> > leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
> >
> >
>
>
>
> —
> You are currently subscribed to ntdev as:
> xxxxx@yahoo.com
> To unsubscribe send a blank email to
leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com


NEW Connect to Yahoo! Messenger through your mobile phone NEW
Visit http://in.mobile.yahoo.com/smsmgr_signin.html

—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

4

You might look at NT Swift this is a Bell Labs
Project that did this sort of thing. A set of
slides on it is at
http:/ / www.usenix.org/ publications/ library/ proceedings/ usenix-nt98/
huang_slides/ index.htm

Don Burn
Windows 2000 Device Driver and Filesystem consulting

----- Original Message -----
From: “sajeev sas”
To: “NT Developers Interest List”
Sent: Monday, October 22, 2001 1:27 AM
Subject: [ntdev] RE: Process Mirroring

> Hi Mark,
> Though it’s my application, one of the requirements is
> to avoid changing the code so as to make it as generic
> as possible.
>
> Deviating from my old approach, Instead of always
> running two copies of the same process, another
> approach is to inject a dll into the target process
> and by using a timer save the context+other info in a
> shared buffer. This can be used to recreate the
> process if it crashed. In this approach only one copy
> of the process is running at a time and also context
> saving doesn’t happen for every instruction.
>
> Thanks,
> Sajeev.
>
> — Mark Roddy wrote: > It is
> feasible but hopelessly slow. It these are
> > your own applications,
> > the more traditional approach is to save state
> > information on a somewhat
> > coarser granularity - like before performing an
> > observable change (a
> > write operation to disk, for example.) The saved
> > state constitutes a
> > checkpoint that the mirror application can resume
> > operations from if the
> > primary fails. The point is that a lot of the
> > execution of a program
> > does not really matter - it changes no externally
> > visible state - and as
> > such it can be repeated on failure.
> >
> > > -----Original Message-----
> > > From: xxxxx@lists.osr.com
> > > [mailto:xxxxx@lists.osr.com] On Behalf
> > Of sajeev sas
> > > Sent: Saturday, October 20, 2001 3:14 AM
> > > To: NT Developers Interest List
> > > Subject: [ntdev] Process Mirroring
> > >
> > >
> > > Hi
> > > The Project I work on has a set of applications.
> > One
> > > of those apps is very critical to the system. So I
> > > plan to mirror this app alone on multiple
> > machines.
> > >
> > > Currently my idea is to run the app on two
> > machines
> > > simultaneously by attaching to it as a debugger on
> > both
> > > machines, saving their context+xyz during each
> > instruction
> > > and synchronizing with the debugger app on other
> > machine. In
> > > the event of failure of the critical process I
> > hope to
> > > restart the app at the point at which it failed
> > using the
> > > saved context info.
> > >
> > > The assumptions I make here (for now) are
> > > 1)the critical app doesn’t interact with user or
> > any
> > > other process
> > > 2)performance is not a issue
> > >
> > > Please advice me whether this is feasible? Also is
> > > there any better way of doing it. Also is there
> > any
> > > third party product that does this, so that may be
> > I
> > > can try that.
> > >
> > > Thanks,
> > > Sajeev.
> > >
> > >
> >
>
> > > NEW Connect to Yahoo! Messenger through your
> > mobile phone NEW
> > > Visit
> > http://in.mobile.yahoo.com/smsmgr_signin.html
> > >
> > > —
> > > You are currently subscribed to ntdev as:
> > > xxxxx@hollistech.com To unsubscribe send a blank
> > email to
> > > leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
> > >
> > >
> >
> >
> >
> > —
> > You are currently subscribed to ntdev as:
> > xxxxx@yahoo.com
> > To unsubscribe send a blank email to
> leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>
>
> NEW Connect to Yahoo! Messenger through your mobile phone NEW
> Visit http://in.mobile.yahoo.com/smsmgr_signin.html
>
> —
> You are currently subscribed to ntdev as: xxxxx@acm.org
> To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

5

Unfortunately, you probably also saved the condition that caused the program
to crash in the first place. More than likely, this will lead to repeated
crashes until you clear the current state. The far superior (and only
really workable) solution is to have cooperating but independent processes
passing checkpoint information to the other process in a semi-lock-step
approach. Also, each “Mirror Process” must watchdog the other one to know
when to switch roles. This isn’t always easy to get right and takes
experience in fault-tolerant design. The entire notion of “not modifying an
existing program” and still having the level of fault tolerance you desire
is self-contradictory. Sorry, but you have to design this in. It cannot be
globbed on externally.

Greg

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of sajeev sas
Sent: Monday, October 22, 2001 12:27 AM
To: NT Developers Interest List
Subject: [ntdev] RE: Process Mirroring

Hi Mark,
Though it’s my application, one of the requirements is
to avoid changing the code so as to make it as generic
as possible.

Deviating from my old approach, Instead of always
running two copies of the same process, another
approach is to inject a dll into the target process
and by using a timer save the context+other info in a
shared buffer. This can be used to recreate the
process if it crashed. In this approach only one copy
of the process is running at a time and also context
saving doesn’t happen for every instruction.

Thanks,
Sajeev.

You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

6

Actually it is possible to do this transparently, but it is a lot more work
than the approach that Gregory outlines below. The idea is to checkpoint
around IO output operations, with the checkpoint being the entire set of
memory writes between the last checkpoint and the current one.

There are of course other minor details that one has to work out for process
mirroring, stupid stuff like timestamps, handles, etc. that may very well be
different between process images.

Whether you actually repeat the crash condition or not depends on a lot of
variables. The experience we had at Sequoia Systems, where we built
commercial fault tolerant systems that used a checkpoint and rollback
scheme, was that there were a significant number of defects that, due to
timing or other issues, were not repeated on recovery. Also, software
defects are obviously not the only reason for system failure.

-----Original Message-----
From: Gregory G. Dyess [mailto:xxxxx@pdq.net]
Sent: Monday, October 22, 2001 8:27 AM
To: NT Developers Interest List
Subject: [ntdev] RE: Process Mirroring

Unfortunately, you probably also saved the condition that caused the program
to crash in the first place. More than likely, this will lead to repeated
crashes until you clear the current state. The far superior (and only
really workable) solution is to have cooperating but independent processes
passing checkpoint information to the other process in a semi-lock-step
approach. Also, each “Mirror Process” must watchdog the other one to know
when to switch roles. This isn’t always easy to get right and takes
experience in fault-tolerant design. The entire notion of “not modifying an
existing program” and still having the level of fault tolerance you desire
is self-contradictory. Sorry, but you have to design this in. It cannot be
globbed on externally.

Greg

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of sajeev sas
Sent: Monday, October 22, 2001 12:27 AM
To: NT Developers Interest List
Subject: [ntdev] RE: Process Mirroring

Hi Mark,
Though it’s my application, one of the requirements is
to avoid changing the code so as to make it as generic
as possible.

Deviating from my old approach, Instead of always
running two copies of the same process, another
approach is to inject a dll into the target process
and by using a timer save the context+other info in a
shared buffer. This can be used to recreate the
process if it crashed. In this approach only one copy
of the process is running at a time and also context
saving doesn’t happen for every instruction.

Thanks,
Sajeev.

You are currently subscribed to ntdev as: xxxxx@stratus.com To
unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

7

This looks interesting.
Thanks Don - Sajeev.

— Don Burn wrote: > You might look
at NT Swift this is a Bell Labs
> Project that did this sort of thing. A set of
> slides on it is at
> http:/ / www.usenix.org/ publications/ library/
> proceedings/ usenix-nt98/
> huang_slides/ index.htm
>
> Don Burn
> Windows 2000 Device Driver and Filesystem consulting
>
> ----- Original Message -----
> From: “sajeev sas”
> To: “NT Developers Interest List”
>
> Sent: Monday, October 22, 2001 1:27 AM
> Subject: [ntdev] RE: Process Mirroring
>
>
> > Hi Mark,
> > Though it’s my application, one of the
> requirements is
> > to avoid changing the code so as to make it as
> generic
> > as possible.
> >
> > Deviating from my old approach, Instead of always
> > running two copies of the same process, another
> > approach is to inject a dll into the target
> process
> > and by using a timer save the context+other info
> in a
> > shared buffer. This can be used to recreate the
> > process if it crashed. In this approach only one
> copy
> > of the process is running at a time and also
> context
> > saving doesn’t happen for every instruction.
> >
> > Thanks,
> > Sajeev.
> >
> > — Mark Roddy wrote: > It
> is
> > feasible but hopelessly slow. It these are
> > > your own applications,
> > > the more traditional approach is to save state
> > > information on a somewhat
> > > coarser granularity - like before performing an
> > > observable change (a
> > > write operation to disk, for example.) The saved
> > > state constitutes a
> > > checkpoint that the mirror application can
> resume
> > > operations from if the
> > > primary fails. The point is that a lot of the
> > > execution of a program
> > > does not really matter - it changes no
> externally
> > > visible state - and as
> > > such it can be repeated on failure.
> > >
> > > > -----Original Message-----
> > > > From: xxxxx@lists.osr.com
> > > > [mailto:xxxxx@lists.osr.com] On
> Behalf
> > > Of sajeev sas
> > > > Sent: Saturday, October 20, 2001 3:14 AM
> > > > To: NT Developers Interest List
> > > > Subject: [ntdev] Process Mirroring
> > > >
> > > >
> > > > Hi
> > > > The Project I work on has a set of
> applications.
> > > One
> > > > of those apps is very critical to the system.
> So I
> > > > plan to mirror this app alone on multiple
> > > machines.
> > > >
> > > > Currently my idea is to run the app on two
> > > machines
> > > > simultaneously by attaching to it as a
> debugger on
> > > both
> > > > machines, saving their context+xyz during each
> > > instruction
> > > > and synchronizing with the debugger app on
> other
> > > machine. In
> > > > the event of failure of the critical process I
> > > hope to
> > > > restart the app at the point at which it
> failed
> > > using the
> > > > saved context info.
> > > >
> > > > The assumptions I make here (for now) are
> > > > 1)the critical app doesn’t interact with user
> or
> > > any
> > > > other process
> > > > 2)performance is not a issue
> > > >
> > > > Please advice me whether this is feasible?
> Also is
> > > > there any better way of doing it. Also is
> there
> > > any
> > > > third party product that does this, so that
> may be
> > > I
> > > > can try that.
> > > >
> > > > Thanks,
> > > > Sajeev.
> > > >
> > > >
> > >
> >
>

> > > > NEW Connect to Yahoo! Messenger through
> your
> > > mobile phone NEW
> > > > Visit
> > > http://in.mobile.yahoo.com/smsmgr_signin.html
> > > >
> > > > —
> > > > You are currently subscribed to ntdev as:
> > > > xxxxx@hollistech.com To unsubscribe send a
> blank
> > > email to
> > > > leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
> > > >
> > > >
> > >
> > >
> > >
> > > —
> > > You are currently subscribed to ntdev as:
> > > xxxxx@yahoo.com
> > > To unsubscribe send a blank email to
> > leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
> >
> >
>

> > NEW Connect to Yahoo! Messenger through your
> mobile phone NEW
> > Visit
> http://in.mobile.yahoo.com/smsmgr_signin.html
> >
> > —
> > You are currently subscribed to ntdev as:
> xxxxx@acm.org
> > To unsubscribe send a blank email to
> leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>
>
> —
> You are currently subscribed to ntdev as:
> xxxxx@yahoo.com
> To unsubscribe send a blank email to
leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

____________________________________________________________
NEW Connect to Yahoo! Messenger through your mobile phone NEW
Visit http://in.mobile.yahoo.com/smsmgr_signin.html

—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

8

Mark,
Though I agree with you that it’s possible to do this
completely application independent, I still have some
doubts on it. How often do you take a checkpoint,
it’ll be better if application itself tells the point
at which it is appropriate to take a checkpoint.

Also as you said if all the minor details like file
handles, sockets and ip routing is taken care it’s
entirely possible to do it application independent,
since none of these requires polling except the
checkpoint.

Thanks guys for all the inputs.
-Sajeev.

— “Roddy, Mark” wrote: >
Actually it is possible to do this transparently,
> but it is a lot more work
> than the approach that Gregory outlines below. The
> idea is to checkpoint
> around IO output operations, with the checkpoint
> being the entire set of
> memory writes between the last checkpoint and the
> current one.
>
> There are of course other minor details that one has
> to work out for process
> mirroring, stupid stuff like timestamps, handles,
> etc. that may very well be
> different between process images.
>
> Whether you actually repeat the crash condition or
> not depends on a lot of
> variables. The experience we had at Sequoia Systems,
> where we built
> commercial fault tolerant systems that used a
> checkpoint and rollback
> scheme, was that there were a significant number of
> defects that, due to
> timing or other issues, were not repeated on
> recovery. Also, software
> defects are obviously not the only reason for system
> failure.
>
>
>
> -----Original Message-----
> From: Gregory G. Dyess [mailto:xxxxx@pdq.net]
> Sent: Monday, October 22, 2001 8:27 AM
> To: NT Developers Interest List
> Subject: [ntdev] RE: Process Mirroring
>
>
> Unfortunately, you probably also saved the condition
> that caused the program
> to crash in the first place. More than likely, this
> will lead to repeated
> crashes until you clear the current state. The far
> superior (and only
> really workable) solution is to have cooperating but
> independent processes
> passing checkpoint information to the other process
> in a semi-lock-step
> approach. Also, each “Mirror Process” must watchdog
> the other one to know
> when to switch roles. This isn’t always easy to get
> right and takes
> experience in fault-tolerant design. The entire
> notion of “not modifying an
> existing program” and still having the level of
> fault tolerance you desire
> is self-contradictory. Sorry, but you have to
> design this in. It cannot be
> globbed on externally.
>
> Greg
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com]On Behalf Of
> sajeev sas
> Sent: Monday, October 22, 2001 12:27 AM
> To: NT Developers Interest List
> Subject: [ntdev] RE: Process Mirroring
>
>
> Hi Mark,
> Though it’s my application, one of the requirements
> is
> to avoid changing the code so as to make it as
> generic
> as possible.
>
> Deviating from my old approach, Instead of always
> running two copies of the same process, another
> approach is to inject a dll into the target process
> and by using a timer save the context+other info in
> a
> shared buffer. This can be used to recreate the
> process if it crashed. In this approach only one
> copy
> of the process is running at a time and also context
> saving doesn’t happen for every instruction.
>
> Thanks,
> Sajeev.
>
>
>
> —
> You are currently subscribed to ntdev as:
> xxxxx@stratus.com To
> unsubscribe send a blank email to
> leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>
> —
> You are currently subscribed to ntdev as:
> xxxxx@yahoo.com
> To unsubscribe send a blank email to
leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

____________________________________________________________
NEW Connect to Yahoo! Messenger through your mobile phone NEW
Visit http://in.mobile.yahoo.com/smsmgr_signin.html

—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

9

Another approach is to synchronize the inputs to the program.
In the simplest form, where the inputs occur at the beginning, e.g., on the command line, this is trivial.

If you record all of the inputs, and send them to the other system, you can play them
into the backup, and end up in the exact same state, so long as the program is deterministic,
and you don’t reorder the input events.

There was a startup company about 15 years ago (IMP?) that build a (sort-of) fault tolerant
computer around this concept. The main hardware support they needed was to synchronize inputs
between the two CPUs. (Their main failing was that they neglected one of the key points
of fault tolerance: you can only recover from faults that you detect before they damage the second
copy.)

-DH
----- Original Message -----
From: “sajeev sas”
To: “NT Developers Interest List”
Sent: Tuesday, October 23, 2001 12:43 AM
Subject: [ntdev] RE: Process Mirroring

> Mark,
> Though I agree with you that it’s possible to do this
> completely application independent, I still have some
> doubts on it. How often do you take a checkpoint,
> it’ll be better if application itself tells the point
> at which it is appropriate to take a checkpoint.
>
> Also as you said if all the minor details like file
> handles, sockets and ip routing is taken care it’s
> entirely possible to do it application independent,
> since none of these requires polling except the
> checkpoint.
>
> Thanks guys for all the inputs.
> -Sajeev.
>
> — “Roddy, Mark” wrote: >
> Actually it is possible to do this transparently,
> > but it is a lot more work
> > than the approach that Gregory outlines below. The
> > idea is to checkpoint
> > around IO output operations, with the checkpoint
> > being the entire set of
> > memory writes between the last checkpoint and the
> > current one.
> >
> > There are of course other minor details that one has
> > to work out for process
> > mirroring, stupid stuff like timestamps, handles,
> > etc. that may very well be
> > different between process images.
> >
> > Whether you actually repeat the crash condition or
> > not depends on a lot of
> > variables. The experience we had at Sequoia Systems,
> > where we built
> > commercial fault tolerant systems that used a
> > checkpoint and rollback
> > scheme, was that there were a significant number of
> > defects that, due to
> > timing or other issues, were not repeated on
> > recovery. Also, software
> > defects are obviously not the only reason for system
> > failure.
> >
> >
> >
> > -----Original Message-----
> > From: Gregory G. Dyess [mailto:xxxxx@pdq.net]
> > Sent: Monday, October 22, 2001 8:27 AM
> > To: NT Developers Interest List
> > Subject: [ntdev] RE: Process Mirroring
> >
> >
> > Unfortunately, you probably also saved the condition
> > that caused the program
> > to crash in the first place. More than likely, this
> > will lead to repeated
> > crashes until you clear the current state. The far
> > superior (and only
> > really workable) solution is to have cooperating but
> > independent processes
> > passing checkpoint information to the other process
> > in a semi-lock-step
> > approach. Also, each “Mirror Process” must watchdog
> > the other one to know
> > when to switch roles. This isn’t always easy to get
> > right and takes
> > experience in fault-tolerant design. The entire
> > notion of “not modifying an
> > existing program” and still having the level of
> > fault tolerance you desire
> > is self-contradictory. Sorry, but you have to
> > design this in. It cannot be
> > globbed on externally.
> >
> > Greg
> >
> >
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com]On Behalf Of
> > sajeev sas
> > Sent: Monday, October 22, 2001 12:27 AM
> > To: NT Developers Interest List
> > Subject: [ntdev] RE: Process Mirroring
> >
> >
> > Hi Mark,
> > Though it’s my application, one of the requirements
> > is
> > to avoid changing the code so as to make it as
> > generic
> > as possible.
> >
> > Deviating from my old approach, Instead of always
> > running two copies of the same process, another
> > approach is to inject a dll into the target process
> > and by using a timer save the context+other info in
> > a
> > shared buffer. This can be used to recreate the
> > process if it crashed. In this approach only one
> > copy
> > of the process is running at a time and also context
> > saving doesn’t happen for every instruction.
> >
> > Thanks,
> > Sajeev.
> >
> >
> >
> > —
> > You are currently subscribed to ntdev as:
> > xxxxx@stratus.com To
> > unsubscribe send a blank email to
> > leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
> >
> > —
> > You are currently subscribed to ntdev as:
> > xxxxx@yahoo.com
> > To unsubscribe send a blank email to
> leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>
> ____________________________________________________________
> NEW Connect to Yahoo! Messenger through your mobile phone NEW
> Visit http://in.mobile.yahoo.com/smsmgr_signin.html
>
> —
> You are currently subscribed to ntdev as: xxxxx@syssoftsol.com
> To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com