Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 48789 invoked from network); 20 Jan 2009 03:05:44 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 20 Jan 2009 03:05:44 -0000 Received: (qmail 66481 invoked by uid 500); 20 Jan 2009 03:05:43 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 66437 invoked by uid 500); 20 Jan 2009 03:05:43 -0000 Mailing-List: contact dev-help@directory.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Apache Directory Developers List" Delivered-To: mailing list dev@directory.apache.org Received: (qmail 66428 invoked by uid 99); 20 Jan 2009 03:05:43 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 19 Jan 2009 19:05:43 -0800 X-ASF-Spam-Status: No, hits=1.2 required=10.0 tests=FS_REPLICA,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [64.71.152.235] (HELO lirone.symas.net) (64.71.152.235) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 20 Jan 2009 03:05:34 +0000 Received: from [76.91.220.157] (helo=[192.168.1.23]) by lirone.symas.net with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1LP6vR-00011R-38 for dev@directory.apache.org; Mon, 19 Jan 2009 19:05:13 -0800 Message-ID: <49753F63.8070101@symas.com> Date: Mon, 19 Jan 2009 19:05:07 -0800 From: Howard Chu User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.9.1b3pre) Gecko/20090115 SeaMonkey/2.0a1pre Firefox/3.0.3 MIME-Version: 1.0 To: Apache Directory Developers List Subject: Re: [Replication] Using time offsets instead of absolute time References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Alex Karasulu wrote: > Hi all, > > The first thread on replication after Emmanuel's comments started taking > a turn towards the question of time synchronization across replicating > servers. Time synchronization is very nice to have and forget about > while writing the code around replication. And yes we do not have > control over it since administrators can fudge this up. > > Another alternative would be to have all the servers in the cluster > communicate with one another on occasion to share their current time to > establish offsets. These offsets (differences in time) between servers > in replication agreements can be used to correct for any time variance > we might encounter. Furthermore if the time is adjusted on the hosts, > the cluster can adjust to time changes. > > WDYT? Doing this accurately requires the same amount of work as NTP, to factor in network roundtrip delays etc. In one of my prior jobs I took this route for a Kerberos client implementation on Windows. (Which, if you're curious, is used by Eudora...) Since Kerberos would refuse to authenticate a client if its clock was more than 5 minutes different from the server, we simply recorded the clock offset of each KDC in the client. But - wtf - we had to use SNTP to maintain the offsets anyway... -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/