Path: utzoo!utstat!helios.physics.utoronto.ca!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!mips!bridge2!mdb From: mdb@ESD.3Com.COM (Mark D. Baushke) Newsgroups: news.software.nntp Subject: Re: nntpd questions Message-ID: Date: 5 Feb 90 02:37:56 GMT References: <1990Jan31.222330.8870@ucselx.sdsu.edu> Sender: news@bridge2.ESD.3Com.COM Followup-To: news.software.nntp Organization: 3Com Corp., Mountain View, CA. Lines: 32 In-reply-to: wisner@hayes.fai.alaska.edu's message of 5 Feb 90 00:32:58 GMT On 5 Feb 90 00:32:58 GMT, wisner@hayes.fai.alaska.edu (Bill Wisner) said: Bill> tale@cs.rpi.edu (David C Lawrence): David> From your example it looks like getpeername() isn't picking up David> the name of ucsd.edu; this happens sometimes though someone David> more knowledgeable than I about lower level network interaction David> can explain why better than I can. Bill> Happens to me all the time. I am on the losing end of a 600ms Bill> satellite link to Seattle; this places me in an Internet backwater. Bill> Now, say I want to FTP to uunet. I connect to uunet and its FTP server Bill> tries to figure out my hostname. uunet's nameserver sends a query to Bill> alaska's nameserver, but uunet times out before alaska's response Bill> arrives. The FTP server then is not able to figure out what site I'm Bill> at and it tells me to get lost. But, the response from the alaska Bill> nameserver DOES make it to uunet; uunet's nameserver promptly caches Bill> that response, and the second time I try everything is peachy. Bill> Anybody with slow links to the rest of the Internet is prone to this Bill> problem. Bill> w. Sounds to me like you should get a secondary nameserver which is 'closer' to the NFSNet backbone. Redundancy of DNS information makes life much simpler. At the least, try finding a secondary site on the East Coast or in the South somewhere at the 'other end' of the Internet from you to avoid worst case delay for name lookup. -- Mark D. Baushke mdb@ESD.3Com.COM