From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <7e38167c7e140e20a8c47d19c9f0ffbb@plan9.bell-labs.com> From: David Presotto To: 9fans@cse.psu.edu Subject: Re: [9fans] Speaking of routing.... In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-yliiqvquutiwzrycasfjxqcyss" Date: Thu, 13 Feb 2003 19:32:04 -0500 Topicbox-Message-UUID: 5e750e90-eacb-11e9-9e20-41e7f4b1d025 This is a multi-part message in MIME format. --upas-yliiqvquutiwzrycasfjxqcyss Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit As for the delay, there wouldn't be one if your inside dns server came back quickly with a nonexistant domain response. However, if it comes back with an address that won't work in the inside or doesn't come back, you're stuck with the timeout. --upas-yliiqvquutiwzrycasfjxqcyss Content-Type: message/rfc822 Content-Disposition: inline Received: from plan9.cs.bell-labs.com ([135.104.9.2]) by plan9; Thu Feb 13 19:22:22 EST 2003 Received: from mail.cse.psu.edu ([130.203.4.6]) by plan9; Thu Feb 13 19:22:19 EST 2003 Received: from psuvax1.cse.psu.edu (psuvax1.cse.psu.edu [130.203.23.6]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 92FB219AB9; Thu, 13 Feb 2003 19:22:09 -0500 (EST) Delivered-To: 9fans@cse.psu.edu Received: from plan9.cs.bell-labs.com (plan9.bell-labs.com [204.178.31.2]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 0DE9219AB8 for <9fans@cse.psu.edu>; Thu, 13 Feb 2003 19:21:28 -0500 (EST) Message-ID: From: David Presotto To: 9fans@cse.psu.edu Subject: Re: [9fans] Speaking of routing.... In-Reply-To: <200302140017.h1E0H4M24547@augusta.math.psu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: 9fans-admin@cse.psu.edu Errors-To: 9fans-admin@cse.psu.edu X-BeenThere: 9fans@cse.psu.edu X-Mailman-Version: 2.0.11 Precedence: bulk Reply-To: 9fans@cse.psu.edu List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.cse.psu.edu> List-Archive: Date: Thu, 13 Feb 2003 19:21:27 -0500 Actually, dial does currently dial /net first and then /net.alt. It's a hack I've never been too proud of but I like it better than changing every single service to check where the call is coming from, mistakes there are too easy. --upas-yliiqvquutiwzrycasfjxqcyss--