Subject: [P2PSIP] clients in reload and Update

From: Bruce Lowekamp <[email-masked]>
Date: Thu, 16 Jul 2009 22:46:56 -0400

Based on some of the list discussion, we (mostly ekr) tried to improve
some of the text surrounding clients in the draft.  I hope this
clarifies some of the intent of how clients are supported by the base
protocol.

I also added some text to send Update requests to all nodes in the
Connection Table when a peer's responsible ID range changes.  The
intention of this change was to provide a mechanism where a node
attaching to a peer because it is responsible for a particular ID be
notified if the peer is no longer responsible for the desired ID.
This change also doesn't require the peer to determine why a
particular connection is established, which preseves the generality of
the current approach.

Unfortunately, the implication of sending Updates to clients is that
clients are required to process Updates.  This is in conflict with the
goal that clients don't need to implement the overlay algorithm used
by the overlay (since Update's content is defined by the overlay
algorithm).  I see a few solutions to this problem:

1) rely on the clients to periodically Ping or Route_Query to ensure
they are connected to the correct peer.  Unfortunately, this leaves an
obvious gap before the topology change is noticed.  Unlike
sip-outbound, we don't have redundant connections to compensate for
temporary loss of reachability.

2) define a new method for this purpose that is generic, so
independent of overlay algorithm

3) retain the current use of Update, and specify that a client
receiving an Update that it cannot process (because it does not speak
the overlay algorithm) SHOULD perform a Route_Query to confirm it is
still connected to the proper peer.

My personal preference is option 3, because I dislike the performance
tradeoffs of option 1, and I think option 3 has all of the
functionality option 2 would have anyway.

On a slightly separate note, I'm a bit concerned about the ability to
establish a client's ability to establish a reliable connection with
its responsible peer.  In Chord, for example, greater reliability
would be achieved by establishing a connection with the responsible
peer and n successors.  If a peer receives a message routed to a node
for which it is responsible but has no connection, it could then
forward that message to its n successors to attempt to deliver it.
Currently the peer would drop the message silently.

My current feeling is that such a feature should be left for an extension.

Bruce

---

From: Bruce Lowekamp <[email-masked]>
Date: Fri, 17 Jul 2009 10:09:24 -0400

> still connected to the proper peer.

I should have been more clear that options 2 and 3 are peer-initiated
(so 2 would be a new Request a peer sends to all members of its
connection table when its responsible ID range changes).

Bruce

---

From: Bruce Lowekamp <[email-masked]>
Date: Tue, 28 Jul 2009 10:26:23 +0200

> Currently the peer would drop the message silently.

After thinking about it some more, I'm wondering if a better option
might be to define a new method that allows a client to query for the
replica set for a Resource-ID and for the peer to inform its connected
non-overlay-topology nodes when the replica set for a Resource-ID
changes.  This would address both of these problems at the same time
without requiring clients to speak the overlay algorithm.

Bruce

---

From: [email-masked]
Date: Tue, 28 Jul 2009 18:28:49 +0800

===================================
 Zip    : 210012
 Tel    : 87211
 Tel2   :(+86)-025-52877211
 e_mail : [email-masked]
===================================

Bruce Lowekamp <[email-masked]> 
发件人:  [email-masked]
2009-07-28 16:26

收件人
p2psip <[email-masked]>
抄送

主题
Re: [P2PSIP] clients in reload and Update

Bruce
_______________________________________________
P2PSIP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/p2psip

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.