"Banning" client?

[seaweb]

I guess there is a new admin at Static-Subs, who has posted a list of banned clients, with what read like kinda snooty reasons.

Anyone else have this problem with Static-Subs? I'm running the latest version of the Original, and I guess it just isn't ::good:: enough.

Too bad. Is this unreasonable...or just another of Life's "challenges?"

But I really would like to have the last episode of Wind: A Breath of Heart...

[Shii]

BT Official 3.4.1 and older - Enhancements from newer clients are required for proper communication with the tracker.

Sounds like a terrible tracker

Just get ABC for the moment, he doesn't seem to have a problem with that.

[AnimeOni]

Actually, it's a properly configured tracker.

Newer trackers limit this to prevent leeching and allows for compact announce.
- Leeching clients such as G3Torrent and older hacked clients are no longer able to connect. People are required to actually share files instead of just leech. This promotes the benefits to everyone.
- Compact header announce allows for lower loads on the server. This allows more people to connect and reduces overhead costs of maintaining a site.

There are many other benefits but I guess there were too many abuses and costs overrun that forced the admin to do this.

Since you are using the original bt, you must be using a very outdated version. The latest build is the current build which is supported. The older 3.1 and older can crash the tracker.

BTW S-S hosting server has this restriction for a long time so it's nothing new.
________
Celebrity

[Supersonic]

Originally Posted by AnimeOni

Actually, it's a properly configured tracker.

Newer trackers limit this to prevent leeching and allows for compact announce.
- Leeching clients such as G3Torrent and older hacked clients are no longer able to connect. People are required to actually share files instead of just leech. This promotes the benefits to everyone.
- Compact header announce allows for lower loads on the server. This allows more people to connect and reduces overhead costs of maintaining a site.

There are many other benefits but I guess there were too many abuses and costs overrun that forced the admin to do this.

Since you are using the original bt, you must be using a very outdated version. The latest build is the current build which is supported. The older 3.1 and older can crash the tracker.

BTW S-S hosting server has this restriction for a long time so it's nothing new.

hmm...I always was told that it really isn't the bandwidth that does you in, it's the hardware (many trackers eat up a lot of system resources, but I hear bandwidth usage is surprisingly minimal)

and I imagine compact announce does nothing to alleviate that (can someone explain to me in depth what compact announce is? I understand it's a way of announcing without eating up so much bandwidth, but can someone get more into detail than that?)

[AnimeOni]

A normal announce can take 3K of traffic per transaction. A compact announce can be around 300 bytes. If you multiple by 2000 hosts, this is a great deal of bandwidth and if you multiply by multiple torrents, then it can be even greater. On top of this, there's also the peer_id_mode and other data that is sent to the tracker about who you are and what you have and what you need. This is also known as the scrape data. You may see scrape errors from time to time. This data is also compressed and saves bandwidth.

Now if we talk about gzip compression, this can work inversely so some trackers sharing a lot of small torrents would not benefit from gzip compression. For those sites that have a lot of big torrents, gzip will come in handy.

An easy experiment you can do is to compress a 300K txt file using gzip. It will be compressed to at least 10:1 ratio or better.

When we bring compression into the mix, the client (you), will have to do more compression. I can go into detail but think of the data being sent as a $string vs array[] matrix. Your system will need to extract the information for every scrape.

If you take a look at the data being provided by a.scarywater.net, you will get the point as to why hosts are using compact announce.

From a.scarywater.net
In total, we have seen 3500679233 announces with an average size of 674 Bytes, 2450785641 of which gzip-encoded. Scrape was called 493467305 times, with an average size of 639.00b.

If you do the math, this is about 5GB/s of traffic.
________
Daihatsu yrv history

[Supersonic]

Originally Posted by AnimeOni

A normal announce can take 3K of traffic per transaction. A compact announce can be around 300 bytes. If you multiple by 2000 hosts, this is a great deal of bandwidth and if you multiply by multiple torrents, then it can be even greater. On top of this, there's also the peer_id_mode and other data that is sent to the tracker about who you are and what you have and what you need. This is also known as the scrape data. You may see scrape errors from time to time. This data is also compressed and saves bandwidth.

Now if we talk about gzip compression, this can work inversely so some trackers sharing a lot of small torrents would not benefit from gzip compression. For those sites that have a lot of big torrents, gzip will come in handy.

An easy experiment you can do is to compress a 300K txt file using gzip. It will be compressed to at least 10:1 ratio or better.

When we bring compression into the mix, the client (you), will have to do more compression. I can go into detail but think of the data being sent as a $string vs array[] matrix. Your system will need to extract the information for every scrape.

If you take a look at the data being provided by a.scarywater.net, you will get the point as to why hosts are using compact announce.

From a.scarywater.net
In total, we have seen 3500679233 announces with an average size of 674 Bytes, 2450785641 of which gzip-encoded. Scrape was called 493467305 times, with an average size of 639.00b.

If you do the math, this is about 5GB/s of traffic.

wow...but about the issue I brought up earlier, how does the scarywater hardware handle all these announces? I always thought that that hardware would always be the choking point as far as tracker quality, and not bandwidth

anyways, yeah, I understand what you're saying about compact announce now...but what all data is contained in your announe, i always thought it was just the info hash and your IP address, and the tracker just returned to you the IP addresses of everyone else using that torrent (determined, of course, by the info hash you provided the tracker

of course, a whole lot more would have to be in this announce for it to run in the range of even 300B. asumming 4 bytes per IP addy, 300B would be 75 Peers given in each announce. I appreciate your thorough explanation of compact announce, but now you've just peaked my curiousity even further.

[AnimeOni]

From what I see, they are running on a hosted dedicated server using Apachee 1.327.

I found some more info but as a personal policy, I am not going to disclose this info.
________
Bmw k1200lt

[Supersonic]

Originally Posted by AnimeOni

From what I see, they are running on a hosted dedicated server using Apachee 1.327.

I found some more info but as a personal policy, I am not going to disclose this info.

lmfao, info meaning...?

[Kawaii_tsunami]

maybe someone with the same client is hammering the tracker (im probably wrong...>.> hopefully)

[Shii]

Originally Posted by Supersonic

lmfao, info meaning...?

meaning he looked it up on netcraft.com

[hhaamu]

Originally Posted by Supersonic

of course, a whole lot more would have to be in this announce for it to run in the range of even 300B. asumming 4 bytes per IP addy, 300B would be 75 Peers given in each announce. I appreciate your thorough explanation of compact announce, but now you've just peaked my curiousity even further.

First of all: Let me correct AnimeOni's terms. compact announce = gzip-compressed announce. The standard client offers this bandwidth-saver since 3.2. The trackers send the announce data normally as a bencoded string, but apply a gzip compression there (think: "Content-Encoding: gzip" in HTTP header terms)

Second, I absolutely hate trackers that ban clients based on their version string. While I do agree that banning to some extent is good (mainly the leecher clients and maybe the old standard clients (<=3.1)), I've had nothing but trouble with them (tracker seemingly randomly rejecting my client no matter how new it is or what "brand" it is). It also appears that some trackers ban every client but those that are on its allowed list =(

I guess the OP needs to upgrade to azureus or bittornado (maybe for this torrent only). Those, to my knowledge, are the clients that least often end up in the bans list.

[subcool]

Compact announces are HEX coded =P

while we're on this topic
does anyone have a list of BT clients that like to hammer trackers with announces?
i consider it hammering if a client sends more than 1 announce each (half)hour.

Im already gonna block G3Torrent cause its just a leeching client =P

[AnimeOni]

I would definately block G3Torrent - no questions about it!

I would block these also....

BitComet - annoucing errors and generates a lot of bad data. It's also a favorite for Asian users so you might be blocking a lot of leechers...um...sharers.

BT++ - Old and generates a lot of bad data

Shad0w - the 5.x core does not support gzip headers so it can generate a lot of traffic on your host and some hacked versions can hammer your tracker.

Also, I would, in general, block older clients. Older Azureus, official, and bittornado. since new technologies have better implementations and compression to reduce overall load and traffic to your server.

I think Static-Subs (first post)'s host forums have the similar list of banned clients but I cannot confirm since I cannot remember their board URL.

[Kam_Islash]

I have a relevant question:

Where can one get the Mac version of the new build of the original bt?

I recently had the banned client problem as well.

///

[AnimeOni]

There's actually no 'original' client for the mac. There's quite a lot of 3rd party applications.

For the Mac, I strongly recommend Azureus. The GUI is identical to the PC/LINUX builds and is very easy to install and use.

If you want something that looks like the original, I think Tomato Torrent will fit this bill.

[Kam_Islash]

But...
my client is actually CALLED BitTorrent.

///

[AnimeOni]

Originally Posted by Kam_Islash

But...
my client is actually CALLED BitTorrent.

///

My bad, haven't used the Mac for a long time. Went back and checked from Bram's website.

Get the original mac client here.
http://prdownloads.sourceforge.net/b...2.dmg?download

I would still go and get Azureus since it allows you to limit BW and avoid the many pitfalls many users here have seen.