[]

Replication Manager is a UI to replication functionality provided by
the synchronizer component that runs on each end of an indirect or
Internet replication setup.

The synchronizer program is only available with Replication Manager,
not as a separate downloadable component.

But it is only necessary for non-direct replication, because it's
whole purpose is to run on a machine with direct access to your
local replica, and then communicate with another synchronizer on
another machine.

With direct replication, the machine doing the synchronizing is
opening both replicas.

With indirect replication, the local synchronizer process is
communicating with the remote synchronizer process and exchanging
information about the two replicas. Then, the local synchronizer
drops message files into the dropbox on the remote system. The
remote synchronizer then applies those message files to the remote
replica, then drops its own message files in the local dropbox for
the local synchronizer to apply to the local replica. A synch
generally takes two or there cycles of this.

Put more clearly, synchronizing replica A and replica B on PC A and
PC B, respectively, requires this for indirect and Internet
replication:

1. synchronizer running on PC A, with replica A open.

2. synchronizer running on PC B, with replica B open.

Direct replication from PC A opens both replica A and replica B.

Indirect replication does this:

1. synchronizer A drops message files in dropbox on PC B.

2. synchronizer B applies message files in dropbox B to replica B.

3. synchronizer B drops message files in dropbox on PC A.

4. synchronizer A applies message files in dropbox A to replica A.

These 4 steps repeat until the replicas are identical. The reason it
can take several sycles is because certain changes have to happen in
order. For instance, if there's been a schema change, you have to
synch the records edited *before* the schema change first, then
synch the schema change, then synch the data edits made *after* the
schema change. Also, keep in mind that cascading deletes are going
to have to be handled in a single cycle, but you can't have the
deletes occur until after the add of the deleted replicas has been
propagated.

The simplest way to think of it is that each generation has to be
propagated sequentially. But Jet is smart enough to figure out if it
can roll up several generations into one synchronization cycle.

You don't see any of this with direct replication because the files
on both ends are open. However, the same number of cycles are
involved.

Internet replication is, of course, different, as it depends on IIS
for FTP support to copy files to the remote dropbox. Indirect
replication works over an SMB networking connection, so the local PC
is writing direct to the file system of the remote PC (well, via
networking services).

Indirect replication was designed to work over very low bandwidth
(dialup connections), but using SMB networking (i.e., native Windows
networking services).

I don't know what they are or are not promoting. SQL Server
replication brings a whole host of new problems.

Indirect replication over VPN is the only solution I can recommend.

The other alternative is to drop replication entirely and do
something like hosting the remote users on Windows Terminal
Services. But that requires a constant Internet connection, whereas
indirect replication over VPN does not.