SAFETY OF CHECKPOINTING AND ROLLBACK-RECOVERY
PROTOCOL FOR MOBILE SYSTEMS WITH RYW SESSION
GUARANTEE
∗
Jerzy Brzezi
´
nski, Anna Kobusi
´
nska, Jacek Kobusi
´
nski
Pozna
´
n University of Technology, Institute of Computing Science
ul. Piotrowo 2, 60-965 Pozna
´
n, Poland
Keywords:
Rollback-recovery, mobile systems, Read Your Writes session guarantee.
Abstract:
This paper presents rVsRYW checkpointing and rollback-recovery protocol, which preserves Read Your
Writes session guarantee and includes the proof of safety property of the proposed protocol. In order to
provide RYW guarantee required by mobile clients, despite failures of servers, in rVsRYW protocol semantics
of consistency protocol operations is exploited and build in recovery mechanisms.
1 INTRODUCTION
Mobile environments, by enabling motion and loca-
tion independence of clients, give the opportunity to
provide new services and allow supplementary infor-
mation access that may occur any time and any place.
In such environments, clients accessing the data may
not be bound to particular servers, but they can switch
from one server to another. This switching adds a
new dimension of complexity to the problem of con-
sistency, because after switching to another server,
client’s new operations should remain consistent with
ones previously issued. Therefore, a new class of
consistency models, called session guarantees, rec-
ommended for mobile environment, has been intro-
duced (Terry et al., 1994). Session guarantees, also
called client-centric consistency models, define re-
quired properties of the system observed from clients
point of view. Four session guarantees have been de-
fined: Read Your Writes (RYW), Monotonic Writes
(MW), Monotonic Reads (MR) and Writes Follow
Reads (WFR) and protocols implementing them have
been introduced (Terry et al., 1994; Kobusi
´
nska et al.,
2005; Sobaniec, 2005). However, according to our
knowledge, none of proposed consistency protocols is
resistant to servers’ failures. Such assumption might
be considered not plausible and too strong for certain
mobile distributed systems. Therefore, in this paper
checkpointing and rollback-recovery protocol rVsSG
∗
This work was supported in part by the State Com-
mittee for Scientific Research (KBN), Poland, under grant
KBN 3 T11C 073 28
that preserves RYW session guarantee is introduced.
rVsRYW protocol ensures that after the server fail-
ure and its recovery, RYW session guarantee is pre-
served. In the proposed protocol the semantics of op-
erations of VsSG consistency protocol (Kobusi
´
nska
et al., 2005; Sobaniec, 2005) is exploited and build in
recovery mechanisms. As a result, rVsRYW protocol
offers the ability to overcome servers’ failures, at the
same time preserving RYW session guarantee.
2 BASIC DEFINITIONS
2.1 System Model
Throughout this paper, a replicated, distributed stor-
age system is considered. The system consists of
a number of servers holding a full copy of a set of
data items and clients running applications that ac-
cess these data items. Although all system compo-
nents (mobile clients, servers, communication links)
can be a subject of failures, in this paper we assume
that only servers are prone to failures, and thus we
do not consider failures of clients and network links.
Servers may crash at arbitrary moments and recover
after crashing a finite number of times, according
to crash-recovery model of failures (Guerraoui and
Rodrigues, 2004). Clients are mobile, i.e. they can
switch from one server to the other. Moreover, they
are separated from servers, i.e. a client’s application
may run on a separate computer than the server. To
118
Brzezi
´
nski J., Kobusi
´
nska A. and Kobusi
´
nski J. (2006).
SAFETY OF CHECKPOINTING AND ROLLBACK-RECOVERY PROTOCOL FOR MOBILE SYSTEMS WITH RYW SESSION GUARANTEE.
In Proceedings of the Eighth International Conference on Enterprise Information Systems - SAIC, pages 118-123
DOI: 10.5220/0002446101180123
Copyright
c
 SciTePress

access shared data, the client selects a single server
and sends a direct request to this server. Operations
are issued by clients synchronously, i.e. a new oper-
ation may be issued after the results of the previous
one have been obtained.
The storage replicated by servers does not imply
the particular data model or organization. It is a set of
data items, which may be simple variables, files, ob-
jects of object-oriented programming language, etc.
Later in the paper, the data items are referred to as
objects. Operations performed on shared objects are
divided into reads and writes. Reads do not change
the state of objects, while writes does. Some clients
can concurrently submit conflicting writes at different
servers, e.g. writes that modify the overlapping parts
of data storage.
Operations on shared objects issued by client C
i
are ordered by relation
C
i
 called client issue order.
As client procecesses are sequential, relation
C
i
 de-
termines total order on the set of operations issued by
C
i
. Operations performed by server S
j
are ordered
by relation
S
j
, called server execution order. Since
operations are performed one at a time, the server ex-
ecution order is also totally ordered. Depending on
operation type (write, read or these whose type is ir-
relevant), operations on objects are denoted by w, r
or o. The operation performed by server S
j
is denoted
by o|
S
j
.
2.2 Session Guarantees
Session guarantees have been introduced in the con-
text of Bayou project (Terry et al., 1994). Informally,
RYW expresses the user expectation not to miss his
own modifications performed in the past. MW en-
sures that order of writes issued by a single client is
preserved. MR ensures that the client’s observations
of the data storage are monotonic, and finally WFR
keeps the track of causal dependencies resulting from
operations issued by a client.
In the paper, it is assumed that clients perceive the
data from the replicated storage according to Read
Your Writes session guarantee. Let us consider some
examples, how RYW session guarantee may be used
in practice.
First, let us consider a user writing a TODO list
to a file. After traveling to another location, the user
wants to recall the most urgent tasks, and reads TODO
list. Without RYW session guarantee the read may
return any previous (possibly empty) version of the
document.
Further, imagine that a user, after changing his
password, while logging to the system receives an
”invalid password” response. This problem would
arise in situation when the logging process contacted
a server to which a new password had not been prop-
agated. In this case RYW guarantee ensures that the
logging process will always read the most recent pass-
word. Formally RYW session guarantee is defined as
follows (Sobaniec, 2005):
D
EFINITION 1. Read Your Writes (RYW) session
guarantee is a property meaning that:
∀C
i
∀S
j

w
C
i
r|
S
j
⇒ w
S
j
 r

2.3 VsSG Coherency Protocol
Data consistency in the paper is managed by VsSG
consistency protocol (Kobusi
´
nska et al., 2005; Soban-
iec, 2005). The VsSG protocol uses a conception
of server-based version vectors for efficient represen-
tation of sets of writes required by clients. Server-
based version vectors have the following form: V =

v
1
v
2
... v
N
S

, where N
S
is a total number of
servers in the system and single position v
i
is the
number of writes performed by server S
j
.
The server, which first obtains the write from the
client is responsible for assigning such a write a glob-
ally unique identifier, returned by a function T : O →
V and set to the current value of the vector clock V
S
j
of server S
j
performing the write for the first time.
The set of all writes performed by server S
j
is de-
noted by O
S
j
. The sequence of past writes is called
history (Sobaniec, 2005). Formally:
D
EFINITION 2. A history H
S
j
at time moment t, is a
linearly ordered set

O
S
j
,
S
j


where O
S
j
is a set of
writes performed by server S
j
, till time t and relation
S
j
 represents an execution order of writes.
During writes performed by server S
j
, its ver-
sion vector V
S
j
is incremented in position j and a
timestamped operation is recorded in history H
S
j
. Fi-
nally, the current value of the server vector clock is
returned to the client and causes the update of the
client’s vector W
C
i
, representing writes issued by
the client. Servers occasionally synchronize states of
their replicas by exchanging information about writes
performed in the past. As a result, all writes submit-
ted by clients are eventually propagated and executed
by every server.
During synchronization of servers, their histories
are concatenated. The concatenation of histories H
S
j
and H
S
k
, denoted by H
S
j
⊕ H
S
k
is a sum of writes
from the first history and new writes from the second
history (Sobaniec, 2005).
SAFETY OF CHECKPOINTING AND ROLLBACK-RECOVERY PROTOCOL FOR MOBILE SYSTEMS WITH RYW
SESSION GUARANTEE
119

2.4 Checkpoint and Log Definitions
Below, we propose formal definitions of mechanisms
used by rVsRYW protocol:
D
EFINITION 3. AlogLog
S
j
is a set of triples:

i
1
,o
1
,T(o
1
)i
2
,o
2
,T(o
2
) ... i
n
,o
n
,T(o
n
)

,
where i
n
represents the index of the client that issued
a write operation o
n
, i
n
∈ 1..N
C
, and N
C
is a num-
ber of clients in the system. The operation o
n
∈O
S
j
and T (o
n
) is its timestamp.
During a rollback-recovery procedure, opera-
tions from the log are executed according to their
timestamps, from the earliest to the latest one.
D
EFINITION 4. A checkpoint Ckpt
S
j
is a couple

V
S
j
,H
S
j

, of a version vector V
S
j
and a history
H
S
j
maintained by server S
j
at the time t, where t
is a moment of taking a checkpoint.
For the sake of recovery procedure, it is commonly
assumed that servers have access to a stable stor-
age, able to survive all failures (Elmootazbellah et al.,
2002). The log and the checkpoint are saved by the
server in the stable storage. The newly taken check-
point replaces the previous one, so just one check-
point for each server is stored.
3 rVsRYW PROTOCOL
3.1 The General Idea
To preserve RYW session guarantee the protocol must
ensure that every write request issued by the client
is not lost by the server. Checkpointing every single
write operation fulfills this requirement, but results
in frequent saving of server state in the stable stor-
age, which is time–consuming. Logging procedure
overcomes this disadvantage and takes less time than
checkpointing, as only the operation, its timestamp
and issuing client index are stored in the stable stor-
age. On the other hand, the log size may grow infi-
nitely and may turn out to be too large. Combining
these two approaches by joining logging and check-
pointing seems to be the best solution. While apply-
ing these known techniques, the semantics of oper-
ations, characteristic of session guarantees, is taken
into account, which is a novel feature of proposed
protocol. Consequently, in rVsSG, only operations
essential to provide session guarantees are logged, so
checkpoints are optimized with respect to required
session guarantee requirements. Moreover, in pro-
posed protocol, it is assumed that only the server,
which performs write operation issued directly by a
client, logs this request to stable storage. Writes re-
ceived from other servers during synchronization pro-
cedure only cause server’s state update, but they are
not logged. The checkpoint is taken when the server
obtains read operation from a client, and since the lat-
est checkpoint, it has performed any write operation
issued directly from this client. Taking a checkpoint
results in clearing servers’ logs.
After a failure occurrence, the failed server restarts
from the latest checkpoint and replays operations
from the log to restore the execution to a state that
occurred before the failure.
3.2 Protocol Implementation
The request sent from client C
i
to server S
j
carries
the operation that is to be performed and a vector W
that is calculated depending on the operation type. W
is set to 0 (line 1) or to W
C
i
(line 3) for writes and
reads respectively. Afterwards, the modified message
o, W  is send to a server (line 5).
Server S
j
obtains operations o, W, i issued di-
rectly by a client or operations S
k
,H issued by
other servers in the result of synchronization proce-
dure. Upon receiving a new request from client C
i
, S
j
checks whether it has performed all writes issued pre-
viously by C
i
, by comparing version vectors V
S
j
and
W (line 6)(Sobaniec, 2005). If the state of server S
j
is not sufficiently up to date, the request is postponed,
because RYW session guarantee is not fulfilled (line
7). The request will be resumed after synchronization
with another server (line 40).
When the client requests to perform a write opera-
tion (line 9), then server S
j
stores issuing client iden-
tifier by adding clients’ index to the set CW
S
j
(line
10). Further S
j
updates its data structures: increases
the value of its version vector V
S
j
and timestamps the
operation o,togiveo a unique identifier (lines 11-
12). Before performing operation o, S
j
logs data nec-
essary to recover its state in case the failure occur-
rence (line 13). When the information necessary for
rollback-recovery is logged, the server performs the
client’s request (line 14) and adds it to its history of
performed writes (line 15).
When the read request from client C
i
is received
by server S
j
, the server checks first if, since the lat-
est checkpoint, it has performed any write operation
submitted by C
i
(line 17). If not, the previously
taken checkpoint possesses all information necessary
to guarantee RYW to C
i
and the new checkpoint does
not need to be taken. Otherwise, when at least one
write request issued by C
i
has been performed by
S
j
, the state of the server is checkpointed (line 19).
ICEIS 2006 - SOFTWARE AGENTS AND INTERNET COMPUTING
120

Checkpointing the server state causes clearing log
Log
S
j
and set CW
S
j
(lines 20-21).
After the failure, the server state is recovered ac-
cording to the information remembered in the latest
checkpoint Ckpt
S
j
of server S
j
(line 41) and in log
Log
S
j
(lines 42-50). Recovered operations are added
to the vectors V
S
j
(line 46) and CW
S
j
(line 49), as
well as to history H
S
j
(line 48).
During rollback-recovery procedure it is important
that logging of write operations takes place before
performing them. Such an order is crucial because,
if the operation is performed but not logged, it could
be lost in the case of failure. When failures happen
during the rollback-recovery procedure, the recovery
action is just prolonged, as the server must be rolled
back again and operations from the log have to be exe-
cuted from the beginning. The repeated recovery pro-
cedure works correctly, as the content of the check-
point and the log is not changed.
4 PROOF OF SAFETY
PROPERTY
The safety property asserts that clients access object
replicas maintained by servers according to RYW ses-
sion guarantee, regardless of servers’ failures.
For the sake of the proof simplicity we introduce
some auxiliary lemmas. First, we state that every
write operation issued by a client and performed by
a server is not lost in the rVsRYW protocol.
L
EMMA 1. Every write operation w issued by client
C
i
and performed by server S
j
that received w di-
rectly from client C
i
, is kept in checkpoint Ckpt
S
j
or
in log Log
S
j
.
Proof. Let us consider a write operation w issued by
client C
i
and obtained by server S
j
.
1. From the algorithm, server S
j
before performing
the request w, saves it in the stable storage by
adding it to log Log
S
j
(line 13). Because logging
of w takes place before performing it (line 14), then
even in the case of failure the operation w is not
lost, but remains in the log.
2. Log Log
S
j
is cleared after performing by S
j
the
read operation. However, according to the algo-
rithm, reads cause storing the information on writes
by checkpointing the server’s version vector V
S
j
and history H
S
j
in Ckpt
S
j
(line 19). The check-
point is taken before the operation of clearing log
Log
S
j
(line 20). Therefore, the server failure that
occurs after clearing the log does not affect safety
of the algorithm, because writes from the log are
already stored in the checkpoint.
Upon sending a request o to server S
j
at client C
i
1: W ← 0
2: if (not iswrite(o)) then
3: W ← W
C
i
4: end if
5: send o, W  to S
j
Upon receiving a request o, W  from client C
i
at server S
j
6: while V
S
j
≥ W do
7: wait()
8: end while
9: if iswrite(o) then
10: CW
S
j
← CW
S
j
∪ i
11: V
S
j
[j] ← V
S
j
[j]+1
12: timestamp o with V
S
j
13: Log
S
j
← Log
S
j
∪i, o, T (o)
14: perform o and store results in res
15: H
S
j
← H
S
j
⊕{o}
16: end if
17: if (not iswrite(o)) then
18: if i ∈ CW
S
j
then
19: Ckpt
S
j
←V
S
j
,H
H
j

20: Log
S
j
←∅
21: CW
S
j
←∅
22: end if
23: perform o and store results in res
24: end if
25: send
o, res, V
S
j
to C
i
Upon receiving a reply o, res, W  from server S
j
at client C
i
26: if iswrite(o) then
27: W
C
i
← max (W
C
i
,W)
28: end if
29: deliver res
Every ∆t at server S
j
30: foreach S
k
= S
j
do
31: send
S
j
,H
S
j
to S
k
32: end for
Upon receiving an update S
k
,H at server S
j
33: foreach w
i
∈ H do
34: if V
S
j
≥ T (w
i
) then
35: perform w
i
36: V
S
j
← max V
S
j
,T(w
i
)
37: H
S
j
← H
S
j
⊕{w
i
}
38: end if
39: end for
40: signal()
On rollback-recovery
41: V
S
j
,H
S
j
←Ckpt
S
j
42: vrecover ← 0
43: foreach o

j
∈ Log

S
j
do
44: choose i

,o

i
,T(o

i
) with minimal T (o

j
)
45: from Log

S
j
where T (o

j
) >V
S
j
46: V
S
j
[j] ← V
S
j
[j]+1
47: perform o

j
48: H
S
j
← H
S
j
⊕ o

j
49: CW
S
j
← CW
S
j
∪ i

50: vrecover ← T (o

i
)
51: end for
SAFETY OF CHECKPOINTING AND ROLLBACK-RECOVERY PROTOCOL FOR MOBILE SYSTEMS WITH RYW
SESSION GUARANTEE
121

3. After the checkpoint is taken, but before the log is
cleared (between lines 19 and 20) writes issued by
client C
i
and performed by server S
j
are stored in
both the checkpoint Ckpt
S
j
and the log Log
S
j
.
Hence, every write operation w before being per-
formed, but not yet checkpointed, is stored in the log
Log
S
j
(from 1). At the moment of clearing the log,
all operations from the log are already saved in the
checkpoint Ckpt
S
j
(from 2). There is a time, where
operations performed by S
j
are saved in both data
structures: the checkpoint and the log (from 3). Data
stored in the log and the checkpoint are kept in the
stable storage. As a result, even in the case of server
S
j
failure the write w received by S
j
directly from
client C
i
is not lost and is stored either in the log or in
the checkpoint, or in both these structures.
The checkpoint definition (Definition 4) leads us
to the observation, that all write operations issued
by client C
i
and performed by server S
j
, that have
been checkpointed in the latest checkpoint Ckpt
S
j
taken before the failure of S
j
, are recovered during
the rollback-recovery procedure.
In contrast to recovery of checkpointed operations
(line 41), the recovery of operations saved in the log is
not made atomically (lines 43-49). Therefore, there is
a possibility that server failure may occur in the mid-
dle of recovery procedure, when some logged opera-
tions have been recovered, but others have not. Thus,
the recovery of all logged operations is not obvious.
For that reason below, in Lemma 2, we prove that also
all operations logged in log Log
S
j
, which have been
performed after the moment of taking checkpoint but
before the failure of S
j
, are recovered during recovery
procedure.
L
EMMA 2. The rollback-recovery procedure recovers
all write operations issued by client C
i
and performed
by server S
j
that were logged in log Log
S
j
in the mo-
ment of server failure.
Proof. According to the algorithm, all write opera-
tions issued by client C
i
and performed by server S
j
are logged in log Log
S
j
before being performed (line
13).
Let us assume server S
j
fails. The rollback-
recovery procedure after recovering values V
S
j
and
H
S
j
from a checkpoint, recovers all operations (line
43) performed by S
j
before the failure occurred, but
after the checkpoint was taken. These operations are
recovered due to values remembered in the log (line
44 ) — from the log definition these are the issuing
client index, the operation and its timestamp. The
recovered operation updates version vector V
S
j
(line
46), it is performed by S
j
(line 47) and added to the
server’s S
j
history H
S
j
(line 48).
Assume now, that failures occur during the
rollback-recovery procedure. Due to such failures the
results of operations that have already been recovered
are lost again. However, since log Log
S
j
is cleared
only after the checkpoint is taken (line 20) and it is not
modified during the rollback-recovery procedure, the
log’s content is not changed. Hence, the recovery pro-
cedure can be started from the beginning without loss
of any operation issued by client C
i
and performed by
server S
j
after the moment of taking checkpoint.
To preserve RYW session guarantee, all write op-
erations performed by server S
j
have to be recov-
ered before new read operation is obtained from client
C
i
. Otherwise, there is a possibility that some writes
previously issued by C
i
are still not recovered and
the read operation cannot be performed according to
RYW.
L
EMMA 3. The server performs new read operation
issued by a client only after all writes performed be-
fore the failure are recovered.
Proof. By contradiction, let us assume that there is
write operation w performed by server S
j
before the
failure occurrence, that has not been recovered yet,
and that the server has performed a new read oper-
ation issued by client C
i
. According to underlying
VsSG protocol, for server S
j
that performs the new
read operation, the condition
V
S
j
≥ W
C
i
is fulfilled (lines 6-7).
Let us consider which actions are taken when a
write operation is issued by client C
i
and performed
by server S
j
.
On the server side, the receipt of the write operation
causes the update of vector V
S
j
in the following way:
V
s
j
[j] ← V
S
j
[j]+1and results in timestamping w
with the unique identifier (line 12). The server that
has performed write sends a reply that contains the
modified vector V
S
j
to the client.
At the client side, after the reply is received, vec-
tor W
C
i
is modified: W
C
i
← max (W, W
C
i
) . This
means that vector W
C
i
is updated at least at position
j: W
C
i
[j] ← max[j]+1.
If there is a write operation w performed by server
S
j
before the failure that has not been recovered yet,
then V
S
j
[j] <W
C
i
[j] , which follows from the order-
ing of recovered operations (line 44). This is a contra-
diction with V
S
j
≥ W
C
i
. Hence, the read operation
cannot be performed until all previous writes are re-
covered.
THEOREM 1. RYW session guarantee is preserved by
rVsRYW protocol for clients requesting it, even in the
presence of server failures.
ICEIS 2006 - SOFTWARE AGENTS AND INTERNET COMPUTING
122

Proof. Let us consider operations w and r, issued by
client C
i
, which requires RYW session guarantee. Let
read operation follows a write one in the client’s issue
order and let read be performed by server S
j
.
It has been proven that VsSG protocol pre-
serves RYW session guarantee, when none of
servers fails, i.e. for any client C
i
requir-
ing RYW and for any server S
j
the relation
∀C
i
∀S
j

w
C
i
r|
S
j
⇒ w
S
j
 r

holds. According to
Lemma 1, every write operation performed by server
S
j
is saved in the checkpoint or in the log. After
the server failure, all operations from the checkpoint
are recovered. Further, all operations performed be-
fore the failure occurred, but after the checkpoint was
taken, are also recovered (according to Lemma 2).
According to Lemma 3, all recovered operations are
applied before new ones.
Hence, for any client C
i
and any server S
j
,RYW
session guarantee is preserved by the rollback- recov-
ery and checkpointing rVsRYW algorithm.
5 CONCLUSIONS
The growing attention paid to mobile systems, re-
sults in their increased reliability requirements. Most
of rollback-recovery protocols which take into con-
sideration characteristics of mobile environment, pay
special attention to increasing efficiency of the proto-
col. The efficiency is usually increased through min-
imization of the amount of messages exchanged be-
tween mobile hosts during taking a checkpoint. On
the other hand, the protocol efficiency can also be in-
creased by data replication. However, in this approach
the problem of replica consistency during the recov-
ery process is faced and should be solved. Accord-
ing to our knowledge, although several studies have
examined the issues of checkpointing, logging and
rollback-recovery in mobile environment, none of the
existing solutions integrates these issues with the con-
sistency protocols. Especially client-centric consis-
tency models, regarding consistency from the client’s
point of view, have not been considered in the context
of rollback-recovery.
Therefore, this paper addresses a problem of inte-
grating the consistency management of mobile sys-
tems with the recovery mechanisms. We introduce
rVsRYW rollback-recovery protocol for distributed
mobile systems, which provides Read Your Writes
session guarantee. The proposed recovery protocol
is integrated with the underlying VsSG consistency
protocol. Additionally, the proof of safety property of
rVsRYW protocol is included.
The rVsRYW protocol, takes into account the se-
mantics of operations during the rollback-recovery
procedure. This results in checkpointing only results
of write operations. As a result, rVsRYW protocol
offers the ability to overcome the servers’ failures
and ensures RYW session guarantee, in the optimized
way.
REFERENCES
Alvasi, L. and Marzullo, K. (1998). Message logging: pes-
simistic, optimistic, causal and optimal. IEEE Trans.
Softw. Eng, 24(2):149–159.
Bernstein, P. A., Hadzilacos, V., and Goodman, N. (1987).
Concurrency Control and Recovery in Database Sys-
tems. Addison Wesley.
Duchamp, D., Feiner, S., and Jr, G. M. (1991). Software
technology for wireless mobile computing. IEEE Net-
work Magazine, pages 2–18.
Elmootazbellah, N., Elnozahy, Lorenzo, A., Wang, Y.-
M., and Johnson, D. (2002). A survey of rollback-
recovery protocols in message-passing systems. ACM
Computing Surveys, 34(3):375–408.
Elnozahy, E. and Zwaenepoel, W. (1992). Manetho: Trans-
parent rollback-recovery with low overhead, limited
rollback, and fast output commit. IEEE Transactions
on Computer, 41(5):526–531.
Guerraoui, R. and Rodrigues, L. (2004). Introduction to
distributed algorithms. Springer-Verlag.
Kobusi
´
nska, A., Libuda, M., Sobaniec, C., and Wawrzy-
niak, D. (2005). Version vector protocols implement-
ing session guarantees. Proc. of Int. Symp. on Cluster
Computing and the Grid (CCGrid 2005).
Pradhan, D., P.Krishna, and Vaidya, N. (1996). Recovery in
mobile environments: Design and trade-off analysis.
Proc. of the 26th International Symposium on Fault-
Tolerant Computing, pages 16–25.
Sergent, N., Dfago, X., and Schiper, A. (1999). Failure
detectors: Implementation issues and impact on con-
sensus performance. Technical Report SSC/1999/019,
cole Polytechnique Fdrale de Lausanne, Switzerland.
Sobaniec, C. (2005). Consistency Protocols of Session
Guarantees in Distributed Mobile Systems. PhD the-
sis, Institute of Computing Science, Poznan Univer-
sity of Technology.
Szychowiak, M. (2003). Replication of checkpoints in DSM
systems with read-write objects. PhD thesis, Institute
of Computing Science, Poznan University of Technol-
ogy.
Tanaka, K., Higaki, H., and Takizawa, M. (1998). Object-
based checkpoints in distributed systems. Journal of
computer system science and Engineering, 13(3):125–
131.
Terry, D. B., Demers, A. J., Petersen, K., Spreitzer, M.,
Theimer, M., and Welch, B. W. (1994). Session guar-
antees for weakly consistent replicated data. Proc. of
the Third Int. Conf. on Parallel and Distributed Infor-
mation Systems (PDIS 94), pages 140–149.
SAFETY OF CHECKPOINTING AND ROLLBACK-RECOVERY PROTOCOL FOR MOBILE SYSTEMS WITH RYW
SESSION GUARANTEE
123