Hi Ratul, Imagine the phone example. Both app have the duty of having a log of what was done. app745 talked to app234 and app234 talked to app745. If during such talk one of them stops seeing the other it should log, app745 was talking with app234 when it hang up. Not sure if app745 really need to update app234 log but the hangup status is a bad one for app234 and i need thta to b valid only when its true. app745 cant say app234 hang up if it did not and app234 cant say that app745 log stating app234 hangup is false if its not. I considered that both app log that the task started and the missing end entry behaving as the hangup log. but this has not helped.
Jacques On Thu, Oct 8, 2009 at 1:36 AM, <ratul.mukhopadh...@wipro.com> wrote: > Hi Jacques, > > I guess 1 and 2 can be achieved with any of the common DHTs. But with 3, > you are now dealing with node churn. In this case, it gets a little more > complicated. In fact, it may even affect 2. I would suggest you to read the > following preliminary papers to get a perspective of how to deal with such > scenarios. > > > > *nms.lcs.mit.edu/papers/podc2002.pdf*** > > *www.srhea.net/papers/bamboo-usenix.pdf* > > *iptps06.cs.ucsb.edu/papers/Tati-Maint06.pdf* > > > > I also have some questions regarding 3. If app234 goes down all of a > sudden, and app745 is expected to update the data to the DHT, I suppose > app745 is updated by app234 itself at every step of the task. How about > updating data from each step to the DHT itself every time? Is that not an > option for your application? I am raising this question because of a > scenario wherein both app234 and app745 goes down. What then? Since you have > not incrementally saved app state to the DHT, everything is now lost. > > > > Regards, > > Ratul. > > > ------------------------------ > > *From:* p2p-hackers-boun...@lists.zooko.com [mailto: > p2p-hackers-boun...@lists.zooko.com] *On Behalf Of *Jacques Exelrud > *Sent:* Wednesday, October 07, 2009 11:31 PM > *To:* p2p-hackers@lists.zooko.com > *Subject:* [p2p-hackers] Distributed partnership > > > > Dear p2p-hackers, > > > > For an application I`m wrtting I miss two features. > > > > 1) The app needs to be able to locate among the remaining running > applications (same app running around the world, ie app234 and app745) one > that it`ll act as partner to solve the task. > > 2) After this task is done among other things I have a bunch of data (small > volume) that belong to each node that is affected by the fact they worked > together. So stat stat234 is changed and stat745 is also changed. Those two > sets of data need not be lost and update any previous version that was > around. > > 3) If during thet work one of the peers is gone (app234) then app745 needs > to be able to update both sets of data (I suppose something like some time > must be waited in order of this set of data be allowed. Maybe app234 have > some time to inform he is still present and this update needs to be > validated by it. If app234 is really gone then after some time the data > updated by app745 (both sets) is valid. I'm afraid that I'll have a hard > time on this topic not being exploitable so, for now, it's desirable but not > needed. > > > > I think I can use DHT to solve 1st task and 2nd task can be solved by > freenet (or similar) by publishing new version of both data. > > > > Its desirable (but not mandatory) that only app234 can be shown as app234. > Also I do not want any central controller, directory, signer or anything. > > > > Not a good example but close to is as follow: > > > > Two person that want to talk. One needs to be able to find the other in > other to directly talk to. The data changed could be something like people > I've talked to list. > > > > Any suggestions ? > > > > Thanks in advance, > > Jacques > > *Please do not print this email unless it is absolutely necessary. * > > The information contained in this electronic message and any attachments to > this message are intended for the exclusive use of the addressee(s) and may > contain proprietary, confidential or privileged information. If you are not > the intended recipient, you should not disseminate, distribute or copy this > e-mail. Please notify the sender immediately and destroy all copies of this > message and any attachments. > > WARNING: Computer viruses can be transmitted via email. The recipient > should check this email and any attachments for the presence of viruses. The > company accepts no liability for any damage caused by any virus transmitted > by this email. > > www.wipro.com > > _______________________________________________ > p2p-hackers mailing list > p2p-hackers@lists.zooko.com > http://lists.zooko.com/mailman/listinfo/p2p-hackers > >
_______________________________________________ p2p-hackers mailing list p2p-hackers@lists.zooko.com http://lists.zooko.com/mailman/listinfo/p2p-hackers
