Have you consider using Avahi? http://www.avahi.org/wiki/AvahiWalkOfFame
-E P2P SIP https://sourceforge.net/projects/viasip/ On 9/9/07, David Barrett <[EMAIL PROTECTED]> wrote: > > So we've talked a lot about how dynamic DNS / mDNS could be used in a P2P > system as the backbone of a global naming system (after all, that's > precisely what it's designed for). However, it falls down in the presence > of NATs, especially restricted or symmetric NATs. But I'm wondering if > there are a couple minor extensions we could make to get around that > restriction. > > > > First, as background, the basic plan is this: > > > > - I install some P2P client (eg, a VoIP client) > > - I buy a DNS name (eg, "quinthar.com') from any dynamic-DNS > provider (eg, DynDNS) > > - I enter my desired user name into the client (eg, > "dbarrett.quinthar.com") > > - My client uses STUN and figures out my LAN and NAT IP addresses > > - My client registers my current IPs with my dynamic-DNS provider > > - My client listens for mDNS resolutions on > "dbarrett.quinthar.com" > > - You run some P2P client > > - You type my name (dbarrett.quinthar.com) in > > - Your client does a 100% standard DNS resolution on my name > > o If we're on the internet, my dynamic DNS provider responds to you > > o If we're on an ad-hoc LAN, my client responds to you via mDNS > > - Either way, your client gets my latest LAN/NAT IP addresses and > tries to connect in parallel > > - Now, it'll work some of the time: > > o If I'm not behind a NAT or firewall, then you can connect to me > directly > > o Likewise, if we're on the same LAN (even if it's ad hoc), my > client will hear your mDNS broadcast for "dbarrett.quinthar.com" and will > respond accordingly > > - But if we're separated by a NAT you can't connect to me > because: > > o You don't know what port I'm listening on > > o Even if you did, I probably have a restricted-cone NAT that > blocks you > > > > So first, before proposing my solution, let me rant on why this would be > so awesome: > > > > - Doesn't require inventing new protocols from scratch > > - Works both on and off the internet > > - Seamlessly supports static and dynamic IP addresses (fixed and > mobile VoIP) > > - Leverages an existing, proven backbone (the global DNS network) > > - Is decentralized in the way that matters most: between separate > legal entities (dynamic DNS providers) across separate international > jurisdictions > > > > But, currently, the above system has the following problems, to each of > which I propose a solution: > > > > 1) *Problem:* When you resolve my domain name (dbarrett.quinthar.com) > you get back my IPs, but not which port I'm listening on. Thus it only > works if we agree a priori on which port to use (much like HTTP has reserved > port 80 from the IANA, we'd need to do the same for our VoIP protocol). This > isn't so bad, but completely screws up any sort of port-hopping approach, as > well as any port-mapping applied by a NAT. > *Solution:* When my client uploads its latest IP addresses to the dynamic > DNS provider, it also provides the port being used on each IP address. Then > the dynamic-DNS provider creates a TXT record for each IP listing which port > to use. So, clients attempt to listen on a well-known port, and clients who > aren't looking for these TXT records won't need them. But if you can't > listen on a well-known port (or are behind a NAT, clients can use the TXT > records to figure out which port you're on. And clients that aren't > expecting the TXT records will simply ignore them. > > 2) *Problem:* If behind a restricted-cone NAT, even knowing my IP > and port is insufficient to connect to me – I also need to be connecting to > you at the same time. > *Solution:* This solution is broken into three sub-parts: > > a. When my client uploads its IP/ports to the dynamic DNS provider, > it maintains a persistent TCP connection such that the server can > communicate back to the client at any time. > > b. Rather than resolving my domain (dbarrett.quinthar.com), you > actually resolve a subdomain that encodes your own IP addresses and ports. > This communicates to my dynamic DNS provider your IP address and port > without requiring any changes to the DNS protocol, or any DNS stack > implementations > > xxx.yyy.zzz.www.port.dbarrett.quinthar.com > > c. Bringing these together: when you resolve my domain using an > encoded IP:port "backchannel", my dynamic DNS provider notifies me via the > persistent TCP connection, basically saying "hey, somebody at > xxx.yyy.zzz.www:port just resolved your name; you might want to try to > connect to it so he can get through your NAT". > > > > So this requires two changes to the dynamic-DNS server: > > > > 1) Record a port mapping for each IP address and respond to DNS > resolutions with a TXT record for each > > 2) Maintain a persistent TCP connection with the dynamic-DNS client > in order to notify it when people try to resolve its address. > > > > Both of these changes are fully backwards compatible. Existing DNS > clients that don't expect the extra TXT fields will simply ignore them. > Existing dynamic DNS clients that don't provide port information just won't > get the TXT fields. Likewise, if they close the resulting TCP connection, > no problem. > > > > However, with these changes, you can use the regular DNS/mDNS > infrastructure as a massive, legally-decentralized, technically-distributed > rendezvous service that seamlessly works both on and off the internet, and > seamlessly supports both fixed and dynamic DNS names and IP addresses. > > > > Where are the holes? > > > > -david > > _______________________________________________ > p2p-hackers mailing list > [email protected] > http://lists.zooko.com/mailman/listinfo/p2p-hackers > >
_______________________________________________ p2p-hackers mailing list [email protected] http://lists.zooko.com/mailman/listinfo/p2p-hackers
