">">

A quality product of Mib Software

HTTPsync: Comparison to other methods

The primary advantages of HTTPsync over other packages like CVS or CVSup is in the ease of setup and use (on both the source and destination sides.) No special daemon is needed on the source side, and a simple utility runs on the destination side with normal privileges. HTTPsync is useful for keeping files synchronized when all changes originate on a single source server.
HTTPsync is similar in method to the program "track", but uses HTTP and standard WWW servers. No special software daemon needs to run on the source side.

HTTPsync in brief:

• Requires only an HTTP server at the source, and the httpsync client at the destination.
  
• No special privileges are required by the programs running on either side.
  
• Destination files are owned by the user running httpsync
  
• Transfers are initiated by the destination side. ("Pull" model)
  
• The source side lists the files to be transferred. This gives the source side some control over what is available to be transferred.
  
• Uses a "packing list" to determine which files to transfer (not time-consuming HTTP
  "If-Modified-Since" or HEAD methods, which require a HTTP transaction even for files
  which have not been changed.
  
• Does not preserve local changes. Files will be made to match.
  
• Does not require multiple versions of files to be kept on source machine.
  
• Does not need configuration files at the destination. All needed information is obtained
  with one or two command line parameters.
  
• Simple to understand, install, use. Only about 850 lines of C.
  
  

• Does the source or destination side initiate the transfer?
  
  

• Protocol/Networking used.
  
• What is transferred (entire files, deltas)? Compression used?
  
  

• Does the source side provide a list of files, or does the Destination
  get a general list?
  
  

• What determines the files that need to be transferred. Is it necessary to
  transfer a full list (from the source) to determine that no changes were made?
  
• Does the source side need to keep multiple versions?
  
  

• What software must exist on the source side.
  
  

• What software must exist on the destination side
  
  

• If local changes are made, are these merged with source changes.
  
  

• Transfer Initiated by: Destination side (pull)
  
• Transfer Method: HTTP of entire files.
  
• List of Files: Source-side "packing lists"
  
• Subset Transferred: Destination iteration of full list to see what doesn't match file time/size.
  
• Source software needed: any HTTP server.
  
• Destination software needed: httpsync (C language)
  
• Merge with local changes: No
  
  
  

• Transfer Initiated by: Destination
  
• Transfer Method: Copies over TCP/IP, or rsh
  
• List of Files: Source determined.
  
• Subset Transferred: Destination iteration of full list, or source query based on destination state information/time stamps.
  
• Source software needed: trackd (librarian) or rsh access
  
• Destination software needed: track (subscriber)
  
• Merge with local changes: No
  
• Notes:
  Daniel Nachbar "When Network File Systems Aren't Enough: Automatic Software Distribution Revisited", Proceedings of the USENIX 1986 Summer Technical Conference, pp. 159-171, USENIX Association, Atlanta, GA, June 1986
  
  

• Transfer Initiated by: Source side (push)
  
• Transfer Method: rsh/ssh over TCP/IP
  
• List of Files: Source side
  
• Subset Transferred: Destination side iteration of full list for what doesn't match file time/size
  
• Source software needed: rsh/ssh, rdistd
  
• Destination software needed: rsh/ssh/rlogin access
  
• Merge with local changes: No
  
  

• Transfer Initiated by: Destination
  
• List of Files: Destination determined.
  
• Subset Transferred: Destination controlled URL-"crawler", or
  recursive ftp DIR with file timestamp comparison.
  
• Transfer Method: Primarily HTTP but also does FTP
  
• Source software needed: HTTP server or FTP server
  
• Destination software needed: wget
  
• Merge with local changes: No
  
  

• Transfer Initiated by: Destination side (Pull)
  
• Transfer Method: Entire files via FTP
  
• List of Files: FTP'ed LISTs (directory listings)
  
• Subset Transferred: Destination side iteration of full list for what doesn't match file time/size
  
• Source software needed: ftp server
  
• Destination software needed: mirror/mm (perl-based)
  
• Merge with local changes: No
  
  

• Transfer Initiated by: Destination-side (Pull)
  
• Transfer Method: Deltas via TCP/IP. Supports encryption
  
• List of Files: Source-side determined
  
• Subset Transferred: Determined from destination state information and query of source machine for difference between versions.
  
• Source software needed: supfilesrv (daemon supporting TCP/IP)
  
• Destination software needed: sup
  
• Merge with local changes: No
  
  

• Transfer Initiated by: Destination-side (Pull)
  
• Transfer Method: Deltas via TCP/IP (internal protocol)
  
• List of Files: Source-side determined
  
• Subset Transferred: Determined from destination state information (in CVS subdirs)
  and query of source machine for difference between versions.
  
• Source software needed: cvs server daemon supporting TCP/IP
  
• Destination software needed: cvs client supporting TCP/IP
  
• Merge with local changes: Yes
  
  

• Transfer Initiated by: Destination side (Pull)
  
• Transfer Method: Compressed deltas via TCP/IP.
  
• List of Files: Source-side determined
  
• Subset Transferred: Determined from destination state information and query of source machine for difference between versions.
  
• Iteration of changes: Source query based on local state information
  
• Source software needed: cvsup (A Modula-3 program)
  
• Destination software needed: cvsupd (A Modula-3 program)
  cvs, (or other configuration manager supporting RCS format)
  
• Merge with local changes: Yes
  
  

• Transfer Initiated by: Destination-side (Pull)
  
• Transfer Method: ?
  
• List of Files: ?
  
• Subset Transferred: ?
  
• Source software needed: ?
  
• Destination software needed: ?
  
• Merge with local changes: ?
  
• Notes:
  Mike Rodriquez, "Software Distribution in a Network Environment,'' in Large Installation System Administrators Workshop Proceedings, p. 20, USENIX, Philadelphia, PA, April 9-10, 1987.
  
  

• Transfer Initiated by: Destination-side (Pull)
  
• Transfer Method: ?
  
• List of Files: ?
  
• Subset Transferred: ?
  
• Source software needed: ?
  
• Destination software needed: ?
  
• Merge with local changes: ?
  
• Notes: ?
  Tim Sigmon, "Automatic Software Distribution,'' in Large Installation System Administrators Workshop Proceedings, p. 21, USENIX, Philadelphia, PA, April 9-10, 1987.
  
  

• Transfer Initiated by: Source or Destination
  
• Transfer Method: Deltas
  
• List of Files: Destination by directory list on source.
  
• Subset Transferred: Destination side iteration of full list for what doesn't match file time/size
  
• Source software needed: rsh/ssh, rsync
  
• Destination software needed: rsh/ssh, rsync, rlogin access
  
• Merge with local changes: No
  
• Notes: "Checksum search" used to find common sections of files to reduce deltas
  
  

• Transfer Initiated by: Source-side (Push)
  
• Transfer Method: Deltas via e-mail (Destination must be kept lock-step synchronized)
  
• List of Files: Source-side determined
  
• Subset Transferred: Source-side iteration of full list to see what changed, difference
  between versions.
  
• Source software needed: generate deltas, mailing list management
  
• Destination software needed: email, ctm
  
• Merge with local changes: Yes
  
  
  

• Transfer Initiated by: Destination
  
• Transfer Method: within operating system (mounted filesystems)
  Does not do remote synchronization.
  
• List of Files: Destination determined.
  
• Subset Transferred: find | cpio based on time stamps and lengths
  
• Source software needed: (filesync is a shell script which uses find, cpio)
  
• Destination software needed: (Source and Destination machines are the same.)
  
• Merge with local changes: No