Ämne:RE: [dcdev] ADC already obsolete?
Från:Gustaf Räntilä <[email protected]>
Till:"'Direct Connect developers'" <[email protected]>
[email protected] [mailto:[email protected]] On Behalf Of [email protected] Sent: Friday, February 11, 2005 4:09 PM To: Direct Connect developers Subject: Re: [dcdev] ADC already obsolete? 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.-----Original Message----- From:
Interesting if TCP 'hole punching' works as frequently as they claim, anyway to increase the probability of it working one can: 1) Try TCP hole punching (TCP is always very nice) 2) Try UDP hole punching if TCP didn't work 3) Send the initial UDP-packet to both the other peer and the hub, so that the hub sees the source address, and thereby forward it to the peer(s), and hope that the NAT at least keep the source port, even if it's not the same as the senders local port (which really doesn't matter then).
CTM have a command parameter for this exact reason. The thing we need is a standardized CTCP for control channel via hub, and an additionalprotocolfor such udp traffic. That can be done by merely adding a few commandsto thehub, 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 parameters are involved. One might wish to more tightly integrate this into ADC than a few CTCP-lookalike-commands.
If my third try works, it definitely requires something new from the hub.
DC++ also now supports UPnP, which obviates this in a friendly NAT environment.
Yeah, I made a 5 minute try to incorporate UPnP to my linux netfilter NAT, and I had no luck. I'm not gonna try again ever until it gets natively into netfilter. Until then, manual configuration will do just... hrmpf... 'fine'. Opera-- DC Developers mailinglist http://3jane.ashpool.org/cgi-bin/mailman/listinfo/dcdev