Hurray PTCL!!

Nor The ISPs Will Be The Virus…But Ourselves Who Don’t Want To Share.

Greed Is Part Of Our Human Nature…We Have To Act Against It.

Much Respect To The Dev Team.
I Take My Hat Off.

I strongly dislike the point of view many ISPs around the world have assumed. Too often they pretend to know better than us about our actual needs. Too willingly they give in to illegal requests of the IFPI and block sites for no reason.

Perhaps it’s time for natural selection to take its toll.

[quote]“BitTorrent users are not the problem, they only signal that the ISPs need to upgrade their capacity, because customers will only get more demanding in the future.”[/quote]

Or rather, bitTorrent (level bandwidth usage) is not the problem, it is the future; and any service providers who dispute this are dinosaurs, likely to be toppled by their far-more evolved successors in the near future.

what will the developers do now?, stand by and wait, or place an all Peer Obfuscation in place ASAP, even to other connected peers to hide the users IP etc?.

http://www.theregister.co.uk/2008/02/22/burnham_dcms_filesharing/

http://www.theregister.co.uk/2008/02/22/burnham_dcms_filesharing/comments/

a fully Encypted Muticasting tunnel is looking like a very good thing to many (UK)P2p users right now, will you step up and make it hapen?.[/quote]
[quote comment="295621"]@kami

you say to stop using comcast… sadly, the world is not always that simple. in some areas in the united states, comcast is a monopoly and if you want internet, you get it through comcast. or, you can get dial-up. but i and many other people would rather be beaten senseless (repeatedly) than go back to dial-up. besides, have you ever tried downloading a movie on dial-up? i have, and the beatings get my vote again.[/quote]

what will the developers do now?, stand by and wait, or place an all Peer Obfuscation in place ASAP, even to other connected peers to hide the users IP etc?.

http://www.theregister.co.uk/2008/02/22/burnham_dcms_filesharing/

http://www.theregister.co.uk/2008/02/22/burnham_dcms_filesharing/comments/

a fully Encypted Muticasting tunnel is looking like a very good thing to many (UK)P2p users right now, will you step up and make it hapen?.

you say to stop using comcast… sadly, the world is not always that simple. in some areas in the united states, comcast is a monopoly and if you want internet, you get it through comcast. or, you can get dial-up. but i and many other people would rather be beaten senseless (repeatedly) than go back to dial-up. besides, have you ever tried downloading a movie on dial-up? i have, and the beatings get my vote again.

Of course there is usually at least 4:1 ratio of upstream ports to down ports, but it doesn’t take too many P2P clients uploading content to fill it up.”

I agree, and my main point ,rather than the ease with which you might Encrypt the Tunnel, is its got to be FAR more economical to sent a single torrent/data packet _once_ to say 4 of your peers at a time with Multicasting, than send the same packet 4 seperate times to each unicast peer as now.

a very large saving in MC upload packets with even this basic 4/1 ratio compared to now with unicast.

sure it will take some thought regarding the re-transmission IF a seed didnt get that packet intact,but not that much work.

and every single packet saved is one less to send to the next Multicast peer.

its clear that even a very basic torrent Multicast peering is far better at using the very limited upstream capacity than any unicast peer if you have more than one person in a swarm.

id hope by now that multicasting has a clear advantage over uncast and we should at least consider moving to it.

at the very least, make a basic MC plug-in for AZ and try the Multicasting idea out.

bamboo DHT java code would seem to be a good starting point for any experimental Multicasting plug-in, also the java Mtunnel might get some torrent coders interest for inclusion.

Google: utorrent mpaa

it seems a simple thing to add a finer grained swarm localisation that trys to keep as much torrent traffic inside the local LAN,then WAN,then ISP, then country, and so on, so keeping the ISPs happy and the users happy too as it should improve throughput.

if you then want to wrap all this inside a tunnel to clean it all up for encryption end to end you must also consider adding the Multicasting DHT extension to once again free up masses of bandwidth.

its not about fighting the ISPs, its more a case of getting more for less and a Multicasting torrent extension will benefit everyone, along side encrypted end to end tunnels.

id rather the able bodyed coder would spend time adding and extending the existing JAVA multicasting DHT abd tunnel code to make far better use of my limited upload pipe for the betterment of all torrent users ,than fight the ISP and l loose out anyway, while the payed binary usenet gets bigger and yet forgotten.

will someone please make a client add-in for AZ to use an _encrypted_ _multicast_ _tunnel_ to other clients etc and we can all be happy in a very short time.[/quote]

It’s more than just transport between ISPs, it’s also about using up the limited upstream capacity of DOCSIS. 16-QAM is just 10 Mbps, while downstream at 256 QAM is ~38 Mbps. Of course there is usually at least 4:1 ratio of upstream ports to down ports, but it doesn’t take too many P2P clients uploading content to fill it up.

Exactly: instead of finding workarounds, why not vote with your pocket book? That’s likely to be more effective than identifying work arounds or contacting your legislator.

it seems a simple thing to add a finer grained swarm localisation that trys to keep as much torrent traffic inside the local LAN,then WAN,then ISP, then country, and so on, so keeping the ISPs happy and the users happy too as it should improve throughput.

if you then want to wrap all this inside a tunnel to clean it all up for encryption end to end you must also consider adding the Multicasting DHT extension to once again free up masses of bandwidth.

its not about fighting the ISPs, its more a case of getting more for less and a Multicasting torrent extension will benefit everyone, along side encrypted end to end tunnels.

id rather the able bodyed coder would spend time adding and extending the existing JAVA multicasting DHT abd tunnel code to make far better use of my limited upload pipe for the betterment of all torrent users ,than fight the ISP and l loose out anyway, while the payed binary usenet gets bigger and yet forgotten.

will someone please make a client add-in for AZ to use an _encrypted_ _multicast_ _tunnel_ to other clients etc and we can all be happy in a very short time.

Freeloaders are greedy, selfish idiots that are of no use to anyone.

Lots of respect to the dev team. Didn’t see this coming for some reason.

That’s my worry

Friend of mine got a message from Comcast that told him to stop or His service will be terminated and they listed the Torrent he was downloading.[/quote]
it won’t block them from knowing anything. this is dumb and the developers are wasting their time.

they are reinventing the wheel, if you want to encrypt your connection between tracker – client user HTTPS/SSL

this won’t help out comcast users at all

Friend of mine got a message from Comcast that told him to stop or His service will be terminated and they listed the Torrent he was downloading.

Boo-hoo for the ISP’s. You’re operating under a mistaken impression. Unlike many places around the globe, almost all ISP services in the US are sold to the public as unlimited service. This means that your “users who share files” ALREADY HAVE PAID for the bandwidth they use.

It is not the fault of the customer for taking them up on the unlimited bandwidth that was promised. It is solely the fault of the ISP’s for not taking into account that when they offered unlimited service that some customers would actually expect and use the unlimited bandwidth they contracted and paid for. Now that the ISP’s have been caught with their pants down because they don’t have the capacity to actually deliver the unlimited bandwidth they sold, they choose to blame their customers rather than investing in their own infrastructure to insure that they can deliver what was promised AND paid for.

that is a such a backwards way of looking at it. I already pay my ISP for a certain amount of Down/Up bandwidth. This whole fiasco shows that they have been overbooking bandwidth, probably because they assumed nobody would use what they paid for. I agree that a “scaled” pricing scheme would be one way out of this mess, but to place the blame on the consumer for actually using what they paid for is quite frankly absurd, and makes me wonder if you work for a big Telecom corporation. It is like Greyhound in the States – they’ll sell as many tickets as they possibly can, without concern for how many seats are on the bus. if the bus is overbooked – as they often are – tough shit for the consumer, first come first serve. Does that mean that people who ride the bus a lot should stop doing so? No, it means that the company needs to sell based on real and not infinite supply. If my ISP sells me a certain amount of bandwidth, they have no right to get all pissy when I actually use it. They should use some of their vast profits (not to mention public funds given to them to do just this!) and upgrade their infrastructure to handle the FACT that more and more people are actually going to use the full extent of their broadband connection nowadays.

“Notice of Action under the Digital Millennium Copyright Act

Dear Comcast High-Speed Internet Subscriber:

Comcast has received a notification by a copyright owner, or its
authorized agent, reporting an alleged infringement of one or more
copyrighted works made on or over Comcast’s High-Speed Internet
service (the ‘Service’). The copyright owner has identified the
Internet Protocol (‘IP’) address associated with your Service account
at the time as the source of the infringing works. The works
identified by the copyright owner in its notification are listed
below. Comcast reminds you that use of the Service (or any part of
the Service) in any manner that constitutes an infringement of any
copyrighted work is a violation of Comcast’s Acceptable Use Policy and
may result in the suspension or termination of your Service account.

If you have any questions regarding this notice, you may direct them
to Comcast in writing by sending a letter or e-mail to:

Comcast Legal Response Center
Comcast Cable Communications, LLC
650 Centerton Road
Moorestown, NJ 08057 U.S.A.
Phone: (856) 317-7272
Fax: (856) 317-7319
E-mail: dmca@comcast.net

For more information regarding Comcast’s copyright infringement
policy, procedures, and contact information, please read our
Acceptable Use Policy by clicking on the Terms of Service link at
http://www.comcast.net.

Sincerely,
Comcast Legal Response Center

Copyright work(s) identified in the notification of claimed infringement:

Title: Crysis

Infringement Source: BitTorrent
Infringement Timestamp: 23 Jan 2008 00:09:37 GMT
Infringement Last Documented: 23 Jan 2008 00:09:37 GMT
Infringer Username:
Infringing Filename: Crysis-Razor1911
Infringing Filesize: 6471561394
Infringer IP Address:
Infringer DNS Name:
Infringing URL: http://tv.tracker.thepiratebay.org:80/announce“

____________________
Web Efforts
http://www.webefforts.co.uk

[10:21] ~> telnet torrentfreak.com 80
Trying 66.228.120.206…
telnet: connect to address 66.228.120.206: Connection refused
telnet: Unable to connect to remote host

But at the same second, from my SBC Yahoo DSL, I can read just fine. Somebody please confirm? I’m in Chicago area.

also, they are re-inventing the wheel. if you want to encrypt your announces use SSL. the developers pretty must wasted their time.

“The UDP tracker is better optimized and puts less strain on the tracking server, however it is not supported by all BitTorrent clients. On the other hand the HTTP tracker is supported by all BitTorrent clients, is more reliable for ratio updates, but more of a strain on the server. Neither tracker has any effect on transfer speeds, except that if a user wanted to use a web browser (transfers via HTTP) then the UDP downloads would not be as affected by the increase in local traffic.”

Now you know.

Your stupidity is showing.

Several BitTorrent developers have joined forces to propose a new protocol extension with the ability to bypass the BitTorrent interfering techniques used by Comcast and other ISPs. This new form of encryption will be implemented in BitTorrent clients …