how-to block ads
|
ISurfTooMuch
join:2007-04-23
Tuscaloosa, AL
| Let them try First of all, I applaud any effort to reduce bandwidth. Frankly, I can't understand why current or even past P2P clients didn't implement something like this, since it benefits the end user. Why would a Comcast user want to download a file from China when the same file is available from another Comcast user? Odds are, the file that's closer will be served up faster.
Having said that, let the ISP's try to place restrictions on this. As soon as they do, two things will happen. First, other P2P clients will implement the same technology, which may happen even if P4P comes without any catches. Second, you can bet that, even if the ISP's don't release the source code, someone will manage to decompile the application and remove any restrictions it contains. Mark my words, it'll happen. | |
|  
funchords
Hello
Premium,MVM
join:2001-03-11
Washington, DC
 ·Verizon Online DSL
 ·Skype
| Re: Let them try said by ISurfTooMuch  :First of all, I applaud any effort to reduce bandwidth. Frankly, I can't understand why current or even past P2P clients didn't implement something like this, since it benefits the end user. They already do, in the way that the P2P clients select peers to pair with for longer-term higher-speed transfers, but it takes 15-30 minutes or so to work through the list of peers (in BitTorrent). The same effect works in eMule and Gnutella but it's based on how many times the same pairs will trade with each other based on their scoring systems.
P4P adds intelligence provided by the ISPs as to where their own routes are vs. the routes of their most expensive transit providers. That intelligence is used to bias the results in peer selection so that the first set peers that you connect with will be heavy on the more local peers.
Of course, all of these tests have been closed and we've just got their word to go on -- but their words are that YES it will be open-source, YES P2P client authors will be able to incorporate it, YES P4P is a choice and users can opt to ignore it without penalty.
Those are great words, and I hope they come true.
--
Robb Topolski -= funchords.com =- Hillsboro, Oregon
More features, more fun, Join BroadbandReports.com, it's free...
| |
| 
RARPSL
join:1999-12-08
Suffern, NY
| said by ISurfTooMuch :First of all, I applaud any effort to reduce bandwidth. Frankly, I can't understand why current or even past P2P clients didn't implement something like this, since it benefits the end user. Most of the support for doing a P4P-like system already exists in the current BT code. All that is needed is to add code to flag each peer as Type1 (same netblock as you), Type2 (same Network), or Type3 (not on my ISP's Network). This information can be located via a WHOIS to whois.arin.net. You query it for your IPN and this will tell you your Netblock (Netblock Name and IPN Range). The Type2s are located by editing the Netblock name. Any peer whose IPN is not in the Type1 or Type2 range is automatically Type3. Now you parse the list of peers to get Type1s. If this does not yield the number of maximum sessions that the user has defined, start adding Type2s. If you still have open slots, go for Type3s. In each case, you select from the current pool using the same methods that are currently used.
This causes you to first talk to near peers, then others on your ISP's network before going out of your ISP's network. No need for P4P mucking with (or monitoring/approving/censoring) your connections since your client does all the selection as it does right now (just more efficiently). | |
| | | |
|
