Hangin up is one peer stopping receiving answer from the other, the app may have crashed, cable priveider went down, routing problem, anything. In some cases (app crashing) only one side stops receving info as the other is no longer running, in other (cable down) on app still sees the p2p network the other does not but both believe the second is the faulting one, in the routing case both app still see part of the p2p network and both thinks the other is the faulting one.
if is use a tcp socket or timeout/heartbeat the problem persists, i still need a good way to one of the to record the incident in both logs (preferably) but preventing of doing so in abusive way. The phone example is not good to show why i need to record the hangup. If a peer does not do the job well i'll update it's data reflecting that. But the peer can disconnected the line trying to flee from this fact. I can't say the he did not do the job well, but i can say he didn't finish. Those info will help me construct some kind of trustworthy degree of each peer. Its not exactly that but its close. Your idea of behavior if the peer is back is good, but i still need to be able to say some peer havent finished what is due to it in a non abusive way. There is one point I haven't told, I think it'll not affect the discussion. But each node can take part in a few tasks and this discussion is valid for each of them and the tasks that each node can do can be different from others, but will be definned by the application. The only role the peer can have in this case is announcing/registering itself as being able to perform task A, D and Y instead of X, F and Y. Jacques On Thu, Oct 8, 2009 at 11:00 AM, <ratul.mukhopadh...@wipro.com> wrote: > I am confused. Could you perhaps restructure the phone example? > > > > Let me state what I understood from your description. One app goes down. > How do we ensure that the other really knows for sure that it has gone down? > Is the question that simple, or am I missing something? If it is, then how > exactly does a peer_going_down (first mail) correspond to app_hanging_up > (second mail)? I am assuming a hang-up means the peer going down totally, > rather than only the application failing to respond. Have you considered a > session layer to keep track of each partnership task? If you are using > something straight-forward like sockets, a broken socket would indicate a > hang up (assuming hang_up is equivalent to a peer going down). If not, you > will have to work with timeouts/heartbeats. > > > > Why do you want to record the hang-up in the state? Are you planning to > renew broken partnership tasks, and continue from where they ended abruptly > (once the drowned node resurfaces)? One thing you could probably try is to > use some time out mechanism to conclude that a node is down, and update the > hung state to the DHT. If the down node starts signaling again, use a > distributed roll-back operation to correct the state. > > > > I am not sure if that really answered your question. > > > > ~Ratul. > > > ------------------------------ > > *From:* p2p-hackers-boun...@lists.zooko.com [mailto: > p2p-hackers-boun...@lists.zooko.com] *On Behalf Of *Jacques Exelrud > *Sent:* Thursday, October 08, 2009 3:51 PM > *To:* theory and practice of decentralized computer networks > *Subject:* Re: [p2p-hackers] Distributed partnership > > > > 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 > > > > * 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
