From owner-freebsd-hackers Sat Oct 28 13:03:36 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA16611 for hackers-outgoing; Sat, 28 Oct 1995 13:03:36 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA16598 for ; Sat, 28 Oct 1995 13:03:28 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id MAA00217; Sat, 28 Oct 1995 12:52:43 -0700 From: Terry Lambert Message-Id: <199510281952.MAA00217@phaeton.artisoft.com> Subject: Re: New lmbench available (fwd) To: hasty@rah.star-gate.com (Amancio Hasty Jr.) Date: Sat, 28 Oct 1995 12:52:42 -0700 (MST) Cc: terry@lambert.org, rcarter@geli.com, jkh@time.cdrom.com, hackers@FreeBSD.ORG In-Reply-To: <199510280705.AAA01197@rah.star-gate.com> from "Amancio Hasty Jr." at Oct 28, 95 00:05:58 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1317 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > > #ifdef TERRY_IN_FUTURIST_MODE > > > > You connect to services instead of machines, of course, and the > > underlying transport is permitted to load balance you off onto > > another server. > > Boy isn't this very similar to Novell's service schemes except that > I don't think that Novell provides for load balancing but then > again that is probably not to hard to implement if you can > agree on the metrics... It isn't even remotely similar. Novell's scheme involves NDS, which is a push model for replication. Push models are inherently broken. Also in NDS, you must still get to the server, though you do authenticate to the network. Not "any server", "THE server". Novell's servers have no means of anonymity. Novell's servers must also go to a particular location to look up a resource identity. That leaves the location as a bottleneck. Novell's servers are broken. The closest thing to this is the SGI video servers; but of course, they must be a cluster located in close proximity, not distributed all over the landscape. SGI's servers are broken. Any "soloution" that supposedly "solves" the problem by assuming a larger pipe is broken, IMO. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.