On Mar 5, 2008, at 2:42 PM, jiangxingfeng 36340 wrote: >>> To me, I am not clear what the relationship between Peer >> protocol level and DHT level from the RELOAD-3 architecture >> figure. Could you give me more information on this? thank you. >> >> Hmm.. Not sure what to say here. Maybe if you told me what you're >> not clear on I could try to explain more. >> > > Ok, Let me clarify it. In order to make the DHT algorithms a > independent piece of the implementation, we should have a clear > call interface to them. RELOAD-3 has done great work in that > regard, I think. > > My concern is: Conventional DHT algorithms only use the routing > table to make routing decisions and because NAT is not considered > in most algorithms, the destination peer often send the response > directly to source peer by using the semi-recusive routing mode( in > P2PSIP term). But due to NAT existence, destination list tries to > reuse the reverse connection which the request has traversed to > improve the performance, but DHT could not find the > reverse connection in the routing table and instead should lookup > in a new state, connection table (if my understanding is right) or > using a new method to check its routing table to see whether the > peer ID is really his neighbor. In that case, I think it introduces > the flexible routing decision which is other than conventional > routing method used in DHT. > > So my question is: where will the function finding the reverse > connection be realized? If it is implementated in the DHT level, it > will break the independence of the the DHT algorithm. If > implementated in the Routing and Replication logic, it will > introduce a new location to do the routing decision? >
The overlay routing and storage layer (of which the DHT is a pluggable component) only needs to deal with the overlay in terms of PeerIDs. The actual IP address used to communicate with a particular peer is actually handled by the Forwarding Layer. There is a minor layering issue in that the DHT and the forwarding layer do need to share knowledge of which peers connections are actually established with (as only they can be in the DHT's routing table), but the DHT still only needs to deal with that at the level of with which PeerIDs connections are established. So for symmetric routing, the via-list encodes the reverse path as a list of peerIDs. To route a reply the via list is switched to the destination list and the next peerID popped at each hop. The connection table that is maintained by the forwarding layer will have a connection to the peerID at each hop, so that is where the IP address used for routing the response will be found. Routing replies actually doesn't require involvement of the DHT (although some DHT algorithms do learn/cache based on reply paths). This all needs worked-out examples in the draft... Bruce _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
