Friday, January 09, 2004
Many people think DHTs might have the possibility of being a unified P2P architecture, a single structure that provides several different network services; the IRIS project is predicated on this belief. A unified P2P DHT-based architecture is attractive because it means programmers only have to understand and implement a single network substrate in order to get many different services. For example, an open-source project named The Circle implements a Chord-like DHT and uses it in several different ways:
* Share files
* Send instant messages and chat IRC-style
* Put together your own personalized, trust based news service
It does this by using its Chord DHT as a generalized architecture that doesn't need to be changed based on particular uses.
I would like to add NAT/Firewall routing and detection to the mix. The research question is: is it possible to add NAT/Firewall routing into DHTs/overlay networks such that you get them "for free" or for very little extra effort?
Well, as a first quick stab at the problem, imagine this. Most DHT type systems involve your requests being mediated by other peers, as they examine the hash of what you are looking for, and either re-route that request in a certain direction or satisfy it because they are handling that portion of the DHT space. So by default all peers are being mediated, which is a base requirement for NAT or firewall issues, since those peers can't automatically receive incomming requests from outside peers and need to be mediated for certain transactions. Imagine further that your particular DHT scheme requires that you maintain a constant connection with the other peers who are "closest" to you in the DHT space, which makes sense for performance reasons because you will be getting and sending requests to these folks on a large basis. If this connection were made to be HTTP, then we have again solved another piece of the puzzle since many firewalls allow HTTP connections out; plus, many of the JXTA-type NAT schemes require that the NATed peer maintain an HTTP connection to another peer, who mediates all inbound requests to the NATed peer. Further, imagine if we somehow encode whether a peer is NATed or firewalled into its hash address, and choose our DHT scheme to somehow "stripe" NATed/Firewalled peers against non-NATed/non-firewalled peers (since NATed/Firewalled peers must have non-NATed/non-firewalled peers be their intermediaries). Now imagine that we are a NATed/firewalled peer, sitting in our location in the DHT address space in such a way that we are automatically being mediated by our closest neighbor, who is non-NATed/non-Firewalled. We maintain a connection to our closest neighbors using HTTP. We send out a request containing the hash value of some item to retrieve as well as our own peer's hash ID within the space; this value is routed through the DHT until it reaches a peer who can satisfy it, at which time that peer pulls out the requesting peer's hash ID and sends back the response. Since our DHT was set-up to stripe NATed and non-NATed peers together, as this responding request comes back through the mesh it will automatically go to the non-NATed peer, who will then send it back to us.
* Share files
* Send instant messages and chat IRC-style
* Put together your own personalized, trust based news service
It does this by using its Chord DHT as a generalized architecture that doesn't need to be changed based on particular uses.
I would like to add NAT/Firewall routing and detection to the mix. The research question is: is it possible to add NAT/Firewall routing into DHTs/overlay networks such that you get them "for free" or for very little extra effort?
Well, as a first quick stab at the problem, imagine this. Most DHT type systems involve your requests being mediated by other peers, as they examine the hash of what you are looking for, and either re-route that request in a certain direction or satisfy it because they are handling that portion of the DHT space. So by default all peers are being mediated, which is a base requirement for NAT or firewall issues, since those peers can't automatically receive incomming requests from outside peers and need to be mediated for certain transactions. Imagine further that your particular DHT scheme requires that you maintain a constant connection with the other peers who are "closest" to you in the DHT space, which makes sense for performance reasons because you will be getting and sending requests to these folks on a large basis. If this connection were made to be HTTP, then we have again solved another piece of the puzzle since many firewalls allow HTTP connections out; plus, many of the JXTA-type NAT schemes require that the NATed peer maintain an HTTP connection to another peer, who mediates all inbound requests to the NATed peer. Further, imagine if we somehow encode whether a peer is NATed or firewalled into its hash address, and choose our DHT scheme to somehow "stripe" NATed/Firewalled peers against non-NATed/non-firewalled peers (since NATed/Firewalled peers must have non-NATed/non-firewalled peers be their intermediaries). Now imagine that we are a NATed/firewalled peer, sitting in our location in the DHT address space in such a way that we are automatically being mediated by our closest neighbor, who is non-NATed/non-Firewalled. We maintain a connection to our closest neighbors using HTTP. We send out a request containing the hash value of some item to retrieve as well as our own peer's hash ID within the space; this value is routed through the DHT until it reaches a peer who can satisfy it, at which time that peer pulls out the requesting peer's hash ID and sends back the response. Since our DHT was set-up to stripe NATed and non-NATed peers together, as this responding request comes back through the mesh it will automatically go to the non-NATed peer, who will then send it back to us.
Subscribe to Posts [Atom]
