June 30th, 2002
|
| |
But this problem can be circumvented by a TCP "proxy-out" mechanism. Here's how Blubster's author deals with it: Quote:
How are we going to enable everybody to connect with Blubster if they can’t use UDP? The answer is “Guide Nodes”. Guide nodes will be normal Blubster peers that will be acting like a guide for non-UDP-enabled peers.
The idea is that, when a peer (peer-A) that can’t use UDP tries to connect, it will “ask” for a UDP-enabled peer (peer-B) to be his/her gateway to the network. A normal TCP/IP connection is now between the two peers. The peer-A will see through peer-B. When peer-A needs to search for something, it passes the search to peer-B, who will process it, resending it -using the normal UDP transmissions- to the network. Peer-B will then receive the results and will forward them to peer-A. This is similar to the router port forwarding, but we will do it in a different layer.
The pros for this method are that everybody will be able to connect with Blubster. If you can navigate the web then you can connect to a Guide Node. The cons are the TCP/IP connection needed. TCP/IP transmissions are reliable, which means that guided peers will not be anonymous. Guide Nodes will sacrifice about 20% of performance receiving, processing and sending data to the guided peer.
| The performance hit for those who use this method shouldn't be that bad, IMHO.  |
Similar Threads 
Threaded Mode
