Traffic hitting firewall

[davidesharpe]

Hi,

Can anyone answer this ?

My BitComet client is behind a firewall/router, and is unable to have portforwarding allowed and so cannot "listen" on a port. I'm not TOO worried abou the speed issue, as i can live with this. but what i wish to know is how many other clients or whatever will be atempting to connect to me from outside directly, despite not being able to listen out for them ? and so how much useless traffic/attempted connections will be on my bandwidth ?

I have turned listening off in the client, but i'm not sure if this will stop attempted remote connections occurring or not.

Thanks for any help/explanations that will be of help to me.

[The UnUsual Suspect]

Generally the comunication part of even a very active torrent is far below 1kBs (from what I've observed). So I don't think this will use up much of your bandwidth.

As for listening port, if you could forward your port, it would make a big difference in your download speeds.

Suspect

[kluelos]

I'm not very clear on why this should be a concern, which makes me think that I don't understand some part of your question.

It sounds like you're very concerned about traffic hitting the firewall. This shouldn't normally be an issue, as that's what a firewall is for. Is this traffic going to trigger some sort of security alert for you?

If that's the case, I'm not sure anybody can give you a good answer. It depends on more than just BitComet. If listen mode is disabled, what exactly is sent out in the PORT field of the metafile? The spec doesn't say it's optional, and doesn't prescribe any specialized behaviour (e.g., if it's zero or blank, nobody try). The tracker may not even allow it. Worse, that may differ from tracker to tracker. Then it depends on what all the other clients do in reaction to this. The answer to these is: I don't know, and I don't know anybody who does.

In the normal course of things, if you've got a blocked listen port all that happens is that unsolicited requests bounce off your firewall. As time goes by, each individual swarm member tries often, then fades away to rarely. But new swarm members can potentially join all the time, and they'll start trying to connect when they join.

There may be something in particular implementations that handles this better, but there's no easy way to find out: source isn't available for anything except Azureus and a few other open-source clients, and the developers of the others are notoriously difficult to contact. Even if there is, you have lots of other implementations to worry about.

If it's a huge concern then I'd suggest using something besides bittorrent.