[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [coldsync-hackers] [PATCH] removing lastsync PC dependency onhost's IP



On Fri, 17 Aug 2001, Dan Pelleg wrote:
> Andrew Arensburger writes:
>  > On Tue, Aug 14, 2001 at 02:33:41PM -0400, Dan Pelleg wrote:
>  > >  Details: the last PC is stored in ~/.palm/lastsync, and is incremented
>  > > with each sucessful sync. If this file is missing, a random 32-bit number
>  > > is used. As was done previously, a mismatch in the ID will force a slow
>  > > sync. Once the ~/.palm hierarchy is copied from one host to another, so is
>  > > the file lastsync, and subsequent syncs in either the copier or copyee will
>  > > be fast. I tested this in both standalone and daemon modes. Systems tested
>  > > on are RedHat Linux, and FreeBSD 4.4-PRERELEASE.
>  >
>  > 	Sorry, but this strikes me as a hack. I'd much rather
>  > 	a) Fix the config file to allow you to set the host ID in the
>  > config file. This should solve the problem of DHCP clients with
>  > transient IP addresses.

>  It also has the advantage that the user
> needs not set up any config entries themselves, which I think your solution
> requires. Maybe I got you wrong there, but did you mean the host ID is
> something the user puts in?

	Yes, you need to specify the host ID yourself, and put it in the
config file. Is this a problem?

> I can't think of anything the computer itself
> can supply that will serve as an ID (remember that hostnames can also be
> set by the DHCP client).

	Well, Suns have had unique IDs since forever, and Pentium IIIs do,
too. MAC addresses are supposed to be unique, too (I'm inclined to argue
that anyone who messes with his MAC address either knows what he's doing,
or gets what he deserves). If I remember correctly, IPv6 allows part of
the address to be unique to the interface; this part should remain
constant even if you use DHCP or something similar.
	Also, Message-ID headers in email messages are intended to be
unique across all time and space. Is there anything that can be learned
from them? I believe they usually incorporate the hostname, time, and PID.

>  > 	b) Have one or more ancillary files that give the ID of the
>  > host with which a given database was synced. That way, this
>  > information can be rdisted along with the databases, and ColdSync can
>  > make a more informed decision as to whether or not to do a slow sync.
>
>  As for (b), it can definitely work, but the logic needs to be worked
> out. I'm guessing you'll end up needing some universal "clock" to compare
> sync events timeestamps to. That clock needs to be stored on the PDA, or
> else you have no way of identifying a sync against the PDA after a sync to
> a different host which has not bothered to send its files over since.

	Good point. One possibility might be to store both the host ID and
the "last good sync time" field from struct dlp_usrinfo (and perhaps other
data as well).

-- 
Andrew Arensburger                      Actually, these _do_ represent the
arensb@ooblick.com                      opinions of ooblick.com!
                        Generic Tagline V 6.01

This message was sent through the coldsync-hackers mailing list.  To remove
yourself from this mailing list, send a message to majordomo@thedotin.net
with the words "unsubscribe coldsync-hackers" in the message body.  For more
information on Coldsync, send mail to coldsync-hackers-owner@thedotin.net.