How Networking Works |
Top Previous Next |
This section describes in detail how the real-time networking functionality in Campground Master works. It may be helpful to understand what's going on behind the scenes, to get a better idea of why some things work the way they do.
Real-time Networking
Each workstation will have its own copy of the database, both on the hard disk and in RAM memory. This allows each workstation to operate quickly and independently when viewing data, running reports, etc. This also allows workstations to be operated offline if necessary -- though not recommended in general, this allows operation even if the network is down, or for instance if you want to do some reports offline. Note that non-master workstations can only work offline if the Work Offline function is specifically selected (administrator access is required for this).
Unlike most networked database applications, Campground Master operates as a real-time system. When changes are made at one workstation (reservations added, dates changed, etc.), those changes will be immediately sent to all other workstations so that they will be up to date. If the changes affect the current tab view, the screen will be updated immediately to reflect the changes, just as if they were done at each workstation (subject to a refresh delay setting, which can be used to prevent numerous screen refreshes when the workstation is in use).
As mentioned in earlier sections, Campground Master does not depend on a shared database file for networking -- every computer must have its own copy of the database, preferably on its own hard drive. Networking is done entirely through TCP/IP communications, with simple notification messages. This is similar to the way "Chat" programs like ICQ, AOL Instant Messenger, or MSN Messenger program work. Therefore it can work just as well through the Internet as it does through a local area network.
Naturally it's important to keep changes synchronized and to prevent two workstations from making different changes to the same information at the same time. This is achieved through three mechanisms -- record locks, sequence numbers, and logs.
Record Locks
Before any changes can be made to a record in the database, it must be "locked" by the workstation. All locks are requested through the master workstation (which also acts as the network server). If a record is already locked by another workstation, then the lock request will be denied, and the operator at that workstation will be informed that it can't be edited. If the lock is granted, then editing proceeds normally. For the most part this is transparent to the operator as long as there is no conflicting locks, except for a small delay when requesting the lock (e.g. before the editing dialog is opened).
Once the editing is complete, the changes are sent to the master workstation for distribution to the other workstations, and the locks are released so other workstations can edit the record if needed. If a workstation gets disconnected or goes down while it has records locked, these locks will be "stuck" in the master workstation -- but they will be cleared automatically when the workstation comes back online, or they can be manually cleared at the master workstation by an administrator function.
Sequence Numbers
Whenever changes are made, they are tagged with a sequence number and logged, as well as sent to the master workstation. If changes are missed for any reason, the gap in sequence numbers will be detected. The master workstation will request any missed changes from a workstation and will make sure they are applied in the correct order. Likewise, the master makes sure that a workstation is up to date before allowing it to lock any record, so that data integrity is maintained. Sequence numbers are checked often (along with the "heartbeat"), so a change missed due to network problems (extremely rare, but possible) will be quickly detected and corrected.
The other benefit of logging changes with sequence numbers is that it can allow automatic synchronization after a workstation has been offline. For instance, if you could call in to your network via the internet from home, all changes since the last time your home workstation was connected will be synchronized automatically. Likewise, you could work offline (preferably after getting synchronized), then call in to the network -- all of your changes will be downloaded to the master and the database will be synchronized.
If a workstation cannot be synchronized for any reason, there is a fail-safe mechanism -- the entire database can be transferred from the master to a workstation. This will be done automatically if the master can't find all of the changes needed by a workstation (e.g. if the log file becomes corrupt due to a computer crash), or it can be done manually any time if the workstation doesn't seem to have the correct data. Note that this can only be done from the master workstation -- if a client workstation, rather than the master workstation, is determined to have the only "good" copy of the database, then it must be transferred manually to the master and then synchronized to the other clients.
Logs
Sequence numbers indicate when changes are missed, but in order for a workstation to "catch up" on missed changes, they must be logged so that they can be retrieved. Each workstation maintains log files of all changes, both for its own workstation and for all other workstations. Thus if changes are requested for a specific range of sequence numbers, it can read them from the log and send them to the requesting workstation. If the log entries for the requested sequence numbers can't be found, the only recourse is to refresh the entire database -- this will be done automatically when needed, but can cause a significant delay. Therefore make sure that history logging is enabled and that disk space doesn't run out.
A new log file will be started each day, and named according to the database name, date, and workstation ID. Log files are automatically deleted after a specified number of days to keep disk space to a minimum, but you should keep logs for at least 7 days if possible. Another reason to keep logs for a longer period is that they can serve as a complete audit trail. Every single change to the database is recorded, and every entry has the date, time, and operator responsible for the change. The logs are in tab-delimited text format, so they can be examined if necessary (some knowledge of the database structure is required). In addition, network problems could be diagnosed by comparing the logs of different workstations.
You can optionally log record locks and unlocks as well as the changes. While this is not required for any functionality (and in fact will make other functions slower and use more disk space), it can be useful for diagnostic purposes if a software bug is suspected. In general, you can leave this option turned off.
Finally, one great side-benefit of the logs is the ability to completely recover after a crash, even if the crash destroys the database. As long as the log files are intact (for at least one workstation), you can restore from a previous backup and have Campground Master automatically re-apply all changes made since the backup was made.
Additional Topics:
Setting up Multiple Connections
Networking Through the Internet
Firewall Configuration Examples