Hi Henry, Actually, I'm currently working on a research project. Basically, we're interested in the feasibility of a decentralized location-based services. All commercially available mobile location-based services (including social networks too) currently have a "central" server that stores all of the information of users, our main motivation is the security/privacy implications of this.
Our approach is to still have maybe some infrastructure but only have limited role (we definitely don't want the the servers to store user's personal information). -Harold --- On Thu, 6/25/09, Henry Robinson <he...@cloudera.com> wrote: > From: Henry Robinson <he...@cloudera.com> > Subject: Re: General Question about Zookeeper > To: zookeeper-user@hadoop.apache.org > Date: Thursday, June 25, 2009, 2:40 PM > What else do you want to use ZK for - > just leader election? It doesn't > require so much a centralised server (which implies kind of > a single point > of failure) as a small amount of fixed infrastructure. If > you have a highly > dynamic network - an ad-hoc network like a social net - ZK > will likely not > be appropriate. There are leader election algorithms that > work better in > totally ad-hoc networks, and other co-ordination models > that are better > suited. In particular, you may not want persistence in the > sense that later > instances of a consensus algorithm might not need to see > the results of > previous ones, removing the need to keep logs > synchronised. > > However, if you have five or so servers that you can > dedicate to > coordination, ZooKeeper should work very well. I'm really > curious about your > use case - is there more you can explain? > > Henry > > On Thu, Jun 25, 2009 at 7:16 PM, Harold Lim <rold...@yahoo.com> > wrote: > > > > > Hi Gustavo, > > > > Actually, in my case, we have a fully decentralized > service. Something like > > where you have users in a social network. Originally, > we were thinking of > > using a distributed consensus algorithm (e.g., Paxos) > to perform some > > functionalities (e.g., leader election). > > > > Then, I read about ZooKeeper and was thinking of using > ZooKeeper for leader > > election instead. However, that means that we're > introducing a "central" > > server/service to the architecture. > > > > Currently, I'm just thinking of some of the original > functionalities and > > how much of these functionalities I can offload to > ZooKeeper, without > > breaking the original privacy/security motivation. > > > > > > -Harold > > > > > > > > > > --- On Thu, 6/25/09, Gustavo Niemeyer <gust...@niemeyer.net> > wrote: > > > > > From: Gustavo Niemeyer <gust...@niemeyer.net> > > > Subject: Re: General Question about Zookeeper > > > To: zookeeper-user@hadoop.apache.org > > > Date: Thursday, June 25, 2009, 1:59 PM > > > Hey Harold, > > > > > > > I am interested in a security aspect of > zookeeper, > > > where the clients and the servers don't > necessarily belong > > > to the same "group". If a client creates a znode > in the > > > zookeeper? Can the person, who owns the zookeeper > server, > > > simply look at its filesystem and read the data > > > (out-of-band, not using a client, simply browsing > the file > > > system of the machine hosting the zookeeper > server)? > > > > > > Yes, absolutely. You could certainly > encrypt the data > > > that goes > > > through the ZooKeeper server, but since ZooKeeper > is > > > supposed to be > > > doing coordination work, I think that if you > don't trust > > > the server, > > > the whole situation might get a bit > awkward. I'm > > > curious about your > > > use case, since I'm pondering about doing > something where > > > clients > > > don't necessarily trust other clients or machines > in the > > > same network > > > (or even different users in the same machine), > thus might > > > require > > > additional tighting up, but if you don't trust > the server > > > itself, that > > > may be tricky. Please note that ZooKeeper > isn't meant > > > to be used just > > > as a distributed filesystem for storage, but > that's > > > probably not your > > > intention anyway. > > > > > > -- > > > Gustavo Niemeyer > > > http://niemeyer.net > > > > > > > > > > > >
