Thanks for the suggestions! More comments inline: > -----Original Message----- > From: Cullen Jennings > Subject: Re: [p2p-hackers] Dynamic DNS as rendezvous service > > One of the issues you need to consider is what wold be the expiry > time on your DNS lookups. I understand some of your later proposal > would imply basically zero but talking to the dyndns folks, if we had > 50 million clients all doing a few calls a day - they sounded pretty > concerned about the load that would cause with a really low TTL. I'm > not arguing one way or the other here other than this is part of the > design that would need consideration.
50M users making a few calls a day? Er, that's a pretty extreme example accounting for a significant fraction of global telecom (AT&T only does like 300M calls/day to put that into perspective). I'd *love* the problem of having 150M paying customers (generally only 1/3 of users are active at any point in time). I expect if you work out the actual numbers of servers you'd need, you'd find the cost/user very tolerable -- especially if you're buying hardware, bandwidth, and datacenters on that scale. > > 1) Problem: When you resolve my domain name > > It might be easier to just use SRV records and your client could > upload the IP and port - no change need to SIP clients reading the > record. Good suggestion, thanks. This makes way more sense than TXT records. > > > 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. > > I've got no good idea on how to deal with this but if you keep a > persistent TCP connection back to the DNS server - you have made the > DNS server have many of the scalability problems of just running a > SIP proxy. Scalability is not as big a problem as everybody seems to make it out to be. It really, truly isn't. A cheapo $100/mo Linux box can handle a hundred thousand of simultaneous TCP connections. If you can't get a business model that generates at least $0.001/user/mo, then you've got bigger problems than technology. Regardless, the point isn't to solve the (nonexistent) SIP proxy scalability problem, it's to make a simple extension to DNS such that it continues to do what it's meant to do (resolve names to IPs in an authoritative manner) with 100% backwards compatibility, while also adding IP roaming and NAT penetration. > > 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. > > The mDNS is a good idea - the problem I see with it is that if I am > on the same subnet as someone trying to call you, I might be able to > high jack your calls depending on how the rest of your security > works. This may or may not be a big deal depending on the use case. Totally agree, mDNS isn't secure. But it seems to do well enough in the places it's actually used in the real world. -david _______________________________________________ p2p-hackers mailing list [email protected] http://lists.zooko.com/mailman/listinfo/p2p-hackers
