Solution
If BitComet appears to be using a lot of your PC's memory (or even gradually using a lot of your PC's memory), you must uninstall Nvidia's firewall. Disabling the firewall will be of no use, as it continues running in the background (i.e. in Processes).
This issue is not inflicted by BitComet, it is Nvidia's firewall that is causing the problem.
Sources from http://forums.nvidia.com/lofiversion/index.php?t2682.html
Please check in the logs for the next URLs:
ip-us.bitcomet.org: 221.130.193.23-221.130.193.23
ip-us.bitcomet.org: 221.130.193.33-221.130.193.33
ip-us.bitcomet.org: 221.130.195.221-221.130.195.222
ip-us.bitcomet.org: 221.130.195.224-221.130.195.226
torrent-cache.bitcomet.org: 221.130.195.227-221.130.195.227
torrent-filehash.bitcomet.org: 221.130.195.229-221.130.195.229
torrent-filehash.bitcomet.org: 221.130.195.231-221.130.195.231
inside-stats.bitcomet.com: 221.130.199.139-221.130.199.139
inside-stats.bitcomet.com: 222.73.227.222-222.73.227.222
and allow them. Your problem will be solved.
Windows XP SP2 limits the number of simultaneous TCP connection attempts to 10, at any given moment. If there are more concurrent TCP connection attempts, Windows generates a warning: “EventID 4226: TCP/IP has reached the security limit imposed on the number of concurrent TCP connect attempts”. You can go to XP's Admin tool, Event Viewer, look in the System tab and notice tcpip entry (appears beside a yellow warning sign).
The detailed description can be found in Microsoft documentation:
Event 4226, EVENT_TCPIP_TCP_CONNECT_LIMIT_REACHED
In Windows versions beginning with XP SP2, there are 10 concurrent TCP connection attempts allowed simultaneously. Additional connections are placed in a queue, and will be opened no more than 10 at a time, until the target number of successful connections is reached. Windows versions prior to Windows XP SP2, did not have this limit.
Cause of this issue
The limit was added to prevent computers from unknowingly being used in a type of Denial-of-Service attack known as a “Syn Flood”, in which your computer sends an endless stream of connection requests (SYN's) to another computer. (A SYN that has not yet been followed up on is a half-open connection.) This barrage of SYNs fills up all of that computer's “slots” for incoming connections, so it cannot respond to anyone else until those slots are cleared.
Your computer never follows up on any of these requests, it just keeps sending more SYNs. The attacked computer gradually times-out uncompleted requests and reopens its slots, but your computer just fills up those cleared slots with more SYNs. The result is that nobody else can find an open slot to connect to on that computer.
Thus the denial-of-service.
By limiting the rate of half-open connections your computer can have pending (the number per second of SYN requests you can have that haven't been converted to fully-open), you give the attacked computer time to clear its slots before you can re-attack them. Other computers will have a chance to find an open slot and connect.
No legitimate software application should ever behave this way for any reason, or need to start so many connections unless it's attacking another computer. Do not attack other computers. This usually happens when you've been zombied and taken over by malware, because you were careless about your firewall.
This half-open limit won't affect the speed of your torrents. Connection attempts from you will open at a steady rate of about 10 per second, until your target of successful connections is reached (which, in almost all cases, will be less than one minute). Altering this setting should only be done by expert computer users, who have a specific reason for making this change.
The Pedantic Part: A connection attempt (half-open connection) is an attempt to connect to another computer. If the TCP connection is accepted and confirmed (it's a three-part process) (don't ask), it is no longer “half open”, as it becomes a completed TCP connection. If there is no response or no response to the response (we said, don't ask), the connection will remain in the “half open” state, until a time-out occurs (usually a few seconds) and the connection attempt is dropped (disconnected). The slot on the receiver becomes ready to accept another request for connection.
Event 4226 Report, when generated by normal use of BitComet, is NOT a problem and is an expected, normal occurrance.
Warning: Recent versions of BitComet include a patch which can alter your system's tcpip.sys file, to change this rate limit. We strongly recommend this only be attempted by computer professionals, and only if there is a specific reason for wanting to change said limit, as it could cause problems, or make the system become unstable. Use this at your own risk. Don't ask for help recovering from it, they'll only laugh at you.
When downloading a BT task where not all of the files are selected, BitComet must create a file containing boundary data. This data will be saved at present time, in a special file: taskname.piece_part.bc!
BitTorrent clients exchange data which has been broken down into small pieces, not entire original files. Often, one or more of these pieces may span over two or more files, making it necessary to download parts of a file that was not selected to be downloaded. In order for the selected files to be fully downloaded and pass a hash check, this excess data must be present, and will be stored in this additional file.
BitComet versions prior to v. 1.02 do not use this type of boundary data file (taskname.piece_part.bc!) and could, in some cases, cause valid files to fail a hash-check, if the task properties have been altered, or the files are manually hash-checked.
This file (taskname.piece_part.bc!) must be present as long as the task is active in BitComet (as well as if, in the future, you need to reseed the torrent). It's not required, in any way however, with regards to the usage of the files after downloading.
However, prior to introducing this feature, in version 0.85 and latter, BitComet introduced the Align File to Piece Boundary option in the torrent making dialog. This option assures the torrent's author that no single BT piece will span over two or more files, by the use of padding files. This are files created by Bitcomet, which have the exact size of the remaining unoccupied space in every piece that holds the last data chunk from the end of a file. Thus, the remaining chunk from the end of the file plus the padding file will occupy the whole piece and the padding file will end exactly on piece boundary. Since in versions v.0.85 and latter, BitComet conceals and skips these padding files, they are transparent to the end user when it looks at the contents of a torrent in BitComet. But in older versions (as well as in other clients) they are visible, hence the reason why you see and have to download these files. That is also why the advice to upgrade to the latest version appears, in order to avoid seeing and downloading them. Nevertheless you'll still be able to download such torrents with versions older than v.0.85 or with a different client, but you'll have to cope with the presence (annoying for some people) of the padding files in your user interface and on your disk.
For some additional details on piece boundary related issues, refer to the next topic, too.
There may be several reasons why this happens; up to now, the most well-known ones are as following:
This problem has been solved in 0.85 and above versions. It's suggested that you update BitComet to the latest version. Or stopping and restarting the task manually, might work.
There are several reasons to why this happens, such as: