Subject: Re: [P2PSIP] Remove StoreReq.resource, FetchReq.resource, etc.

From: "Michael Chen" <[email-masked]>
Date: Sun, 27 Dec 2009 09:48:55 -0700

Eric,

Thanks for pointing out the replica StoreReq paragraph in 6.4.1.1, but I still have 2 questions:

1. What is the via and destination list look like for a replica StoreReq?

I believe StoreReq (replica or not) should not be routed, thus the via list should be empty and the destination list should contain a lone entry of the receiving peer (i.e. the successor of the responsible peer). If this is true, the draft should enforce it.

2. What are the use cases for the other 3 requests where the resource ID in the message differ from the destination list?

FetchReq.resource
StatReq.resource
FindReq.resource

Replica is not involved in these cases. These messages are only meant to be answered by the responsible peer. If this is true, these resource IDs should be removed from the message.

Thanks

--Michael

-------- Original Message --------

Subject: Re: [P2PSIP] Remove StoreReq.resource, FetchReq.resource, etc.

From: Eric Rescorla <[email-masked]>

Date: Sat, December 26, 2009 5:20 pm

To: Michael Chen <[email-masked]>

Cc: [email-masked]

On Sat, Dec 26, 2009 at 5:15 PM, Michael Chen <[email-masked]> wrote:

> Hi,

> The resource IDs in these request structures should be removed and be

> provided only from the Destination list in the forwarding header.

>     StoreReq.resource

>     FetchReq.resource

>     StatReq.resource

>     FindReq.resource

> This can avoid the possible inconsistency between the header and the

> message. It may make the request structure seemingly incomplete, but less is

> more.

These aren't actually redundant. There are times when you want to do a

Store or a Fetch to the non-responsible node (e.g., replica stores).

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 27 Dec 2009 09:10:37 -0800

On Sun, Dec 27, 2009 at 8:48 AM, Michael Chen <[email-masked]> wrote:
> I believe StoreReq (replica or not) should not be routed, thus the via list
> should be empty and the destination list should contain a lone entry of the
> receiving peer (i.e. the successor of the responsible peer). If this is
> true, the draft should enforce it.

I had assumed that this question was implementation and overlay
dependent. Say for the sake of argument that a node can't establish
direct connections with all the replica set, then it would have to
route replica stores, no? What do you think would be the advantage
of adding this restriction?

> 2. What are the use cases for the other 3 requests where the resource ID in
> the message differ from the destination list?
>
>   FetchReq.resource
>   StatReq.resource

Both of these can be used by the storing node to explicitly address replica
nodes; see 6.4.1.2:

      The list of other peers at which the data was/will be replicated.
      In overlays and applications where the responsible peer is
      intended to store redundant copies, this allows the storing peer
      to independently verify that the replicas have in fact been
      stored.  It does this verification by using the Stat method.  Note
      that the storing peer is not require to perform this verification.

The text probably should say "Stat or Fetch" methods.

>   FindReq.resource
>
> Replica is not involved in these cases. These messages are only meant to be
> answered by the responsible peer. If this is true, these resource IDs should
> be removed from the message.

Well, the idea with Find is to allow you to ask a specific node a question, so
it's expected to be addressed to a node directly, not a resourceid, thus
requiring the resourceid in the request.

-Ekr