> -----Original Message-----
> From: [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.

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 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.

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