 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
MS Access Forum / Replication / December 2006Indirect synchronization setup with no synchronizers on servers
In another thread that is getting very long, jacksonmacd suggested a method for using indirect synchronization in a scenario where remote PCs have synchronizers but the server does not. OK. Let's pursue that suggestion. General setup: Four LANs that are connected via WANs. One LAN server is the main server for the entire setup and is where I've been told I can place all of may application files. Assume Jet Synchronizer is installed on user PCs. Assume that it CANNOT be installed on any server. Assume further that we have to use one of the user's remote PCs as the indirect sync hub for each LAN. I don't understand the messaging in this setup. The problem with any PC on the LAN is that you can't see it. You can only see the servers. So does this mean that: 1) there needs to be a dropbox on a server contained within each LAN. Each user of the app will have a synchronizer. That synchronizer will send messages to the common dropbox located on the LAN server. Or is the suggestion to use direct synchronization for computers within each LAN. If I can get IT to approve synchronizers, then I would want to use indirect synchronization. After the beating I've taken about possibly using direct syncing why would I want to use it between remote PCs within the same LAN, when indirect syncing is a viable option. 2) The designated user's machine on each LAN is the one that will initiate the syncing of the dropbox message(s) with the replica farm on the respective LAN server. However, presumably this user is also using my app. Can his/her synchronizer handle both tasks (i.e. sending messages from the PC to the server dropbox and syncing the messages in the server common dropbox with the replica farm on the LAN server?). If so, why can't any user's synchronizer do this. After all, all user's synchronizers are sending messages to the common dropbox on the LAN server (unless the idea was to use direct syncing within each LAN). 3) Then we need to synchronize the replica farms on each individual LAN with the replica farm on the main server for this entire setup (the central server for this setup of LANs). How is this initiated? I think I can see how the topology works on this, but I'm unclear on how the synchronizers will work since there are none on the LAN servers. > In another thread that is getting very long, jacksonmacd suggested > a method for using indirect synchronization in a scenario where > remote PCs have synchronizers but the server does not. There is no difference between a synchronizer operating on replicas and dropboxes stored on its local LAN (e.g., on a server) or on the same machine where the synchronizer is running. > OK. Let's pursue that suggestion. General setup: Four LANs that > are connected via WANs. One LAN server is the main server for the > entire setup and is where I've been told I can place all of may > application files. I foresee problems here. You can't use a single server, as all the remote machines won't be local to it. You need four separate servers (using the generic term, where a "server" is a machine that offers shares to be accessed across the network). > Assume Jet Synchronizer is installed on user PCs. Assume that it > CANNOT be installed on any server. Assume further that we have to > use one of the user's remote PCs as the indirect sync hub for each > LAN. There is a problem with your terminology. "Server" means to you "the machine that IT calls a Server, the one that is a file server, an Exchange Server, a web server, etc." while what you mean is "all the machines that can share files." > I don't understand the messaging in this setup. The problem with > any PC on the LAN is that you can't see it. You can only see the > servers. The remote machine doesn't *need* to see the machine running the synchronizer. It only needs to be able to see that machine's dropbox, which can be stored on the server (and not on the machine running the synchronizer). The machine running the synchronizer doesn't have to host the managed replicas being synched by the synchronizer -- those can be stored anywhere on the synchronizer's local LAN. > So does this mean that: > > 1) there needs to be a dropbox on a server contained within each > LAN. YES. > Each user of the app will have a synchronizer. That synchronizer > will send messages to the common dropbox located on the LAN > server. Users local to a LAN don't need to use indirect replication. They can synch directly with the hub on the server because they are connected by a LAN. Indirect is only needed to synch between servers. This is the multiple star topology, where each LAN is a small star with direct replication and the centers of each star synch with each other (or with one central hub) over the WAN via indirect replication. > Or is > the suggestion to use direct synchronization for computers within > each LAN. YES. Why bother with indirect when direct is safe? > If I can get IT to approve synchronizers, then I would want to > use indirect synchronization. After the beating I've taken about > possibly using direct syncing why would I want to use it between > remote PCs within the same LAN, Uh, what? What do you mean by "remote PCs within the same LAN"? If they are connected by LAN, they aren't remote to the server on that LAN. If they *aren't* connected by LAN, then they aren't on that LAN at all, and might as well synch with a single hub somewhere else. > when indirect syncing is a viable option. Use indirect only when you MUST, i.e., when you don't have a LAN connection to synch across. > 2) The designated user's machine on each LAN is the one that will > initiate the syncing of the dropbox message(s) with the replica [quoted text clipped - 6 lines] > to the common dropbox on the LAN server (unless the idea was to > use direct syncing within each LAN). That's a very complicated set of questions. I'm not sure I can answer, and I'm certain it's relevant once you grasp the other things I've posted in this newsgroup today. However, I *think* the correct answer to the last question is that each replica's messages are specific to that replica. Remember, the synchronizer drops files in the dropbox on the *other* end of the connection, not in its own dropbox. If a workstation initiates an indirect synch with a server, then the workstation drops messages into the server's dropbox. The server's synchronizer pings that dropbox every N seconds (dunno exactly how often) and when it finds messages, it processes them. It then drops messages into the workstation's dropbox that tell the workstation what data to send. Then the workstation's synchronizer drops the appropriate messages into the server's dropbox. It wouldn't really be different if the synch were initiated at the server, as the first set of messages exchanged just establishes whether a synch is necessary (by evaluating generations for adds, updates and deletes), and that will need to be determined between any particular pair of replicas. > 3) Then we need to synchronize the replica farms on each > individual LAN with the replica farm on the main server for this > entire setup (the central server for this setup of LANs). How is > this initiated? You set up a synch schedule on the server where the replica farm replicas are stored. > I think I can see how the topology works on this, but I'm unclear > on how the synchronizers will work since there are none on the LAN > servers. What matters is *not* where the synchronizers are running. A synchronizer can run on the server at the center of one of the LANs or on one of the workstations attached to that LAN. The dropbox and the managed replicas can be on any machine that can serve files. Actually, big WHOOPS there. I've said that several times. It's not true. For an indirect synch, the managed replica has to be local to the file system of the machine running the synchronizer. Or, it has to be in a hidden share (one that ends in $). It's the dropbox that can be anywhere on the local LAN. The managed replica(s) that serve as the indirect replication hub must be on the same machine as the synchronizer. If they aren't, then you run the risk of getting a direct synch because the remote machines can see the replica on your end.  SignatureDavid W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ David: First off let me say that you have been very generous with your time and detailed explanations in all my posts and it is very much appreciated. I know you have in some cases said the same thing over and over again and that can be frustrating. Part of the issue is terminology as you note, my lack of knowledge on this issue, and I think the other part is the restrictions I'm forced to operate under. For example, I may be able to get the jet synchronizer installed on "workstations" but I doubt they will allow Replica Manager to be installed at all. TSI applications are out of the question under all scenarios (third-party). If I get the opportunity to implement indirect then I'm not going to trust any LAN, except the LAN where the file server is that stores my application files. That particular LAN is highly reliable and very fast. But all others will assume indirect replication. You're probably thinking that this is strange given my earlier stance on direct synchronization if indirect is not available. I don't mind putting the coding work in if indirect is available to me. I'm going to study these posts and then setup some indirect synchronization on my two laptops and desktop. At this point I need to be better able to communicate what I need and I need more experience with indirect synchronization. Thanks. > > In another thread that is getting very long, jacksonmacd suggested > > a method for using indirect synchronization in a scenario where [quoted text clipped - 142 lines] > David W. Fenton http://www.dfenton.com/ > usenet at dfenton dot com http://www.dfenton.com/DFA/ > First off let me say that you have been very generous with your > time and detailed explanations in all my posts and it is very much > appreciated. I know you have in some cases said the same thing > over and over again and that can be frustrating. I put the time in in part because I want to create a record for other replication users that can help them work through all the problems. I've had about ten years to learn all of this stuff. You are needing to learn it in a few weeks. I definitely wish someone had told *me* about the downside of direct replication across a non-LAN connection way back when. It would have saved me a lot of headaches and one of my clients thousands of dollars. > Part of the issue is terminology as you note, my lack of knowledge > on this issue, and I think the other part is the restrictions I'm > forced to operate under. For example, I may be able to get the > jet synchronizer installed on "workstations" but I doubt they will > allow Replica Manager to be installed at all. TSI applications > are out of the question under all scenarios (third-party). JRO doesn't supply all the functionality that is found in the TSI Synchronizer. But you *don't* need to install Replication Manager. If you have it, great, but all that needs to be installed is the synchronizer. I've pointed you to my instructions for how to do this without even having ReplMan at all. > If I get the opportunity to implement indirect then I'm not going > to trust any LAN, except the LAN where the file server is that [quoted text clipped - 4 lines] > available. I don't mind putting the coding work in if indirect is > available to me. I see that as way too much trouble, and have no idea why you wouldn't trust any of the LANs. Are they wireless or something? The topology I suggested was because I was trying to minimize the installation requirements to get by the IT department's restrictions. My scenario would require the synchronizer only on the servers at the hub of each LAN group. The other issue is that indirect replication introduces latency because you can't synch indirect with your production LAN replica (because the latter has to be shared and the former must *not* be shared). I'd prefer to minimize latency as much as possible, because that increases conflicts. And you're buying yourself headaches in supporting all those indirect users. With servers, you'd likely be able to get remote access to them and be able to administer and troubleshoot the synchronizer that way. With a bunch of workstations, it's less likely for you to get this permission. SignatureDavid W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ > JRO doesn't supply all the functionality that is found in the TSI > Synchronizer. [quoted text clipped - 3 lines] > pointed you to my instructions for how to do this without even > having ReplMan at all. But if I don't have ReplMan or TSI Sync installed, then I believe all I have available to me is JRO. I have not been able to find any code for managing/setting up a synchronizer using JRO. >> JRO doesn't supply all the functionality that is found in the TSI >> Synchronizer. [quoted text clipped - 7 lines] > all I have available to me is JRO. I have not been able to find > any code for managing/setting up a synchronizer using JRO. ReplMan doesn't really give you much, to be honest. What management/settings are you missing that can't be done manually or with JRO? SignatureDavid W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ Setting up the dropbox for the synchronizer, for example. I'm sure I'd have a lot more specific examples, but I've never done this before, so I don't yet know what to ask. > >> JRO doesn't supply all the functionality that is found in the TSI > >> Synchronizer. [quoted text clipped - 16 lines] > David W. Fenton http://www.dfenton.com/ > usenet at dfenton dot com http://www.dfenton.com/DFA/ >> What management/settings are you missing that can't be done >> manually or with JRO? > > Setting up the dropbox for the synchronizer, for example. I'm > sure I'd have a lot more specific examples, but I've never done > this before, so I don't yet know what to ask. Almost all the ReplMan setup is stored in registry keys. All you'd need is a Reg script to set them, or a program to do it that gathers data from the user. ReplMan really isn't a very useful program, to be honest. SignatureDavid W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ > What matters is *not* where the synchronizers are running. A > synchronizer can run on the server at the center of one of the LANs [quoted text clipped - 11 lines] > risk of getting a direct synch because the remote machines can see > the replica on your end. David I believe that you are technically correct, but I recall Michael Kaplan beating up on me for suggesting that the dropbox can be located anywhere on the LAN. While feasible, it is much preferred for the dropbox to be located on the same physical machine as is running the synchronizer. (Sorry if you've addressed this issue elsewhere. I am on the road and using Google Groups that offers less robust usenet tools Jack MacDonald > I believe that you are technically correct, but I recall Michael > Kaplan beating up on me for suggesting that the dropbox can be > located anywhere on the LAN. While feasible, it is much preferred > for the dropbox to be located on the same physical machine as is > running the synchronizer. I recall that MichKa criticized putting the dropbox on a different machine *only* if that other machine was not always accessible. My memory of the discussion was that the proposed topology was putting the server dropbox on the server and the laptop dropbox on the server, too. But I can't see why there could be any difference with a dropbox on the same LAN, always accessible, because the dropbox is only *read* by the local synchronizer, not written to. SignatureDavid W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ > > I believe that you are technically correct, but I recall Michael > > Kaplan beating up on me for suggesting that the dropbox can be [quoted text clipped - 13 lines] > David W. Fenton http://www.dfenton.com/ > usenet at dfenton dot com http://www.dfenton.com/DFA/ Truth be told, I have run a configuration with the dropbox located on the server instead of on the replica hub. Under this configuration, there were a few isolated incidents where the LAN connection between the computers was lost and the synchronizer was temporarily disabled. However, it was nothing insurmountable. >> > I believe that you are technically correct, but I recall >> > Michael Kaplan beating up on me for suggesting that the dropbox [quoted text clipped - 16 lines] > connection between the computers was lost and the synchronizer was > temporarily disabled. However, it was nothing insurmountable. But that's not really a problem, as all you have to do is delete the message files in the dropboxes and re-initiate the synch. I've lost connections over a VPN on the Internet, and over dialup, so I don't really see any difference there. SignatureDavid W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ > Truth be told, I have run a configuration with the dropbox located > on the server instead of on the replica hub. Under this > configuration, there were a few isolated incidents where the LAN > connection between the computers was lost and the synchronizer was > temporarily disabled. However, it was nothing insurmountable. Another followon: I'm not sure why this would matter. There's always a network connection on one end, either in the dropping of the files into the local dropbox, or in the reading of the files from the local synchronizer's dropbox stored on the remote server. Ah, yes, I see how that would be dangerous. If the local synchronizer opens the MDB data file in the remote synchronizer while it's applying the data to the local replicas, it could leave the local replica in an uncertain state if it's interrupted before it finishes reading the data from the remote dropbox. But I don't consider a LAN connection to be very dangerous at all. I certainly wouldn't do it across a WAN, for the same reason we don't do DIRECT across a WAN, but I just wouldn't worry about a dropped connection on a LAN, unless it were wireless (in which case I don't really consider it a LAN at all). SignatureDavid W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.