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

[Dan Pelleg <peldan@yahoo.com>]

Andrew Arensburger writes:
 > 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?
 > 

 Not in itself, but it makes installation and configuration harder for the
user. But it would probably be easy to supply a sane default that will
apply to the majority of users, who don't have this need (say, just use the
hostname, or the IP).

 > > 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.
 > 

 Yes, after seeing Ryan's post I realized that false negatives are OK here,
so the MAC address should be fine; after all, it's not unacceptable to
force a slow sync following a NIC replacement (or, if you want to pursue
that direction, a processor replacement...).

 > >  > 	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).
 > 
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.