Maybe. But there are two reasons this can happen:
- the target node doesn't exist
- the receiving node (due to instability) isn't aware of the node existing
In the first case, an error message would produce the fastest result, as
you suggest. But in the second case, the periodic retransmission might
occur after the instability is resolved and a subsequent retransmission
would be received correctly. In that situation, if the original
receiving node sends an error response, the transaction is terminated
and the originating node needs to have its own timer to retry the
attempt if it desires.
If the originating node is using parallel routing (which is allowed by
reload, but not specified in the base draft), then it's quite possible
that a different branch of the query is actually returning a successful
response.
Bruce
JiangXingFeng wrote:
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
