Hello Dan, Electing a new master on a federation of internet services does not sounds a idea (at least extremely complex). Several component can see at the same time that a service is down and elect themselves master on a given content, which can thus be distributed several times. Many other problems can occurs, especially if you consider the internet link as not reliable.
That's why I was thinking that the original question was more: "How to make content persistent on Fedone to avoid loosing waves" than actually how can we build a fully robust loosely coupled and distributed data and manipulation system. Relying on each server building a reliable cluster deployment seems to be enough for me. What could be a nice goal however is to allow read only access to wave that cannot currently be accessed, but that sounds conceptually easier. -- Mickaël Rémond http://www.process-one.net Le 29 janv. 2010 à 14:45, Dan Peterson a écrit : > Agreed. This is an area I've been thinking about lately -- the electing a new > master scheme is appealing, but then what do you do when the original master > returns to the rest of the network (e.g. the uplink that was severed is > restored, then there'd be 2 servers that think they are master)? > > As an alternative scenario, I suppose the wave client UI could encourage a > "fork" of the wave conversation -- copying the latest version of the contents > into a new wavelet on the non-dead wave provider. Of course, forks are > effectively duplicate content, so not so ideal. > > -Dan > > On Sat, Jan 30, 2010 at 12:36 AM, Torben Weis <[email protected]> wrote: > Hi, > > I fear it is not as easy as assigning it to missing FedOne features. > > If the master wave server breaks you need some other server to take over. But > the domain name of the broken server is encoded in the wavelet URIs which are > encoded (i.e. signed and hashed) inside the deltas. Thus, you cannot simply > replace the wave server without taking care of the cryptographic problems. > > Even if this is dealt with, how do you efficiently vote on a new master > server? It must not happen that at any time there is doubt about the master > server (i.e. several clients deem different servers to be the master). Wave's > OT cannot handle such a scenario. There are peer-to-peer OT concepts which > can deal with it, but wave does not currently. > > I think this is a really interesting research question, but the solution will > not be all too easy. > This being said, even normal federation is complex enough :-) > > Cheers > Torben > > 2010/1/29 Mickaël Rémond <[email protected]> > > Hello, > > Le 29 janv. 2010 à 13:17, chiang a écrit : > > > Hi all, > > > > This could already have been a known deficiency in the federation > > architecture, but I would like to enquire if it is by design that we > > have authoritative or master wave servers for a particular wave? As > > I've just found out that if the Fedone wave server (which hosts a > > master copy of my initiating wave) goes down or losses all the waves, > > the Fedone wave server does not recover the wave from wavesandbox, > > which also has a copy of the wave. I initially thought wave servers > > federation is supposed to be scalable, and resilient... > > Fedone is an example implementation, not a production ready wave server. For > example, it still miss the storage engine, is not clustered etc. > So this limitation is not by design but simply a not-yet-implemented feature. > > Having an authoritative server for every wave seems a good and needed > approach for the Wave protocol itself. > > -- > Mickaël Rémond > http://www.process-one.net/ > > -- > You received this message because you are subscribed to the Google Groups > "Wave Protocol" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/wave-protocol?hl=en. > > > > > -- > You received this message because you are subscribed to the Google Groups > "Wave Protocol" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/wave-protocol?hl=en. > > > -- > You received this message because you are subscribed to the Google Groups > "Wave Protocol" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/wave-protocol?hl=en. -- You received this message because you are subscribed to the Google Groups "Wave Protocol" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/wave-protocol?hl=en.
