Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
On Wed, Oct 20, 2004 at 11:24:23AM -0400, trlists at clayst.com wrote: > OK, this all makes perfect sense. But I was assuming -- again > definitely not an assumption I tested, it was a casual thought at the > time and not an analysis -- that exchanging packets is typically > relatively fast while waiting for the nameserver to do a lookup is > typically relatively slow. So is making a TCP connection really > "9/10", or not? It depends on the relative speed of the lookup in the > nameserver vs. the packet transit times. Well, I guess it depends. If you look up hosts for which the server is authoritative, then the look-up time will be almost infinitessimally small. That lookup will be done from the server's hash tables, i.e. the server will in most cases be serving the data from its own memory. If, on the other hand, you are waiting for it to query other name servers on the internet, then yeah, that would probably be slow. But if you have control over all this, just use a host for which you know the server should be answering authoritatively. A good choice is localhost, since as someone else pointed out, virtually all properly-configured DNS servers should have an authoritative record for it. The look-up time is negligible in this case -- it's the network I/O that takes all the time. -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail. Sorry for the inconvenience. Thank the spammers. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://lists.blu.org/pipermail/discuss/attachments/20041020/2f090459/attachment.sig>
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |