Date: Thu, 03 Jun 2004 02:54:34 +0800 From: Erich Dollansky <oceanare@pacific.net.sg> To: Saber ZRELLI <zrelli@jaist.ac.jp> Cc: freebsd-hackers@freebsd.org Subject: Re: suggestions ? Message-ID: <40BE226A.4000109@pacific.net.sg> In-Reply-To: <40BE0F0F.6030805@jaist.ac.jp> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?40BE226A.4000109>