On Sep 13, 2007, at 2:28 AM, David Barrett wrote:
> 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). You are right - lol - but think big - AT&T is just a small company :-) > > 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. > On side note about this, I've been looking for some software to try and test 100k connections on Linux or OSX box - anyone have any suggestions of load generators like this? > 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 _______________________________________________ p2p-hackers mailing list [email protected] http://lists.zooko.com/mailman/listinfo/p2p-hackers
