Fwd: [p2p-hackers] lockstep synchronization protocol problem

[coderman]

---------- Forwarded message ----------
From: UE=x <jinz at mail.ustc.edu.cn>
Date: Mar 28, 2006 2:00 AM
Subject: Re: [p2p-hackers] lockstep synchronization protocol problem
To: coderman at gmail.com


can you introduce some papers to read about what you have said?I can't get your
meaning,but thank you.how is it related to the synchronization problem?


i am about to go offline for the night; here are a few off the top of
my head that are relevant.  i can post more later this week and others
on this list will likely have input.

group key distribution:
Efficient Self-Healing Group Key Distribution with Revocation Capability (2003)
http://citeseer.ist.psu.edu/623802.html

group reputation / trust metrics:
www.levien.com/thesis/compact.pdf

quorums and usability are more complicated and i don't have any links off hand.

best regards,

P.S.  please reply with any additional research / results if you
encounter them...




TZDz5D at 4PEVPTx>-La5=:
>From: coderman <coderman at gmail.com>
>Reply-To:
>To: "UE=x" <jinz at mail.ustc.edu.cn>,
  "Peer-to-peer development." <p2p-hackers at zgp.org>
>Subject: Re: [p2p-hackers] lockstep synchronization protocol problem
>Date:Tue, 28 Mar 2006 01:49:17 -0800
>
>On 3/28/06, UE=x <jinz at mail.ustc.edu.cn> wrote:
>> I'm doing research about synchronization problem in P2P system,and the basic
>> synchronization protocol is the lockstep protocol,and it use rounds to
synchronize
>> all the peer's movements,the problem is lockstep only synchronize peer's
>> movements?what about the event created by all the peers?can it use rounds to
>> synchronize them?and how to ?
>
>look at using a quorum based key distribution and agreement protocol
>(where quorum == a specific subset of group key management) with
>regular attestation / rekeying via trusted and strongly authenticated
>mechanisms.  session timeout (for failure / lack of consensus /
>malicious attack) should be detected within an appropriate time frame
>for the user to respond securely.  (i tend to think 60 seconds is an
>acceptable window)
>
>doing this in a user friendly manner is very difficult and probably
>the reason prior work in this domain is scarce.