TELKOM
NIKA Indonesia
n
Journal of
Electrical En
gineering
Vol.12, No.4, April 201
4, pp. 3247 ~ 3
2
5
2
DOI: http://dx.doi.org/10.11591/telkomni
ka.v12i4.4887
3247
Re
cei
v
ed Se
ptem
ber 3, 2013; Re
vi
sed
No
vem
ber 6,
2013; Accept
ed De
cem
b
e
r
11, 2013
A Multi-party Decision Hot-sta
ndby Model
Congd
ong L
v
*, Wei Ma,
Xiao
y
ong Li
Schoo
l of Com
puter an
d Infor
m
ation T
e
chno
log
y
, Bei
jin
g Ji
aoton
g Un
ivers
i
t
y
, Chi
n
a
*Corres
p
o
ndi
n
g
author, e-ma
i
l
: congd
on
g.lu
@gmai
l
.com
A
b
st
r
a
ct
The dual serv
er hot-st
andby
m
e
chanism
is often used
to
im
pr
ove the system
availability.
How
e
ver, in tr
aditi
ona
l d
ual s
e
rver h
o
t-stand
by mod
e
ls
, the
states of serv
ers are s
e
ld
o
m
deter
mi
ned
fr
o
m
the clie
nt
’
s
obs
ervatio
n
, and it
’
s
e
a
sy for the master
serv
er and the sl
ave
server to mak
e
w
r
ong decisi
o
ns
abo
ut the state
of eac
h oth
e
r, w
h
ich
may ca
u
s
e spl
i
t brai
n.
T
h
is
pa
per
pre
s
ents a
mu
lti-p
a
rty decis
ion
h
o
t-
standby
mod
e
l.
In this mod
e
l,
the master ser
v
er an
d
the sl
a
v
e server
deter
mi
ne th
e
state of
each other n
o
t
only fro
m
the
observ
a
tion
of thems
e
lves, b
u
t also fro
m
the observ
a
tio
n
of the client, w
h
ich hel
ps th
e
m
mak
e
correct
decisi
on to
mainta
in or ch
a
nge the s
e
rv
ic
e platfor
m
, so
as to ensure
the contin
uity
of
app
licati
on. Co
mp
are
d
w
i
th traditi
ona
l du
al s
e
rver hot
-stan
d
b
y mo
de
ls, the mod
e
l su
gg
es
ted in this pa
p
e
r
is mor
e
reas
on
abl
e bec
ause o
f
the invo
lve
m
e
n
t of the client
’s observati
on.
Ke
y
w
ords
:
hot
-standby, spl
i
t brai
n, avail
a
b
ili
ty, multi-party
decisi
o
n
Copy
right
©
2
014 In
stitu
t
e o
f
Ad
van
ced
En
g
i
n
eerin
g and
Scien
ce. All
rig
h
t
s reser
ve
d
.
1. Introduc
tion
The d
ual
se
rver hot
-sta
nd
by mechani
sm
is
a
com
m
on m
e
thod
to improve
servi
c
e
availability of
the system. VRRP [1] and
HSRP [2
] are
both cla
ssi
c
hot-sta
ndby p
r
otocols. Ma
n
y
vendors an
d
open
sou
r
ce
orga
nization
s also lau
n
che
d
co
rre
sp
ondi
ng hot-stan
d
b
y solution
s for
their o
w
n
pla
tform and
produ
cts, such
as
Linux
-HA
[3]. The ge
n
e
ral
prin
cipl
e
of hot-stand
by
mech
ani
sm i
s
that the
ma
ster
se
rver/d
evice a
nd th
e slave
se
rve
r
/device
dete
c
t and
judg
e
the
available
state of the othe
r thr
oug
h he
art beat proto
c
ol. Once the
slave serve
r
confirm
that
the
maste
r
serve
r
is un
availab
l
e, it will ta
ke
over
it
s fun
c
tions
and
pro
v
ide services for
client
s. T
he
resea
r
ch
of d
ual serve
r
ho
t-stand
by
me
cha
n
is
m
focu
se
s o
n
fault
detectio
n
, se
rvice
re
cove
ry,
and a
s
sura
nce betwe
en th
e maste
r
se
rv
er and the
sla
v
e serve
r
[3-5
].
The traditio
n
a
l
dual se
rver
hot-sta
ndby
mech
ani
sm
may cau
s
e th
e risk of Split
Brain [6],
[7]. The Spli
t Brain i
s
d
ue to th
e fa
ilure
of the
comm
uni
cati
on me
ch
ani
sm (o
r
hea
rtb
e
a
t
mech
ani
sm)
betwe
en the
maste
r
se
rve
r
and the
sl
a
v
e serve
r
. It
will ca
use the misjud
gme
n
t
betwe
en the
serve
r
s. The
n
, both t
hem
can
not co
nsistently prov
i
de services.
There are m
any
possibl
e cau
s
es for he
artb
eat mech
ani
sm fails, for
example, physi
cal line pro
b
le
ms or the fail
ure
of the heartb
eat softwa
r
e.
Fenci
ng and
Quorum me
cha
n
ism i
s
a
comm
on way to prevent split-
brain
[7, 8],
su
ch
as the
method
of u
s
ing
SC
SI re
serve
an
d Q
uoru
m
Daem
on, du
al st
ate
con
s
i
s
ten
c
y
synchro
n
ization [9], etc.
Ho
wever,
th
e
s
e m
e
thod
s
have ma
ny li
mitations. It
may
cau
s
e a ne
w single poi
nt of failure [10, 11]. In
addition, these me
thods a
r
e not
commo
n. It is
difficult to apply in the dua
l serve
r
hot-s
t
andby me
cha
n
ism of the n
e
twork eq
uip
m
ent.
In orde
r to overco
me or
mitigate the split-b
rai
n
risk of the tradi
tional dual server h
o
t-
stand
by me
chani
sm, we
pre
s
ent
a m
u
lti-pa
rt
y decision
hot-sta
ndby mo
del.
The m
u
lti-p
a
rty
deci
s
io
n me
chani
sm refe
rs that the m
a
ster
se
rver
and the
slav
e se
rver d
e
termin
e the true
availability status of ea
ch other not only rely
on their own observations, but also rely on the
client
s’ ob
se
rvations. Be
ca
use
the
se
rvice
s
a
r
e fo
r
th
e cli
ent, it is
reasona
ble to
use
the
client
's
observation
s as
a se
rver status
dete
r
mi
nation
fa
ctor.
It can effecti
v
ely avoid the limitations
and
one-sid
edn
ess of th
e bilate
ral d
e
ci
sio
n
mech
ani
sm
t
o
combin
e th
e ma
ster se
rv
er’s ob
se
rvations
and the
slave se
rver’
s
o
b
se
rvati
on to
gether
with the clie
nt ob
se
rvatio
ns i
n
the multi-pa
rty
deci
s
io
n mechani
sm. In ad
dition, the du
al serve
r
hot
-stand
by mod
e
l prop
osed i
n
this pap
er
no
t
only can be u
s
ed to the hot
-stan
dby me
chani
sm of
ho
st and data
b
a
s
e services,
but also
can
be
use
d
for the h
o
t-stan
dby m
e
ch
ani
sm of netwo
rk d
e
vices.
Contri
bution
s
of this paper
inclu
de:
Evaluation Warning : The document was created with Spire.PDF for Python.
ISSN: 23
02-4
046
TELKOM
NI
KA
Vol. 12, No. 4, April 2014: 3247 – 3
252
3248
1) Introd
uce the clie
nt’s ob
servat
io
ns of
the servi
c
e st
atus an
d us
e
it as an important facto
r
for
the master server and the sa
lve server to determine the
availability of each other;
2) Comp
rehe
nsively analy
z
e multiple
o
b
se
rvation
s
o
f
the master
serve
r
, the sl
ave se
rver a
nd
the client to p
r
ovide the ba
sis to
jud
ge the state of sy
stem services;
3) Pre
s
ent a
multi-pa
rty decisi
on hot-sta
ndby
model a
nd analy
z
e its versatility and se
curity.
2.
A Multi-p
a
rty
Decision Ho
t-s
tan
d
b
y
Model
The
servi
c
e
provide
s
fo
r the cli
ent. Ho
wever,
in th
e
traditional
d
ual serve
r
ho
t-stand
by
model,
the cli
ent's
o
b
serva
t
ions weren’t con
s
id
ere
d
to
determi
ne th
e se
rvice’
s a
v
ailability [12
-
14]. The
mult
i-pa
rty de
cisi
on h
o
t-sta
n
d
b
y model
co
nsi
s
ts
of thre
e impo
rtant d
e
ci
sion
s e
n
tities:
the maste
r
se
rver, the salv
e serve
r
an
d the clie
nt, sho
w
n in Figu
re
1:
Client
Cli
e
nt
...
H
e
a
r
tbeat Line
Master Serv
er
Slav
e Server
Figure 1. The Structu
r
e of
the Mu
lti-part
y
Deci
sion
Hot-stan
dby M
odel
For the
part
i
cipatin
g enti
t
ies of the
st
ru
cture in
Figure 1, we u
s
e n
u
m
ber
N
(=m*
22
+s*21
+
c*
20
)
to re
pre
s
ent one
entity’s
com
m
unication st
ate
with
the others, whe
r
e
m
stand
s for th
e
comm
uni
cati
on state
with
the maste
r
se
rver, s
stan
ds for the comm
unication
state
with the
slav
e se
rver,
c
stand
s for th
e com
m
uni
cation state
with the ma
ster
se
rver.
The
comm
uni
cati
on relatio
n
sh
ip
bet
wee
n
entities
i
s
bi
dire
ctional,
that is,
if th
e entity A
can
comm
uni
cate
with entity B, then entity B can
co
mmuni
cate to e
n
tity A. Conv
ersel
y
, if the entity A
can
not com
m
unicate with entity B, then the entit
y B
can
not com
m
unicate with the entity A. T
he
values
of m, s, and
c a
r
e
Boolean. T
h
e
value 0 in
dicates n
o
com
m
unication b
e
twee
n them.
The
value 1 i
ndi
cates th
at the
y
can
comm
unicate
with
each oth
e
r. F
o
r e
a
ch e
n
tity, assume th
at it
alway
s
co
uld
comm
uni
cati
on with itself, and the value
is 1.
The
m
odel
in
Figu
re 1 sh
o
w
s
that all cli
ents ar
e a
pa
rticipatin
g e
n
tity. If there i
s
a cli
ent
who
ca
n co
mmuni
cate
with the m
a
ster
se
rver
or the
slave
se
rver, the
n
all cli
ents can
comm
uni
cate
with the master se
rver
enti
t
y or the slave serve
r
entit
y.
For conveni
e
n
ce, we u
s
e
M represent
s the
ma
ster serve
r
com
m
unication
s form, S
rep
r
e
s
ent
s th
e slave
se
rv
er
comm
uni
cation form
a
nd C re
pre
s
e
n
ts the
clie
nt comm
uni
cati
on
form.
In the mo
del
of Figu
re 1,
e
a
ch
entity ma
y hav
e fou
r
communi
catio
n
state
s
with t
he oth
e
r
entities. Fo
r the ma
ster
se
rver,
the
r
e a
r
e 7, 6, 5 an
d
4, whe
r
e 7
m
ean
s it ca
n communi
cate
with
others; 6
indi
cate
s that it
can o
n
ly com
m
unicate
with
the slave
server, but ca
nnot comm
un
icate
with the
cli
ent
; 5 indi
cate
s t
hat it can
onl
y comm
uni
ca
te with th
e
cli
ent, but
can
n
o
t co
mmuni
cate
with the slave
serve
r
; 4 me
ans that
it ca
nnot com
m
un
icate with oth
e
rs:
Evaluation Warning : The document was created with Spire.PDF for Python.
TELKOM
NIKA
ISSN:
2302-4
046
A Multi-part
y
De
cisi
on Hot-stand
by Mo
d
e
l (Co
ngd
ong
Lv)
3249
Table 1. Co
m
m
unication States bet
wee
n
Entities
Entity
Communication
State
Interpre
tation
Master
Server
7
Can communicate w
i
th o
t
hers.
6
Onl
y
can comm
unicate w
i
th t
h
e
slave server, but cannot comm
unicate w
i
th t
h
e
client.
5
Onl
y
can communicate w
i
th the client,
but cann
ot communicate w
i
th the slave
ser
v
er
.
4
Cannot communi
cate w
i
th ot
hers.
Slave
Server
7
Can communicate w
i
th o
t
hers.
6
Onl
y
can comm
unicate
w
i
th the
master server,
b
u
t cannot comm
unicate
w
i
th the
client.
3
Onl
y
can comm
unicate w
i
th the
client, but canno
t communicate
w
i
th the master
ser
v
er
.
2
Cannot communi
cate w
i
th ot
hers.
Client
7
Can communicate w
i
th o
t
hers.
5
Onl
y
can comm
unicate
w
i
th the
master server,
b
u
t cannot comm
unicate
w
i
th the
slave server.
3
Onl
y
can comm
unicate w
i
th the
slave master, but cannot communicate w
i
th the
master
ser
v
er
.
1
Cannot communi
cate w
i
th ot
hers.
Becau
s
e the
comm
uni
cati
on is bidirecti
onal, it isn’t possibl
e to randomly com
b
ine the
comm
uni
cati
on state of t
he thre
e pa
rticipatin
g ent
ities in Ta
ble
1, for exampl
e, M=7 an
d
C=3
can
not o
c
cu
r
simultan
eou
sl
y becau
se
M
=
7
re
pre
s
e
n
ts that
the
ma
ster serve
r
can
comm
uni
cate
with oth
e
rs, b
u
t C=3 in
dica
tes that th
e cl
ient c
annot communi
cate with
the ma
ster se
rver,
tha
t
is
the ma
ster
server cannot
com
m
uni
cat
e
with th
e
cl
ient. They a
r
e contra
dicto
r
y. Rem
o
ve
all
confli
cting
co
mbination,
Ta
ble 2 li
sts all
possibl
e com
b
ination
s
of t
he
commu
nication
state of
the
three pa
rtici
p
ating entities.
And it gives the interp
retati
on
.
Table 2.
All Possi
ble Co
mbination
s
of
the Commu
n
i
cation State and the Interpretation
M
S
C
Interpre
tation
7 7
7
Normal
7 6
5
The master se
rver can communicate
w
i
th the slave se
rver; The sla
v
e server cannot
communicate w
i
t
h
the
client.
6 7
3
The master se
rver can communicate
w
i
th the slave se
rver; The
ma
ster server cann
ot communicate w
i
th
the client.
6 6
1
The master se
rver can communicate
w
i
th the slave serv
er; Neithe
r
the master serve
r
nor th
e slave server
can communicate w
i
th t
he client.
5 3
7
The master se
rver cannot comm
unicate w
i
th the
slave
server; The
slave server can communicate w
i
th the
client.
5 2
5
The master se
rver can communicate
w
i
th the clien
t; Neither the m
a
ster server nor
th
e client can
communicate w
i
t
h
the slave server.
4 3
3
The slave server
can communicate w
i
th t
he client; Neit
her the slave server nor th
e client can communicate
w
i
th the
master s
e
rver.
4
2
1
The
y
can
not com
m
unicate w
i
th ea
ch other.
Here we give
some d
e
finitions a
bout the
model in Fig
u
re 1.
Definition
1
(i
nformatio
n
e
x
chan
ge
rule
s) entit
ie
s
in
the
du
al se
rver hot-stand
b
y
model
based on mul
t
i-party de
cisi
on mechani
sm shoul
d follow the follo
wi
ng rule
s:
1) Each entit
y save an int
e
rnal
data structur
e T. T =
MSC, whe
r
e
M, S, C repre
s
ent the
comm
uni
cati
on state
of the ma
ster
se
rver, the co
m
m
unication
state of the sl
a
v
e se
rver a
n
d
the
comm
uni
cati
on state of the client. After sy
stem initiali
zation, T is
set to 000.
2) Every time t, each entity generates M
,
S or C with comm
uni
cati
on state a
c
co
rding to
their netwo
rk con
n
e
c
tion st
atus and
up
d
a
tes
to
T.
T
h
en h
e
sen
d
s i
t
to the
other
two e
n
tities.
For
instan
ce, the
maste
r
se
rv
er ge
nerates the co
mm
u
n
icatio
n state
M, then up
dates to M i
n
T
store
d
by his own, and fi
nally, send
s i
t
to the
slave serve
r
an
d
the client. The slave
server
gene
rate
s th
e com
m
uni
ca
tion state S, then up
date
s
to S in T stored
by his
own, a
nd fin
a
lly,
Evaluation Warning : The document was created with Spire.PDF for Python.
ISSN: 23
02-4
046
TELKOM
NI
KA
Vol. 12, No. 4, April 2014: 3247 – 3
252
3250
sen
d
s it to th
e ma
ster
se
rver an
d the
clien
t.
The clie
nt
gene
rate
s the
co
mmuni
cation state C,
then u
pdate
s
to C i
n
T
stored by hi
s
own
,
and fin
a
lly
, send
s it to the
maste
r
serve
r
and
the
slav
e
serv
e
r
.
3) After ea
ch
entity receive
s
the commu
nicati
o
n
state
from other e
n
tities, he will
update
it to T. Fo
r
example, th
e m
a
ster
serve
r
receive
s
S
fro
m
the
slave
server, it
will
d
i
rectly
updat
e
S
in T store
d
by his own.
4) If an entity has not recei
v
ed the com
m
unication st
ate of other e
n
tities within t
he time
period e, it will set the correspon
ding it
em to 0. For
example, if
the master
server received
no
comm
uni
cati
on state from
the slave server within the
time period e, it will set S i
n
T stored by his
own to 0.
Table 3. The
Conte
n
ts of e
a
ch Entity’s
T
Form un
der
each Com
m
u
n
icatio
n State
M
S
C
Master Server
T
Slave Server T
Client T
7 7
7
777
777
777
7 6
5
765
760
706
6 7
3
670
673
073
6 6
1
660
660
001
5 3
7
507
037
537
5 2
5
505
020
505
4 3
3
400
033
033
4 2
1
400
020
001
As sho
w
n i
n
Table
3, for
each e
n
tity, in ad
dition to
no
comm
uni
cation
with ot
her t
w
o
entities
(the
shade
d ent
rie
s
in Tabl
e 3
)
, i
t
s value
of
T
i
s
con
s
iste
nt with
the com
m
unication st
ate
MSC of the system, which
means
that even if the communi
cation
state kn
own
by each entit
y is
not consistent with the real communication
state
of
the
system,
it will
not af
fect its
properly
unde
rsta
ndin
g
about the real comm
uni
cation state
of
the system. In fact, if
an entity has no
comm
uni
cati
on with othe
r entities, then the ot
her entities’ real
commu
nication state ha
s no
meanin
g
to it. For exampl
e, in the last two ro
ws
in
Table 3, T of the master
server
rep
r
e
s
e
n
ts
that it has n
o
com
m
uni
ca
tion with the
slave
serv
e
r
and the
clie
nt. So rega
rd
less of existi
ng
comm
uni
cati
on bet
wee
n
t
he sl
ave
serv
er a
nd the
cli
ent (the l
a
st
row b
u
t one
i
n
Tabl
e 3
)
or no
comm
uni
cati
on between t
hem (the l
a
st
row in T
able
3), the mast
er serve
r
kn
o
w
s that it cou
l
dn’t
provide
se
rvice
s
any more
.
Definition
2 (servi
ce
switching rule
s) switchi
ng rule
s
in
the
mult
i-pa
rty
de
cisi
on
h
o
t-
stand
by mod
e
l follow the followin
g
rul
e
s:
1
)
W
h
en
T sto
r
e
d
in
th
e
ma
s
t
er
s
e
r
v
er
is
67
0
o
r
4
00,
the
m
a
st
er se
rver pro
v
ides no
servi
c
e, or
co
ntinue
s to pro
v
ide servi
c
e
s
.
2) When T
stored i
n
the sl
ave se
rver is
673 o
r
033, the slave
se
rver
takes ove
r
servi
c
e
s
from the ma
ster se
rver, o
r
contin
ue
s an
alternate
se
rvice.
As sho
w
n in
Table 3, wh
e
n
T store
d
in
the
master
server i
s
660,
T store
d
in the slave
serve
r
is al
so
660. In this
ca
se, the ma
ster se
rve
r
has no commu
nicatio
n
with the slave se
rver.
So they are a
ll unavailable
to the client, and re
qui
re
m
ent to switch the se
rver d
o
e
s
not exist. In a
real
syste
m
, in this ca
se, t
he ma
ste
r
se
rver
and
slav
e serve
r
sho
u
ld
send
ala
r
m inform
ation
to
alert man
age
rs that the net
work may ma
lfunction.
3. Securit
y
Analy
s
is
Analysis met
hod
s in other wo
rks [15] can be used for refe
re
n
c
e.
To determi
ne
the dual
serve
r
h
o
t-st
andby mo
del
whi
c
h ba
se
d
on multi-p
a
rt
y deci
s
ion m
e
ch
ani
sm is t
o
wo
rk
pro
p
e
r
ly,
we m
u
st ve
rif
y
wheth
e
r th
e
r
e i
s
situation
that t
he
m
a
st
er se
rver and
the slave se
rver
comp
ete
t
o
provide
se
rvice
s
. In other words,
whe
n
the slav
e
serve
r
ta
ke
s over the
service, the ma
ste
r
serve
r
i
s
also providing
servi
c
e
s
. If there
is
com
petition for p
r
oviding
serv
ice
s
, it can
be
con
s
id
ere
d
that the model exist “split-brain".
Evaluation Warning : The document was created with Spire.PDF for Python.
TELKOM
NIKA
ISSN:
2302-4
046
A Multi-part
y
De
cisi
on Hot-stand
by Mo
d
e
l (Co
ngd
ong
Lv)
3251
Based
on
the
se
rvice
switching
rule
s
de
fined
in
defini
t
ion 2, o
n
ly when T
sto
r
e
d
in the
slave
se
rver i
s
67
3 o
r
03
3,
the sl
ave
se
rver is t
r
ying t
o
take
over
providing servi
c
es.
At
the sa
me
time, the T stored i
n
the m
a
ster
se
rver i
s
670
or 4
00.
It is the cond
ition for the m
a
ster
se
rver
out
of providing
servi
c
e
s
. The
multi-party d
e
ci
sion
hot
-st
andby mod
e
l
avoids "split
-brain” b
e
twe
e
n
the maste
r
se
rver an
d slav
e serve
r
.
From the
on
e de
scribe
d
can
be
see
n
, it is pr
e
c
i
s
el
y beca
u
se th
e clie
nt's p
a
rt
icipatio
n,
whi
c
h ma
ke
s prima
r
y and
se
con
dary
servers d
e
termine the
sta
t
e of each o
t
her have
m
o
re
eviden
ce, an
d thus th
e st
ate of ea
ch
other to
m
a
ke the ri
ght ju
dgment
s. Cli
ent as
a service
obje
c
t, whi
c
h
the maste
r
a
nd sl
ave se
rv
er state j
udg
e ha
s two eff
e
cts: Fi
rst, it establi
s
h
e
s t
he
prin
ciple of
majority judg
ment advant
age
s, thus
breaki
ng the tradition of
the master an
d slave
serve
r
s as a result of an eq
ual numb
e
r of
judgment
s
in
each
state there is a
confli
ct cont
roversy.
Secon
d
ly, the cli
ent is no
t mainly p
r
ovided from
th
e
se
rver ba
se
d on
the ju
d
g
ment, when
the
client triplet T
is 004 when
the prima
r
y serve
r
cann
ot provide
servi
c
e
s
to client
s, so even if the
state judg
e a
ppea
rs
cont
ra
dictory to ea
ch other
will n
o
t bring mo
re
service avail
ability issu
es.
4. Implementation
The multi
-
pa
rty deci
s
io
n
hot-stand
by model
ha
s no te
chni
cal ob
stacl
e
s in the
reali
z
ation. T
h
is a
p
p
r
oa
ch
in this pap
er is b
o
th
to
ru
n age
nt software i
n
the
ma
ster
se
rver a
nd
the slave se
rvers. The
n
select a num
b
e
r of c
lient
s, and al
so inst
all and ru
n a
gent software
on
client
s. This a
gent software
supp
orts t
he
rule
s in defini
t
ion 1 and def
inition 2:
1) Entities
sen
d
hello
packet
s
to
each othe
r
via IP multica
s
t and
re
port the
comm
uni
cati
on statu
s
N;
2) Entities ma
intain T = MSC based on the
comm
uni
cation status o
f
themselves
and the
received hell
o
packet.
In order to
ensure
switchi
ng’
s real-ti
m
e ability and reli
ability of the com
m
unication
status, all enti
t
ies nee
d to maintain several time vari
able
s
, inclu
d
ing:
1) T
he
hello
pa
cket’s i
n
terval time
is he
llo
-time,
whi
c
h
co
rrespond
s to
the
time t i
n
definition 1. Every time t, e
a
ch e
n
tity sends a
h
e
llo p
a
cket to repo
rt its communi
cation
status;
2) Element
s’
expiration time in T is e
x
pire-time, which
corre
s
p
ond
s to the time e in
definition
1. If an
entity is
n
o
t re
ceived
communi
cati
o
n
state
from
others
with
in expire
-time,
then
set the
relate
d ele
m
ent to
0 in
T. Fo
r i
n
stan
ce,
wi
thin
the
expire
-ti
m
e, if the
ma
ster serve
r
d
oes
not receive any hello packets from the client, then
the C in T is set to 0. Taking into account the
netwo
rk may
be del
ayed,
the expire
-ti
m
e mu
st be
greate
r
tha
n
the hello
-time
,
gene
rally set at
leas
t that the former is
the latter triple.
Since all
clie
nts a
r
e a
wh
ole pa
rticip
ating ent
ity, so
for any
clie
nt, the mann
er which
gene
rate
s
cli
ent commu
ni
cation
state
C i
s
different
from the
oth
e
r
two e
n
tities.
All cli
ents se
t up
the co
mmuni
cate
state form of them
sel
v
es a
c
co
rdin
g
to
their co
mmuni
cation states and
ot
her
client
s’ hell
o
packet
s
, for
e
x
ample if a
cli
ent doe
s not comm
uni
cate
with
the slav
e
se
rver, but as
long a
s
it re
ceives any o
n
e
client h
e
llo
packet
s
It ca
n com
m
uni
ca
te with the sl
ave se
rver, it will
update th
e
communi
catio
n
state
N=N+1*2
1
. Simil
a
rly, for the
maste
r
serve
r
an
d the
sl
ave
serve
r
, a
s
lon
g
a
s
o
n
e
of th
em
can
com
m
unicate
with
the
client, th
en u
pdate
the
co
mmuni
cati
on
state N=N+1*
20.
Also, the mo
del should t
r
y to avoid the
probl
em
whe
n
the clie
nt is off line at the sam
e
time. If all clients a
r
e
shut
down, then b
o
th the ma
ste
r
server and t
he sl
ave serv
er will thi
n
k t
hat
they can
not
comm
uni
cate
with the
clie
nts. To
avoid
this p
r
obl
em
, when
sele
ct the clie
nt, we
sho
u
ld pay at
tention to the
followin
g
: 1)
Select t
he
a
p
p
rop
r
iate nu
mber of
clie
nts;
2) Confi
r
m the
client doe
s n
o
t simultane
o
u
sly offline or shut dow
n; 3) Try to ensure that these client
s are
not
con
n
e
c
t
ed wi
t
h
t
he same
net
wo
rk a
c
ce
ss d
e
v
i
ce
at the sam
e
time
, to avoid network eq
uipm
ent
failure causes all c
lients while offline.
5.
Conclu
sion and Futu
r
e
w
o
r
k
The multi-party decisio
n h
o
t-st
an
dby m
odel can ove
r
come th
e po
ssible
split brai
n in the
traditional
hot
-stan
dby sy
stem, and its i
m
pleme
n
tati
o
n
is not com
p
licate
d
, and
can b
e
flexible
config
ure
d
. It
doe
sn’t req
u
ire cha
ngin
g
the system plat
form and a
ppl
ication
s
.
Future
works includ
e whe
n
how ma
ny client
s inclu
d
ed in the me
cha
n
ism, the
model is
best. Also, How to ch
oo
se
the clients m
a
y be a good
work.
Evaluation Warning : The document was created with Spire.PDF for Python.
ISSN: 23
02-4
046
TELKOM
NI
KA
Vol. 12, No. 4, April 2014: 3247 – 3
252
3252
Referen
ces
[1]
Knig
ht S, W
eaver D, W
h
ippl
e
D, et
al. Virtual router red
u
n
d
anc
y protoc
ol.
RFC23
3
8
. 1998.
[2]
Li D, Morton P, Li T, et al. Cisco
hot stand
b
y
router pr
otoc
ol (HSRP).
199
8.
[3]
Z
hong C, Z
h
a
ng L, Li H, et al.
Researc
h
and Impl
ementatio
n of
Dual-S
erver Hot
-
Standby o
f
Confi
gurati
on Softw
are
. Intell
ige
n
t Co
ntrol a
nd Aut
o
matio
n
. W
C
ICA 200
6.
T
he Sixth W
o
rld C
ongr
es
s
on
.
200
6; 2: 61
20-6
123.
[4]
Che
n
C
H
, T
i
ng Y, L
u
W
B,
et al
. Recov
e
r
y
mechanis
m
design
fo
r
hot standby c
o
mputer system
.
S
y
stems, Man
and C
y
b
e
rn
etic
s,
2003. IEEE Internati
o
n
a
l Co
nferenc
e on. IEEE. 2003; 3: 3
027-
303
1.
[5]
Nakam
u
ra S, Nakay
a
ma K, Nakaga
w
a
T
.
Optima
l back
u
p interva
l
of da
tabase
by incr
ementa
l
back
u
p
met
h
od
. Indus
trial Engi
ne
eri
ng an
d Engi
n
eeri
ng
Man
a
g
e
ment. IEEM 2009. IEEE Internation
a
l
Confer
ence on
.
2009; 21
8-22
2.
[6]
Han Y. An inte
grated h
i
g
h
av
aila
bi
lit
y
c
o
mp
uting p
l
atform.
Electron
ic Libr
ary
. 2005; 2
3
(6
): 632-64
0.
[7]
Coul
our
is G,
Doll
imore J, Kind
berg T
.
Distr
ibut
ed S
ystems: Conce
p
ts and Des
i
gn Editi
on 3.
Paragr
aph
. 2
0
01; 15: 04-
04.
[8]
Yang
X, W
ang
Y, Liu Y. Desi
gn an
d impl
em
entatio
n of dua
l-server
hot-sta
ndb
y s
y
stem for real-ti
m
e
datab
ase.
Jisu
anji Go
ngc
hen
gyuYi
ngyo
ng (
C
o
m
p
u
ter Engi
neer
ing a
nd Ap
plicati
ons)
. 20
1
2
; 48(29).
[9]
Kam
y
od C, N
i
e
l
sen R
H
, Prasa
d
NR, et al.
R
e
silie
nce i
n
IMS: End-to-e
nd re
l
i
abi
lity a
nalys
is
via Markov
Reward Models
. W
i
reless
Person
al M
u
lt
imedi
a C
o
mm
unic
a
tions
(W
PMC). 15th I
n
ternati
o
n
a
l
S
y
mposium on.
2012; 564-
56
8.
[10]
Z
hou G, Z
h
ao
H, Guo W
.
Saf
e
ty req
u
ire
m
en
ts ana
lysis
an
d p
e
rfor
manc
e
verific
a
tion
of
hot stan
d
b
y
system
us
ing color
ed Petri-
net
. Industrial El
e
c
tronics a
nd A
pplic
at
io
ns (ICIEA), 8th IEEE Confer
enc
e
on
.
201
3; 656-
661.
[11]
Li MJ, Diao Y, Z
hang Y. Des
i
gn
a
nd imp
l
e
m
entatio
n of gas disaster
e
a
r
l
y
-
w
a
rn
in
g s
y
st
em base
d
o
n
hot-stand
b
y
.
G
ongk
ua
ng Z
i
do
ngh
ua-In
dustry
and Min
e
Auto
mati
on
. 201
3; 39(5): 19-
23.
[12]
Mizutan
i
K, T
a
keshita
H, Ishi
i
K, et al. E
x
p
e
r
imental
val
i
d
a
tion
of
effect of
the p
o
w
e
r-s
av
ing sta
n
d
b
y
mode o
n
the
backup p
a
th.
OptoElectroni
cs and Co
mmu
n
ic
ations C
onfere
n
ce h
e
l
d
jointly w
i
t
h
Internatio
na
l C
onfere
n
ce o
n
Photon
ics in Sw
itching (OECC/
PS)
. 2013; 1-2.
[13]
Su H, Z
h
ang
Y. Distribut
i
o
n
grid f
ault
locati
on
app
l
y
in
g tr
ansi
ent zer
o
-m
ode
curre
nt.
TELKOMNIKA
Indon
esi
an Jou
r
nal of Electric
al Eng
i
ne
eri
n
g
.
2012; 1
0
(5): 8
83-8
90.
[14]
Li H,
Le
i Z
.
Rese
arch
on
Infrared
Sp
ecia
l F
a
cu
la V
i
e
w
Meas
ureme
n
t Metho
d
B
a
se
d o
n
Ima
g
e
Processi
ng T
e
chno
log
y
.
T
E
L
K
OMNIKA Indones
ian J
our
n
a
l of Electric
al
Engi
neer
in
g
. 201
2; 10(6)
:
142
2-14
29.
[15]
Samosir AS, Sutikno T
,
Yatim AHM. Dy
namic
Evol
ution
Control for F
uel C
e
ll D
C
-D
C Conv
erte
r
.
T
E
LKOMNIKA Indon
esi
an Jou
r
nal of Electric
al Eng
i
ne
eri
n
g
.
2011; 9: 18
3-1
90.
Evaluation Warning : The document was created with Spire.PDF for Python.