Hi, all: In the section 6.4.2.1 in RELOAD 00, there is a definition on the Attach method: A node sends an Attach request when it wishes to establish a direct TCP or UDP connection to another node for the purposes of sending RELOAD messages or application layer protocol messages, such as SIP.
>From the above definition, Attach request will be terminated by a node who has the same node-id as the destination node-id in the destination list. For example, if peer A wants to attach to peer X whose node-id is 0x123456, then the destination list of the Attach message should be set to the node-id 0x123456, the destination type is node; But in section 14, Attach is also used to establish connection with the nodes which will be filled in the sending node's finger table. In this case, the destination node should be of a resource type and the peer who will terminate the Attach request is the peer who is responsible for the resource id. So there are two kinds of peers who will terminate the Attach request. One is the peer who has the same node-id as the destination in the destination list. The other is the peer who is responsible for the destination (resource type) in the destination list. Because Attach will negotiate the parameters for ICE procedure and establish direct connection between the sending node and the node terminating the request. So if in some situations, if a peer wants to Attach to a node with the same node-id as the destination, and at the same time, the node who has the same node-id as the destination is offline, then later the peer who is responsible for the destination will terminate the request, but the peer is not what the sending peer intended to attach. Finally, unnecessary ICE and connection will be established between them. IMO, I think, in RELOAD, we need to avoid this kind of thing happen. Some situations where the above error happens are listed below: 1. When a peer gets another peer-id through some methods, for example, peer A sends a FETCH message to get the peer where bob is located. Due to some reasons, this information may be stale, for example, bob has quit the system ungracefully without notification to the overlay. Then A will use bob's peer id to establish a direct connection and wants to call him. Finally, a direct connection will be established between A and other peer than Bob. However, the SIP signaling will detect the error and refuse the call, but it does waste resource for the unnecessary connection. 2. When a peer receives Update message form its neighbors, and try to attach to the new neighbor in the routing table in the Update. It is possible that the new neighbor is not online, so it also makes the peer establish an incorrect neighbor connection. 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; 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. Any comments are appreciated. Regards! -- Jiang XingFeng _______________________________________________ P2PSIP mailing list [EMAIL PROTECTED] https://www.ietf.org/mailman/listinfo/p2psip
