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
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 protected]>
Date: Sat, December 26, 2009 5:20 pm
To: Michael Chen <[email protected]>
Cc: [email protected]
On Sat, Dec 26, 2009 at 5:15 PM, Michael Chen <[email protected]> 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
_______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
