Bruce: Thanks for your clarification.
But As proposed in bullet 6.1.2.1, If the entry is a Node-Id which is not equal to this node, then the node MUST drop the message silently unless the Node-Id corresponds to a node which is directly connected to this node (i.e., a client). I don't think in this case, just dropping the message silently is an appropriate action. The sender of the Attach request needs to know what happened, otherwise, it will retransmit the request until all retransmissions are attempted. It's a waste of time and resource. So the destination peer SHOULD send an error response to the sending peer. As we know, rules in section 6.1.2 serve for all kinds of messages. So does that mean RELOAD need to differentiate message types to take different actions when the node-id does not equal to the peer own node-id? Comments? -- > > Jiang, > > Thanks for looking at this in detail. > > JiangXingFeng wrote: > ... > > So I propose to make a few modifications to Attach method in RELOAD to make > > the semantics of Attach more clear and avoid necessary connections. > > 1. Add more text in Attach section on how to set the destination type in the > > Attach request. resource id or node id; > > I think this would be a good clarification. I will try to add some more > text here suggesting why you would route an Attach to a resource-id or > to a node-id. > > > 2. When the responsible peer receives the Attach request, the peer will > > check the destination type first. If the destination type is node id, the > > peer will check whether the peer's own node id equals to the destination > > node id; If they don't equal, sends a error to the sending peer and refuse > > to establish connection. > > I think this is the correct behavior, but it's actually already > accomplished in another way. The general routing algorithm only > delivers messages routed to a node-id if the node-id is an exact match > for a particular node, as described in the third bullet of 6.1.2.1 and > clarified in the note in that section. > > Bruce _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
