A free C++ BitTorrent/HTTP/FTP Download Client

Solution

• Open your Norton Antivirus
• Click Internet Worm Protection on your left tab.
• Next, click Program Control on your right tab.
• Locate/browse for BitComet, and delete
• Click the add button on the bottom
• Browse for BitComet's .exe file (By default C:/Program Files/BitComet/ )
• In the next box, click menu (Drop down) –> Permit
• Click ok.
• Re-open BitComet, Norton Antivirus should pop up a new window again asking you to permit/decline BitComet. Click Permit. No new windows should now pop up.

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// —- ==== PeerGuardian/Protowall Conflicts with BitComet ==== 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. —- ==== What is the 4226 issue in Windows XP SP2? ==== 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.
<html><span style=color:Red>Warning:</span></html> 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. —- ==== What are these “_padding_file…” things in the filelist? ==== 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. —- ==== My file download stops at 9x.x%. What can I do about that? ==== There may be several reasons why this happens; up to now, the most well-known ones are as following: * The torrent is out of date without complete BT seeds. Only if someone makes up for the lacking seed or provides a long-time seed, can you complete the download, in this situation. But for video files, 0.y% will not affect much the rest of the file, so you may still be able to play it. * Along with the large files (e.g. video files), there are sometimes other small image or text files contained in the BT task. As there might be no seed or there could be less seeds for these small files (since others may have chosen not to download them), this may prevent your finishing the task. In this case, it's recommended that you do not download (deselect) these extra files. * The torrent maker included by mistake a system file in the torrent (such as thumbs.db or desktop.ini), which in the meantime got updated by Windows. Thus the piece containing the file will fail the hash check constantly. Check for such files in your torrent task and deselect them. * You are getting rubbish (corrupted) data (pieces which fail the hash-check and are discarded). This can occur due to bad peers but sometimes this is also caused by some faulty implementations of NAT on some SOHO routers. Make sure you're not in the DMZ. A firmware update might help. * You are trying to download a fake, “poisoned” torrent. These will keep forever at a percentage close to 100% but never finish, as they keep being fed pieces which fail the hash-check. If many of your peers are stuck at the same percentage as you, you can be pretty sure that you're in that boat. * Old BitComet version bug. BitTorrent clients transfer the torrent content by pieces which have the same size. All the files in a torrent are concatenated and the resulting data bulk split into pieces, the size of which has been appointed at the making of the torrent file. If there is more than one file to transfer, there might be some pieces which contain the tail of file A and at the same time the head of file B. As a result, although all the content of file A was downloaded, the status of the task might keep permanent “99.9% finished” because some content from file B in this piece, has not been downloaded. 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. —- ==== Why do some BT tasks' progress revert to 99.9% from 100% when their download is finished? ==== There are several reasons to why this happens, such as: * taskname.piece_part.bc! was deleted accidentally. There is boundary data which is contained in this file, and hash-check failed when it was deleted. If this was the cause, perform a Manual hash-check upon completion and then restart task to download. * Part of the task's files were deleted (e.g. padding files, .sfv files), after exiting BitComet. At the next login, the remaining file progress will appear as 99.9%. This is caused by hash-check failure, as some boundary data was deleted. The solution is the same as above. It is suggested to avoid the deletion of some files after download but to deselect them prior to download instead, so that the boundary data will be saved in taskname.piece_part.bc!. * Old Bitcomet version bug: Update your BitComet version or hash-check the BT task again, so that it will work properly. —- -Previous Page -Next Page
-Main Index