![]()
[<<]Message[>>] [<<]Author[>>] [<<]Subject[>>] [<<]Thread[>>]
Number : 4197 Date : 2003-04-03 Author : J. Merrill Subject : Re: Delta-Byte Replication Size(KB) : 1
Can you afford the space on your local system to keep a copy of the file as it is at the other end of the WAN link? (The "local copy" could also be on your local network, as when you did your testing.) If you can, you could build the xdelta file based on the local copy; apply the xdelta file to the local copy; compare the current real file with the local copy and if they don't match exactly (meaning that xdelta didn't do exactly what it should have done) then re-copy the current real file to your local copy and also over the WAN. If the xdelta process worked perfectly, send the xdelta file over the WAN and apply it on the other end. One advantage of this approach is that a bug in the xdelta program would not cause you to have an incorrect copy of the file on the other end of the WAN link (assuming that the "apply xdelta" program behaves identically on both systems). Good luck... At 04:05 PM 4/2/2003 +0000, agressiv99 wrote >Thanks for the response - > >I gave a win32 port of xdelta a try. Locally, it works great. >However, going over the wire, it is another story. > >Example. I have a 134MB file on one computer, connected at 10MB >ethernet to another. > >Copying the file takes about 90 seconds. > >changing about 10 bytes in the file and running an xdelta takes about >140 seconds and uses a ton of bandwidth which is what I was trying to >avoid. I can't imagine it over a 256k frame relay. > >I guess without the program running on both ends and talking to each >other like Storage Replicator or NSI Doubletake, I don't see a >command-line solution to it. Unfortunately those (as well as any >internet-based solutions) require a ton of cash for an environment >our size. > >Greg J. Merrill / Analytical Software Corp
This message if part of XXCOPY's message Archive. The archive contains all the messages posted at Yahoo!Groups: XXCOPY.