Yeah, actually I have no doubts about Paxos protocol itself but rather the
state machine implementation part
(as described in Paxos made simple,section 3) where there could be multiple
Paxos instances.
shouldn't the Paxos instance execution be serialized in order to make the
state machine abstraction useful/friendly
for the real world use? if one paxo instance fails application will be
notified so
that corresponding actions could be taken(retry,rollback,notify
client...etc), instead of blindly continuing and
getting unpredictable results later on. Actually in the Google Chubby case,
the database changelog is being streamed
into the Paxos cluster,how can they afford to lose some of the logs without
breaking the database integrity?
Did I miss something?

On the other hand, I think adopting the FIFO based protocol is a very smart
engineering decision.
It makes the whole thing less complicated and is also more powerful.
E.g. it saves you guys the efforts to invent another language/compiler(like
the Google ppl does).

Just curious, giving how persuasive the TCP stack is deployed today, why the
community still need to stick to the asynchronous system assumption? Just
because TCP sounds
uncool than asynchronous system on paper? hehe..



Reply via email to