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-bounces at lists.zooko.com
[mailto:p2p-hackers-bounces at 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.mukhopadhyay at 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
<http://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-bounces at lists.zooko.com
[mailto:p2p-hackers-bounces at lists.zooko.com] On Behalf Of Jacques
Exelrud
Sent: Wednesday, October 07, 2009 11:31 PM
To: p2p-hackers at 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 <http://www.wipro.com/>
_______________________________________________
p2p-hackers mailing list
p2p-hackers at lists.zooko.comhttp://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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.zooko.com/pipermail/p2p-hackers/attachments/20091008/5c387484/attachment-0001.htm