Slashdot Mirror

probably. bitcomet is the same client without the ad-crap.

Hard disk space that is required if you install Windows XP SP2 from the Windows XP SP2 CD
[...]
1560 MB peak usage during installation
[...]
You must also have 30 MB of free hard disk space on the first primary system partition.

So installing SP2 requires over 1.5GB of free disk space, according to MS's own information. Maybe they're wrong, but I've found it impossible to install it on my 1.9GB drive.

BTW, you say: "I slipstream SP2 into the XP install media". As far as I can tell, this process is illegal. There's nothing in the XP EULA that grants permission to make copies of the installation CD. The fact that various sources both inside & outside MS recommend it as a useful technique is besides the point: it is (at least technically) a copyright violation, and you could be sued for doing it.

As for 30 half-open TCP connections, what is the problem with that? P2P services don't rely solely on half-open connections and perform quite well under SP2 so what's the effective limit? You can't run a server on a desktop OS?

Servers don't typically need all that many half-open connections. Clients that connect to multiple servers for short-lived queries are the main problem. I run a variety of web spiders here, and find that they are substantially slower when run under SP2. As for P2P apps not having trouble with it, why do I see so many of their forums discussing patches that change the limit?

Perhaps why HP home doesn't come with IIS. Are you going to fault MS with that decision as well?

No. But if XP RTM came with IIS but SP2 deleted it, I think I'd have a right to be pissed off. And certainly I think I would have a right to not "upgrade" if I didn't think it was worth it.

Besides that it's incredibly difficult to find a machine which doesn't have enough free space for SP2 since 40gig drives were already well into the norm when XP was released.

Well, yeah... actually I'd slightly disagree, I reckon most entry level machines were being sold with either 10GB or 20GB drives at that time, but it doesn't matter: the minimum specs for XP were basically a 4 year old machine when XP was released: 64MB RAM, Pentium 233 or better, and 1.5GB hard disk. Plenty of people, I'm sure, run XP on machines that aren't a lot better than that. I can't be the only one. That's the reason those are the minimum specs, right, to tell you that if you have a machine that meets them, Windows XP is an operating system you can use on it. Except now it turns out it isn't.

How bout you try again and mention a networking application which isn't feasible which is an end-user application and not a server.

Some P2P apps (try running a gnutella client that was released before SP2 on a SP2 machine; the results will be painful). Anything that downloads web content from multiple servers in parallel and which you expect to finish quickly (e.g., applications that summarize search results). Apparently it can cause issue

Mucking about with things that are new or unfamiliar to you may have deleterious unintended side effects on your system. The same mucking about may also lead you to learn a few new tricks. I personally encourage trying new things but I would also like to strongly recommend that if you are unsure of yourself, practice on a system that is not relied upon for work or school. Missing deadlines can be bad; losing a nearly complete master's thesis can cause you to do things that will land you in jail. By contrast, toasting the install on a completely spare system may just give you an excuse to try the latest Linux/BSD/Solaris install that you've been itching to play with.

With that said.

A google search for "TCPIP.SYS patch" will turn up a little information on this.

The tool I used to change mine was nLite, which allowed me to make the changes to my install media prior to performing a fresh install. The desired setting in this program is in the 'Patches' area.

Another tool is available from a small German website that claims to allow you to change the settings without requireing a complete re-install. I have not tried this tool myself yet (since when I did my last install, this tool did not support x64) so I would recommend that you manually create a backup of your tcpip.sys file and set a windows restore point before you test it.

As for modifying your torrent client. I would recommend trying BitComet and playing with the connection settings paying particular attention to the effects of throttling the Global Upload rate, Max connections per task and max half-open connection settings. Other clients may have similar settings but you'll have to find those for yourself.

Hopefully this information was helpful and does not toast your system.

Yet another feature that BitComet already has. Sadly, I expect Azureus and uTorrent to ignore this fact and implement their own standard. BitComet version 0.62 or 0.63 will probably conform to it. My point is, why doesn't anyone ever seem to know about BitComet's basic feature set? It's obviously a well known client. In fact, the last swarm I was in it was about equal in popularity to Azureus and BitTornado (only a couple people were using uTorrent, and someone was using the official client). If some feature has a possible exploit (like adding the DHT network as a backup in case the private tracker goes down) then everyone is up in arms about it. The useful features seem to go without notice, like UDP NAT bypass (great if you can't recieve incomming connections), an Intellegent Disk Cache (I WANT my torrent client to use more RAM so hard drive writing frequency is kept reasonable), Packet Header Encryption (the feature in question), the ability to share peer information even if the tracker goes down (implemented long before Azureus added DHT networks), sharing peer information between tracker updates (causes faster downloading), chatting with other BitComet users in the swarm, and others.

Good thinking. Except there are two companies that run the high-speed lines here, Rogers and Bell. Ignoring the fact that Bell Sympatico DSL is quite slower than my tier of cable for a moment, what happens if Bell also filters Bittorrent? Are you suggesting that the appropriate course of action then would be to move?

On a more practical note, use port 1720 (used by Rogers' own VoIP digital phone service, so they can't and don't deep packet filter it) and if that doesn't work (remember to restart your client and forward ports accordingly) try BitComet with the encrypted header option. Worked fine for me after a bit of fiddling.

I use Bitcomet now instead whenever possible. Sure it's not geek-friendly (no linux support), but it offers the same stuff as Azureus (that's file selection, advanced options) at a lot less RAM and CPU usage.
I am dissapointed not to see it reviewed here.

how can they review bittorrent clients for windows, without including BitComet (http://www.bitcomet.com? easily the best bt-client for windows

You missed some!

Network

putty for SSH (even commandline SCP which rules), wget for sucking down the web, opera if you don't like firefox, and some form of bittorrent client, like bitcomet.

Utilities

gvim, unxutils or in a pinch some downloads from the gnuwin32 tools, tools from SysInternals.

Multimedia

Don't forget Mediaplayer classic (MPC) which by happy coincedence is included in the k-lite mega codec pack (from codecpack.nl).

Security

grisoft AV, tools from SysInternals.

Apparently BitComet has the ability to encrypt the protocol headers (though, only when talking to another BitComet client) to stop traffic shaping by those ISPs

There are quite a lot of differences in the three major P2P technologies. Here I try to cover the most important of each:

ed2k (eMule)

• + Easy linking. Links can be shared anywhere: in web pages, IRC, email. The single 100-200 character link contains everything that is needed to download the file.
• + Supports usage with and without a server (in eMule, ed2k server and serverless Kademlia)
• - If you run a server, you can't make it private
• - If you run a server, you cannot control what is shared there
• - Inefficient, seems to waste bandwidth

Direct Connect (DC++, Reverse Connect)

• + You can run servers (hubs) private
• + You can see what everyone is sharing in your hub
• + Using eMule-like links has recently become available, though clicking a link doesn't add the file in your queue, it only allows you to search for it
• + Efficient, you can download directly from someone very fast, even through intranet
• - No serverless mode
• - You don't have total control on what is shared in your server
• - Only in Reverse Connect you can download from multiple sources simultaneously

BitTorrent (Azureus, BitComet)

• + The most efficient p2p yet
• + Server (tracker) admin can have total control of what is shared choosing a directory where he uploads allowed torrents
• + A single .torrent file can contain instructions on how to download multiple files
• - No serverless mode
• - No searching
• - To share download instructions for a file(set), you have to be able to transfer a .torrent file, a plaintext link isn't enough

This has been the situation for a while. In ed2k nothing big has changed for a year. DC++ (incl. Reverse Connect) is evolving, but magnet (TTH) linking has been the only major change in years. When DC++ gets its support for ADC complete, the evolution of Direct Connect is predicted to get a major boost.

What trackerless BitTorrent does is to make every client a small tracker. So it doesn't just enable searching and serverless usage, it also makes sharing illegal files easier (more than it does for legal). Previously, to share content, you had to find a tracker that allows posting .torrents. To share copyrighted content, you also had to find a tracker that didn't care about legal aspects. So sharing legal and illegal content is now equally easy, while it previously was (at least in theory) a little bit easier to share legal content.

Overall, the changes of trackerless BitTorrent would still make it the best available p2p techonology. For certain special cases, Direct Connect could be better, and both DC and ed2k support easier linking than BT, but even that can change in the future: BT could implement a meta-p2p engine, so that you could share plaintext links that make your client download the right .torrent file and add it to your queue. This would make BT superior to eMule in every aspect.

I'd recommend the pure C++ BitComet.

Unfortunately BitTornado runs in Python, which can get almost as slow as client-side Java when you have a lot of stuff running. I'd recommend the pure C++ BitComet.

Also, Bitcomet (Windows only)allows UDP-based connections that manage to get around most firewalls. Everyone else can just change the incomming port to something like port 80 or 443 so even heavily firewalled users can connect to them (in most cases).

My university (MSU-Bozeman) uses a firewall that blocks inbound connections. With no inbounds, BT goes slower than turtles screwing(I hardly ever broke 1kB/s)
Anyway, I was looking for a way around the firewall, and I found BitComet. It has a feature call "nat traversal" using UDP that allowed me to get speeds much closer to normal.
Unfortunately, nat traversal only works between bitcomet clients, so the speeds aren't always as good as they could be.

Try it out and make sure to enable the nat traversal option.

Code

NOBODY and I do mean NOBODY writes Java Applets any more. Java Applications are what have been working to displace Windows dominance. A few examples:

Azureus Bit Torrent Client...

I'm with you about the Java Applets. F-U-G-L-Y. However, I'm going to use your post to illustrate my point earlier in this thread about Java. However, I've used Azureus quite regularly on multiple platforms. It's an excellent application. I've also used BitComet, a Windows-only C++ native BitTorrent client. Although the latter is only available for Windows, the performance differences between Azureus and BitComet are astonishing. BitComet's memory and CPU utilization are significantly lower, and from an antecdotal "application snappiness" level, BitComet just crushes Azureus.

This it not to sling mud at all of the Java-lovers out there. Its a fine development package, and definitely has its purposes. The point is that under most circumstances, a lower level language, while generally more expensive to develop, can yield greater performance. To me, this is critical.

This single example clearly doesn't drive the point home, and I've seen studies that tend to show otherwise, but this just provides a single real world example of where a lower-level language-based application can outperform its counterpart. Finally, I don't have a problem admitting (disclaiming) that I'm slightly biased against Java after working on a few Java development projects in the early days and been infuriated by its performance.

Frankly, Bittorrent++'s GUI is too slow for my taste, and I don't think it's based on the latest BT protocol. These are BT clients I recommend:

• Azureus (the best in general)
• BitComet (limit to 1 port, for minimal internet browsing slowdown. But that prob. is why it doesn't have to fastest download performance, although you may have good mileage with a bit of tweaking)
• TheShadow's (one of the oldest "experimental" implementation, a mod of the official BT client with useful featrues)