From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 2 11:54:49 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0765F16A4CE for ; Wed, 2 Jun 2004 11:54:49 -0700 (PDT) Received: from santiago.pacific.net.sg (santiago.pacific.net.sg [203.120.90.135]) by mx1.FreeBSD.org (Postfix) with SMTP id E94B043D48 for ; Wed, 2 Jun 2004 11:54:47 -0700 (PDT) (envelope-from oceanare@pacific.net.sg) Received: (qmail 4742 invoked from network); 2 Jun 2004 18:54:46 -0000 Received: from unknown (HELO maxwell6.pacific.net.sg) (203.120.90.212) by santiago with SMTP; 2 Jun 2004 18:54:45 -0000 Received: from pacific.net.sg ([210.24.202.26]) by maxwell6.pacific.net.sg with ESMTP id <20040602185445.QXQA8220.maxwell6.pacific.net.sg@pacific.net.sg>; Thu, 3 Jun 2004 02:54:45 +0800 Message-ID: <40BE226A.4000109@pacific.net.sg> Date: Thu, 03 Jun 2004 02:54:34 +0800 From: Erich Dollansky Organization: oceanare pte ltd User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7b) Gecko/20040409 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Saber ZRELLI References: <40BDF377.4000900@jaist.ac.jp> <40BE05C0.1090807@pacific.net.sg> <40BE092F.9090402@jaist.ac.jp> <40BE0C13.309@pacific.net.sg> <40BE0F0F.6030805@jaist.ac.jp> In-Reply-To: <40BE0F0F.6030805@jaist.ac.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org Subject: Re: suggestions ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jun 2004 18:54:49 -0000 Hi, Saber ZRELLI wrote: > > Erich Dollansky wrote: >>If multiple servers provide the data, it should not matter which server >>provides it. > > > > I see what you mean , you are talking at higher level , It does not have to be at a higher level. > when i mentioned Robust TCP/IP i meant TCP connections in the kernel > network stack level , > the architecture you are talking about is like a middle ware handeling > all TCP/IP connections for a client to multiple servers. > Yes. The client sees only one TCP/IP connection. It also does not see which server provided the real data. > the mechanism is something like buffereing data in the network stack as > prevention for eventual connection problem , when that problem happens > and is detected , the Net. stack will try to reconnect ( while buffering > the user data ) , once the connection is reistablished the buffered data > will be sent and the user wont notice nothing ( if the outage time is > not huge of course ). > It is a bit more complex because as long as one server is able to provide the data the client gets the data immediatly but the software must make sure now that the failed server does not damage data. It is not this simple as it sounds at the start. The other papers will give you some inside information how things like this are done already and it also could give you some ideas to improve them further by hiding the fault-tolerance from the client. Erich