Jan Vidar Krey wrote:

On Friday 11 February 2005 14:27, Gustaf Räntilä wrote:

<... Snip UDP port-punching scheme ...>

Yes, this sounds logical, but many NAT routers will rewrite the source port, and the scheme you outlined relies on the fact that the parts are sending to the correct ports which will be opened for a brief window of time (45 seconds is default in Linux at least). In the cases where the source port have been changed by the router, the clients have no way of knowing which port to send to, thus communication cannot be established.

I suspect this happens more frequently on routers when there is high amounts of traffic going on.

Evidently it works fairly frequently; see http://zgp.org/pipermail/p2p-hackers/2004-November/002171.html and the paper it references. This seems work persuing. For others, there's still passive mode.

CTM have a command parameter for this exact reason. The thing we need is
a standardized CTCP for control channel via hub, and an additional protocol for such udp traffic. That can be done by merely adding a few commands to the
hub, so the hub doesn't need to be updated much at all.

It directly concerns the difference between command types A and B; that's fairly fundamental. Further, INF's U[46] parameters are involved. One might wish to more tightly integrate this into ADC than a few CTCP-lookalike-commands.

DC++ also now supports UPnP, which obviates this in a friendly NAT environment.

-cologic