1. A New, Efficient Coordinated Check pointing
Protocol Combined with
Selective Sender-Based Message Logging
(Synopsis)

2. Abstract:
Check pointing and message logging are the popular and
general-purpose tools for providing fault tolerance in distributed
systems. The most of the Coordinated check pointing algorithms
available in the literature have not addressed about treatment of the
lost messages and these algorithms suffer from high output commit
latency. To overcome the above limitations, we propose a new
coordinated check pointing protocol combined with selective senderbased message logging. The protocol is free from the problem of lost
messages. The term ‘selective’ implies that messages are logged only
within a specified interval known as active interval, thereby reducing
message logging overhead. All processes take checkpoints at the end
of their respective active intervals forming a consistent global state.

3. Introduction:
Check pointing refers to saving the address space and
state of processes periodically to stable storage. On detection of
failures, each process rolls back to its latest checkpoint and resumes
the execution from that point. Check pointing protocols are categorized
into two main classes i.e. independent and coordinated check pointing.
In independent check pointing each process checkpoints its state
independently and does not require any synchronization when a
checkpoint is taken. It can have potentially high recovery overhead
because of domino effect i.e. rollback of one process causes avalanche
rollback of other processes to find a consistent recovery line. In
coordinated check pointing, the processes coordinate their check
pointing actions in such a way that the set of local checkpoints taken is
consistent . Hence the performance of coordinated check pointing is
better than that of Independent check pointing. However, the
Coordinated check pointing algorithms available in the literature have
not addressed about treatment of the lost messages and these
algorithms suffer from high output commit latency
In general, the message logging protocols are combined
with independent checkpointing. The limitations of this strategy are i)
High message logging overhead ii) Recovery is complex and doesn’t
ensure protocol to be free from domino effect. iii) Checkpointing
overhead is more. iv) Rollback is unbounded, because of which useful
computation is lost. v) Storage overhead is high. To overcome the
above limitations, a new coordinated checkpointing protocol combined
with selective sender- based message logging is proposed. The term
‘selective’ implies that messages are logged only within a specified
interval known as active interval, thereby reducing the message

4. logging overhead. In our protocol, messages are kept in the volatile
memory of the sender and flushed to stable storage only when taking
a new checkpoint. This technique results substantial decrease in the
message
logging
applications.
overhead
even
for
communication
intensive

5. Existing System :
Checkpointing and message logging are the popular and generalpurpose tools for providing fault tolerance in distributed systems. The
most of the coordinated checkpointing algorithms available in the
literature have not addressed about treatment of the lost messages
and these algorithms suffer from high output commit latency.
Disadvantages:
•
Rollback recovery recovery was not treated.
•
Checkpoint storage was not used.
Proposed System :
To overcome the above limitations, we propose a new
coordinated checkpointing protocol combined with selective senderbased message logging. The protocol is free from the problem of lost
messages. The term ‘selective’ implies that messages are logged only
within a specified interval known as active interval, thereby reducing
message logging overhead. All processes take checkpoints at the end
of their respective active intervals forming a consistent global state.
Outside the active interval there is no checkpointing of process state.
Advantages :
•
Rollback recovery is used
•
Checkpoint storage
•
Garbage Collection is used

6. Modules:
1. Calculation of Active Interval.
2. Handling of lost messages.
3. Handling of orphan messages.
4. Handling of garbage collection.
Module Description:
Calculation of Active Interval
In this module the coordinator send the prepare check point
message to the client. After particular time duration the coordinator
resend the message of take checkpoint. The time duration between
the prepare checkpoint message and take checkpoint message is
known as Active Time Interval.
AI
CP
CT
CP – Prepare Checkpoint
CT – Take Checkpoint
AI – Active Time Interval
Handling of Lost Messages
In this module, the messages sent during the active interval
of a sender process under consideration and received after the active

7. interval of a destination process under consideration are referred to as
lost messages. It is also calculate the message sent count and
message received count. It maintain in FIFO method.
Handling of Orphan Message
The messages sent after the active interval of a sender process
under consideration and received before the active interval of a
destination process under consideration are referred to as orphan
messages. In case of any failure, processes rollback to their latest
checkpoints, and replays the orphan/duplicate messages which should
be ignored by the receiving process. Since, the receiver maintains the
SSN count in its latest checkpoint, if the sender tries to replay any
messages
whose SSN count is less than or equal to receivers SSN;
the receiver discards them as orphan messages.
SSN –Sender Sequence Number
Handling of Garbage Collection
Garbage collection is the process of reclaiming the space
allocated to the unwanted checkpoints by removing them from the
stable storage. Whenever Pinitiator sends ‘prepare for checkpoint’
message to all other processes in the (n+1)th interval, the protocol
will automatically delete the global consistent state formed in the (n1)th interval, as it is no longer required; thereby ensuring garbage
collection.

8. REQUIREMENTS
Software requirements
Operating System
:
Windows
Programming Package :
JAVA
Tools
:
My Eclipse
SDK
:
JDK1.5.0
Hardware Specification
Processor
: Pentium IV
Speed
: 1.5 GHz
Main Memory
: 256 MB
Hard Disk Drive
Floppy Drive
: 40 GB
: 1.44 inches