Fwd: [p2p-hackers] lockstep synchronization protocol problem
---------- Forwarded message ---------- From: UE=x <jinz@mail.ustc.edu.cn> Date: Mar 28, 2006 2:00 AM Subject: Re: [p2p-hackers] lockstep synchronization protocol problem To: coderman@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@4PEVPTx>-La5=:
From: coderman <coderman@gmail.com> Reply-To: To: "UE=x" <jinz@mail.ustc.edu.cn>, "Peer-to-peer development." <p2p-hackers@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@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.
participants (1)
-
coderman