From: Damien.Doligez@inria.fr (Damien Doligez)
To: cypherpunks@toad.com
Message Hash: 49765b078086cecccb700b0509ec4e446c6281196ebd7f31e82204f41cb8752f
Message ID: <9508281844.AA22408@couchey.inria.fr>
Reply To: N/A
UTC Datetime: 1995-08-28 18:45:07 UTC
Raw Date: Mon, 28 Aug 95 11:45:07 PDT
From: Damien.Doligez@inria.fr (Damien Doligez)
Date: Mon, 28 Aug 95 11:45:07 PDT
To: cypherpunks@toad.com
Subject: Re: SSL trouble
Message-ID: <9508281844.AA22408@couchey.inria.fr>
MIME-Version: 1.0
Content-Type: text/plain
>From: Christian Wettergren <cwe@Csli.Stanford.EDU>
>What I wonder is wheter the server congestion really showed that
>the protocol is flawed.
I never meant to say that the protocol was flawed in any way.
I'm sorry if I gave this impression. (I used pretty much the same
protocol on Hal1)
Since I'm not the one who's writing the code, I will not try to tell
you how it should be written, of course.
My point was only that the central server approach does not scale.
When we reach its limit (and it seems we have not reached it yet), we
can use a hierarchical approach, and it is faster than the random one.
But the random algorithm does have its strong points and we should not
dismiss it out of hand. Maybe I got a little carried away in my
advocating of the random algorithm.
(another topic:)
As for the updates to the client software, let me point out that I did
10 different versions of my own client when working on Hal1. Some
machines worked for one week with version 1, while others needed many
updates, due to different network and OS conditions. This is the main
advantage of a well-defined (and stateless) protocol: it allows the
server and clients to be all updated independently while the
computation is running.
-- Damien
Return to August 1995
Return to “Damien.Doligez@inria.fr (Damien Doligez)”
1995-08-28 (Mon, 28 Aug 95 11:45:07 PDT) - Re: SSL trouble - Damien.Doligez@inria.fr (Damien Doligez)