Cullen Jennings wrote: > Great comments - thanks - more inline > > On Jun 17, 2008, at 1:22 AM, JiangXingFeng wrote: > >> Hi, >> Some comments on the new RELOAD-4. Hope it is helpful. >> >> 1.connect: IMHO, the peer sending the connect request SHOULD check >> whether >> the >> destination peer ID equals the peer ID it wants to connect or not when >> receiving >> the response. But in some case, the peer may find a peer who is >> reponsible >> for the >> requested Node ID, not the peer whose ID equals the request Node ID. >> For >> example, if a peer receives a UPDATE request and start to connect >> with the >> peer >> in the routing table in the UPDATE reqeust. Maybe some peer is not >> alive or >> offline, in this case, the connect request will be directed to the >> peer >> being >> responsbile for the Node ID. So suggestion is to check whether >> mismatch >> happens. >> >> (Open Issue: do we need extend connect to distinguish connect for a >> resource >> or >> for a peer? For example, if the resource value is so large that not be >> appropriate delivered through the overlay, a direct connection may >> be needed >> for >> the future transfer.) > > Good point - I'm not really sure what to do here. I can see the use > case you are making for connects to an ID that is different than the > id of the node that ends up connecting. The only way I see to allow > that is to remove the check but I'd have to think about if this breaks > anything. >
Establishing a direct connection before transferring a large resource is clearly pretty important and useful. I think you've hit on a good point and the exact mechanism for doing so may need a little more thought. > >> >> 2.In section 1.2.4 When connections are made or broken, the >> Forwarding Layer >> >> notifies the Topology Plugin, which adjusts the routing table as >> appropriate. >> >> To me, I am not clear how the RELOAD detects the connection has been >> broken >> down? Just relying on the STUN keepalive message or conclusion from >> failure >> to >> deliver the packets to the next hop if the transport protocol is not >> reliable, >> such as UDP? Why not use a keepalive mechansim at the peer layer to >> detect >> the >> connection failure? > > Yes, I agree some sort of keep alive is needed to detect liveness on > these connection. We also need to be able to deal with receiving a TCP > RST for the TLS connections. Why should the keepalive be at the peer layer rather than using STUN? It seems like that mechanism is well-understood and lightweight. Now detecting failure is a slightly different question (and very hard, in general), but in general it seems to me that the stun keepalives solve this. (You're right that the draft doesn't say that you should be using STUN keepalives over TCP/TLS. But assuming it did, do you think it needs something else at the peer layer?) Bruce _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
