UPnP ports need to be closed at exit

[snmememe]

BitComet 1.13 WinXP SP2 ADSL2 Billion 7404VNPX

I need all traffic to be terminated (unattended) at a particular time of day corresponding to onset of the ISP's peak period.

BitComet doesn't by itself appear to offer a scheduled means to exit and shutdown the computer, so I have been employing task manager to schedule c:\windows\system32\shutdown -s -t 0.

The main problem that ensues is that when BitComet is told to exit, it does so, but leaves UPnP ports open.

I've experienced several occasions of receiving 1 gigabyte in each hour after my computer has shutdown due to traffic attempting to connect with my shutdown computer through the still open port.

This useless traffic can burn through my quota very quickly.

Please can the UPnP ports be closed gracefully when the program is told to close.

I've also had occasions of receiving huge traffic like 200 KB/s while BitComet 1.12 is operating, but that traffic visible with NetLimiter 2 monitor was barely showing in BitComet at all, perhaps only 20 KB/s. I had the impression that either something was seriously wrong with the peer negotiation or that I was subject to denial of service attack. For a time I reverted to older versions of BitComet, but I think the hazard still occurred some times. I've since deleted all torrents in case one was attracting DOS attack.

Please can I be assured that such download wastage scenarios will be guarded against in new versions.

[kluelos]

I'm afraid that wouldn't help.

A "port" is just a routing number. It's not a physical or virtual device of any kind, not a gate or doorway that you can close,it's just a required number included in a tcp packet. An application like BitComet can register with WinSock (part of your TCP/IP stack) to receive all traffic that has that particular routing number, that "port". A firewall simply blocks or refuses any traffic with a routing number that hasn't been previously allowed under its rules. But the traffic still arrives, whether you accept it or not. It's a little bit like not answering your phone -- that doesn't make the calls stop.

When you terminate a bittorrent client, for whatever reason, there is no way to notify all other peers that you have done so. Most of them will keep trying to send to you, until they themselves re-scrape (re-contact the tracker successfully, report their status and update their list of interested peers), and notice that you aren't on that list anymore. Those other peers will gradually drop away, one by one. But there is no way to notify any of them that you're leaving. The bittorrent protocol does not have any such message code, and there is no way for another peer to know whether your dropoff is temporary or permanent. It will keep trying for a while, then eventually give up on you. If it gives up too soon or too easily, simple network glitches would clobber many of your connections, and your download speed would suffer because of it. You and others would complain, loudly, in shrill, unpleasant voices.

If you quit Bittorrent in an orderly fashion, your client tells the tracker that you're leaving and to take you off of its list of interested peers. Each peer eventually re-scrapes, and gets told by the tracker how long to wait before doing it again. That re-scrape time is usually about 20 minutes but can be a lot longer. It can take a while for the new list to propagate throughout the swarm (for everybody to get the word), especially since some peers will experience timeouts and the like when they try to re-scrape.

If your departure is not orderly (say, you crash or just close the client), then the tracker eventually notices that it hasn't heard from you in quite a while, and drops you from the list. That can take hours, and then the propagation time is on top of that.

All of this means you've got a lot of traffic coming, for at least 20 minutes -- probably a lot longer -- and there's no way for you to stop it, nor anything that BitComet could do to stop it either.

BTW, you shouldn't use programs like NetMonitor unless you thoroughly understand what you're doing and precisely what they're measuring, how, and why. Otherwise they will simply mislead you into a lot of notions you will just have to unlearn later.

[snmememe]

If your departure is not orderly (say, you crash or just close the client), then the tracker eventually notices that it hasn't heard from you in quite a while, and drops you from the list. That can take hours, and then the propagation time is on top of that.

Thankyou for your quick response and insight.

Now certainly I've noticed much improved behaviour if I can "remote in" and push the BitComet red exit button; the traffic cools off quickly.

Is it not possible to do the whole orderely exit business when BitComet receives the message telling it to shutdown. You've got quite a few seconds before forced termination measures start to apply. It would appear that at present no "orderely exit" is performed when BitComet is tapped on the shoulder to exit. Alternatively a self time scheduled (or on completion) process exit and optional shutdown rather than merely suspending tasks temporarily would solve the problem.

I've had to rush home from work early to prevent my remotely monitored download quota from being totally wasted.

Maybe as an interim measure I could use the BitComet scheduler to stop all tasks just before shutdown in the hope that all the trackers would be informed of loss of interest. The current one hour block granuality makes that awkward to use with precision however.

Regarding NetMonitor reported traffic; I was seeing huge real traffic that really was quickly exhausting my ISP download quota, but little of it was contributing to actual file download progress as shown by BitComet statistics. NetLimiter made it clear that the traffic was associated with the BitComet process. Manually restarting with a different port number provided some quick relief, with the rogue other party loosing connection for a while. I also now take the precaution of setting the download rate limit much lower than line capable speed.

[kluelos]

The exact behaviour here is, like much else, not documented. However, I believe that BitComet does at least attempt to contact the tracker with a termination message when asked to shut down.

(That behaviour also caused controversy, because some private trackers were taking the "finished" message to mean that BitComet had somehow magically sucked down the entire torrent in the short time it was connected, so must somehow be cheating and was therefore banned. Some days, you can't win for losing.)

But if the tracker is busy, as they very often are, and BitComet can't get through, then what is it to do?

• Hang the system shutdown until it finally gets acknowledgment from the tracker? That wouldn't be acceptable to anybody.
  
• Just send a packet blindly, via UDP, then go ahead and shut down? If the packet times out, it times out. The tracker may never get the word.
  

I don't know what it actually tries to do (not documented, as I said), but I have seen the system shutdown hang while waiting for BC to close. I suspect that's a defect, unrelated to this issue, and it was many versions ago. I don't know that for certain, though.

Is there any possibility of you changing service providers? Most of them don't try to measure traffic or establish quotas this way, and that would assuredly make your life easier.

[snmememe]

The exact behaviour here is, like much else, not documented. However, I believe that BitComet does at least attempt to contact the tracker with a termination message when asked to shut down.

Is there any possibility of you changing service providers?

No ISP change likely. The bulk of download allowance is offpeak, budget service.

I have the feeling that whatever happens upon shutdown message is inadequate, as evidenced by the fact that the Billion still shows the UPnP ports mapped.

Maybe I have to take your word that those ports remaining mapped in the router isn't the essence of the problem.

Otherwise I would have thought the the Billion would be more inclined to refuse a connection attempt on a weirdo unmapped port and thus speed up the decay of the prior known interested peer. I have the impression that at the moment with the port still mapped, the Billion indeed passes the connection to the computer even though it's turned off. The computer has wake on LAN which means the LED for that Billion switch socket remains active. I havn't been able to disable that, but it might not be relevant.

[kluelos]

I've never been very happy about managing a router with UPnP, because it is, in my experience, unreliable, inconsistent, and if something goes wrong, impossible to effectively troubleshoot. Too much is hidden and uncontrollable. I see what you want to do, and why, and if PnP were more reliable it would work. Maybe there's a better way for you, though.

What you might do is look into an application called "Virtual Private Networking", better known by its acronym, VPN.

This is a network on a network. It uses the internet or an existing network as its transport, but is essentially its own separate network. First you'd set up a VPN "listener", or server, on your home computer. You'd need to give it a port to listen on, which would have to have a permanent open rule in your firewall(s). This is so the VPN server can listen for unsolicited traffic from outside.

You would be contacting this server to log on to your own computer at home, from a VPN client you've installed on your computer at work. Doing this, you would be logged into the LAN side of your home network, virtually sitting at your home computer console. From there you could log into the router's control interface (which naturally isn't accessible from the WAN side of things), and manually close the BitComet port from there whenever you need to. You can also stop and start BitComet or any other application while you're connected. So even if this doesn't solve the basic issue, it should save you any more frantic drives home to fix things.

(VPN's have several applications, but this is what they're intended for -- to get you on *that* side of a network. It's just the reverse of a normal usage, logging on to the work LAN from home.)

This ought to work, and is really simpler than it sounds. At least, I can see it in my head that way. I like and use one named TightVNC, but there are several FOSS VNC applications out there and they all seem to work pretty well. They mostly come with both server (listener) and client apps bundled together, and it's easiest to install the listener as an NT service to autostart with Windows.

Protection is by passworded login, and whatever security simple obscurity gives you -- nobody knows it's there. Generally, since there's no standardized message protocol, you have to use the client/server pair. That's not a big deal, I'm just saying that you might have trouble using one app's listener with another app's client. I haven't really even had occasion to try it myself -- no reason to.