Don't forget, indirect replication is just a file based replication. The
more synchronizers you have the more message files pile up waiting to be
processed. So it doesn't matter how many you have, just if the hub replica
can process them fast enough.

Let me put it another way, we indirect sync only every hour and have four
groups of machines to do that. Group 1 runs on the hour, Group 2 on the 15
min mark, Group 3 on the 30 min mark and Group 4 on the 45 min mark. Why?
Because it takes too long for the server to respond to a manually initiated
indirect replication. (Manual = where the application through code starts an
indirect replication and tracks its progress until completion. I need that
for the very infrequently connected users.) There are over a hundred odd
messages to respond to at each mark. So when it waits 10 seconds from
reading the message before dealing with the next message, that time adds up.
Btw, is there any way to speed that up?

Now as far as replication servers, absolutely yes its possible! (Taking in
to account of the replication types that is!) Remember, it's just one
database replicating to another. eg. Some poor person A cannot get a decent
network connection, so instead of VPN'ing into the branch office, person A
replicates with person B who's physically close by to them. Person B
replicates with the branch office at a later time. Btw, the branch office
then replicates with the head office as well. So anyone can replicate with
any other replica equal or greater than their replica type. i.e.. Partial's
can replicate with full's, but not the other way.

I have a server that 12 computers connect to via VPN to do
indirect syncs every 30 min. The number of computers has
been increasing by one every month. Is there a limit on
how many synchronizers that can sync with the server at
any one time?

Is it possible to - at some point - break up the
connections and maybe have two "servers" and have six
computers syncing to each and then the two servers could
sync with each other?

Thanks for any suggestions.
Mike