Well, we released the code as open-source software so that anyone can take the ideas and implement them elsewhere. And we're happy to help anyone who wants to port it.
(From one of the software authors) Obviously this is a real concern, so by default SwarmScreen does nothing until you tell the software where to find content to download. It will only get content from the sites you tell it to.
This is slightly OT, but your brother might find it helpful to check out what these guys are doing: http://people.ucls.uchicago.edu/~bfranke/csreq/index.html
There is a movement toward making CS a graduation requirement for high school, something tells me a few of your here would agree with this.
Actually, I've seen this effect before when testing transfers between two machines behind the same router (one Linux, one XP), both sending data to the same destination in an alternating fashion. Linux was consistently faster. At the time, the source of the difference was that Linux was using a more aggressive default TCP stack than Windows. This might be the reason.
In other words, Ono is not counting router hops, though it is true that Ono generally finds peers along shorter IP-level paths. This makes sense, since Ono finds peers relatively nearby.
For the record, it's not quite based on router hops. Ono exploits CDN redirections for very efficient peer baising. You can find the technical details here: http://www.aqualab.cs.northwestern.edu/publications/DChoffnes08Sigcomm.html
Also, if you want to restrict biasing to a custom set of IP address blocks, Ono now supports "manual peer biasing" toward those blocks. A description of how to use this feature (tailored for Kiwis) is here: http://homepages.xnet.co.nz/~createcoms/
I think they're going to treat all traffic equally, so if your BT download rates suck due to congestion, so will your YouTube, Slashdot, etc. I don't see any way they can reliably allow on BT, Inc. traffic.
Anyway, the more interesting question is what are they doing to make BitTorrent "more efficient" for Comcast. Maybe something like Ono?
Ono definitely does a similar thing without requiring ISPs in the loop. Also, the approach is general, but currently only implemented for Azureus. Ono is open source, so one can port it to other apps -- I'm sure the authors would be happy to help.
Slashdot Mirror
Well, we released the code as open-source software so that anyone can take the ideas and implement them elsewhere. And we're happy to help anyone who wants to port it.
(From one of the software authors)
Obviously this is a real concern, so by default SwarmScreen does nothing until you tell the software where to find content to download. It will only get content from the sites you tell it to.
(From the one of the software authors) UTorrent doesn't support plugins and is closed source. If that were to change, we'd happily develop for it.
This is slightly OT, but your brother might find it helpful to check out what these guys are doing: http://people.ucls.uchicago.edu/~bfranke/csreq/index.html There is a movement toward making CS a graduation requirement for high school, something tells me a few of your here would agree with this.
Actually, I've seen this effect before when testing transfers between two machines behind the same router (one Linux, one XP), both sending data to the same destination in an alternating fashion. Linux was consistently faster. At the time, the source of the difference was that Linux was using a more aggressive default TCP stack than Windows. This might be the reason.
Only infrequent DNS lookups are needed.
In other words, Ono is not counting router hops, though it is true that Ono generally finds peers along shorter IP-level paths. This makes sense, since Ono finds peers relatively nearby.
For the record, it's not quite based on router hops. Ono exploits CDN redirections for very efficient peer baising. You can find the technical details here: http://www.aqualab.cs.northwestern.edu/publications/DChoffnes08Sigcomm.html Also, if you want to restrict biasing to a custom set of IP address blocks, Ono now supports "manual peer biasing" toward those blocks. A description of how to use this feature (tailored for Kiwis) is here: http://homepages.xnet.co.nz/~createcoms/
I think they're going to treat all traffic equally, so if your BT download rates suck due to congestion, so will your YouTube, Slashdot, etc. I don't see any way they can reliably allow on BT, Inc. traffic. Anyway, the more interesting question is what are they doing to make BitTorrent "more efficient" for Comcast. Maybe something like Ono?
No, they game the BT system by giving other peers as little bandwidth as possible while still getting good performance from them.
Ono definitely does a similar thing without requiring ISPs in the loop. Also, the approach is general, but currently only implemented for Azureus. Ono is open source, so one can port it to other apps -- I'm sure the authors would be happy to help.