From owner-freebsd-fs@FreeBSD.ORG Fri Jan 18 10:39:29 2008 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6BDF516A417 for ; Fri, 18 Jan 2008 10:39:29 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 2E84D13C461 for ; Fri, 18 Jan 2008 10:39:29 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id B68C449711; Fri, 18 Jan 2008 05:39:28 -0500 (EST) Date: Fri, 18 Jan 2008 10:39:28 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Rune In-Reply-To: <20080118073445.GA30721@pappardelle.tekno.chalmers.se> Message-ID: <20080118103757.F18977@fledge.watson.org> References: <18CC5A4A2AC36D7FF57615EE@ganymede.hub.org> <478AF6BC.8050604@highperformance.net> <20080114142124.Y55696@fledge.watson.org> <20080116085630.GA32361@pappardelle.tekno.chalmers.se> <20080117080359.U51764@fledge.watson.org> <20080118073445.GA30721@pappardelle.tekno.chalmers.se> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-fs@freebsd.org, Jan Harkes , jcw@highperformance.net Subject: Re: [OpenAFS-devel] Re: AFS ... or equivalent ... X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2008 10:39:29 -0000 On Fri, 18 Jan 2008, Rune wrote: >> Coda worked poorly from behind a NAT, a common property of many development >> environments. > > Unfortunately this is still the case, especially for writing. > > One reading and writing client behind a reasonable NAT implementation is > fine. Several "readonly" ones behind the same NAT are usable. More than the > above is unfortunately not yet ready for production use. > > There is work under way to eliminate the underlying problem, but not near > enough to hold one's breath. Is this because the callback connection sends UDP from the server to the client before the client sends to the server on the same port, meaning it can't get through? If so, presumably we could just teach the client to send a bit of no-op UDP to the server first -- this would limit you to one client per NAT, but that's better than no clients per NAT. Robert N M Watson Computer Laboratory University of Cambridge