|Publication number||US7860827 B1|
|Application number||US 11/552,132|
|Publication date||Dec 28, 2010|
|Filing date||Oct 23, 2006|
|Priority date||Oct 23, 2006|
|Publication number||11552132, 552132, US 7860827 B1, US 7860827B1, US-B1-7860827, US7860827 B1, US7860827B1|
|Original Assignee||Field Automated Communication Systems, Llc|
|Export Citation||BiBTeX, EndNote, RefMan|
|Patent Citations (11), Referenced by (5), Classifications (10), Legal Events (3)|
|External Links: USPTO, USPTO Assignment, Espacenet|
Whenever a copy (instance) of a database or file is made, and the copy is updated in parallel with updates to the master or server instance of the database, there is a need to have the server instance synchronized to reflect all of the data updates to the other instances. The present invention is a synchronization method including the software that keeps a network of processors and their instances of a database synchronized. The “master” instance of the application database is maintained on one or more file servers, and each remote instance of the database is maintained on a personal portable workstation, known as a “tablet”. There have been many methods proposed in the prior art to deal with this need.
U.S. Pat. No. 7,065,658, issued Jun. 20, 2006 to Matthieu Baraban, et. al. discloses a cordless tablet-like computer system with a method using wireless transmission and a checkpoint/restart technique, to achieve data synchronization. However, with multiple disconnected tablets, as in the present invention, a checkpoint/restart method is inadequate to deal with the simultaneous updates occurring on multiple tablets at the same time.
U.S. Pat. No. 7,035,879, issued Apr. 25, 2006 to Shepherd S. B. Shi, et. al., discloses a transmission-based method that relies primarily on timestamps to keep track of which updates have been applied. Such an approach is not adequate for a disconnected database wherein updates are going on simultaneously, but may not be transmitted or received in the sequence in which they were generated. The present method uses a hierarchical and numbered priority scheme to determine the updates that should be applied.
U.S. Pat. No. 7,032,033, issued Apr. 18, 2006 to Eric Ledoux, et. al., discloses a method for synchronizing a server and multiple client computers with direct connection to a network. The synchronization and a collision resolution method are based on an incremental numbering system with a final resolution decision being made by a user of the system, manually. The present invention uses a set of criteria to automatically preempt or discard inappropriate updates.
U.S. Pat. No. 6,952,708, issued Oct. 4, 2005, to Edward E. Thomas, et. al. discloses a synch key method, but is also based on a checkpoint/restart method similar to U.S. Pat. No. 7,065,658. The present invention uses synchronization objects that contain the control information to effect the proper application to the database.
U.S. Pat. No. 6,389,423, issued May 14, 2002, to Takashi Sakakura, discloses a version comparison method for a number of replicated versions. The present invention could not rely on such a method as the tablets and their instances are disconnected from the master server instance and the low bandwidth communication technology could never support such a comparison in the desired response times.
U.S. Pat. No. 6,343,299, issued Jan. 29, 2002, to Yun-Wu Huang, et. al., uses a version table for the multiple records and only applies updates based on version numbers. Such a method would never work in a disconnected database network such as in the present invention.
U.S. Pat. No. 6,317,754, issued Nov. 13, 2001, to Luoscheng Peng, discloses a network of primary servers and secondary servers using a combination of direct connect and summary synchronization vectors to support peer-to-peer synchronization. The user controls the peer-to-peer synchronization whereas the present invention use automated synchronization based on server rules-based control.
This is a description of a synchronization method including the software that keeps a network of processors and their instances of a database synchronized. The “master” instance of the application database is maintained on one or more file servers, and each remote instance of the database is maintained on a personal portable workstation, known as a “tablet”. The tablet 20 contains storage capability, communication capability (cellular technology) and processing capability. The synchronization software (known herein as “synch”) keeps server instances 241 and all tablet instances 242 of the application database 240 synchronized based on business rules and the methods described herein.
The application for this software is to keep office server instances 241 of the application database 240 synchronized with tablet instances 242 in the field, i.e. remote locations away from the central office server 10 and connected to the central office server 10 only through cellular phone technology. Since cellular technology is characterized as slow and with low-volume transmission for data processing requirements, the software is optimized to run in low-bandwidth networks where connectivity is intermittent, supporting data transfers that are opportunistic, preemptable and restartable.
The principal application that created the demand for the synch methods described herein was an entity managing a construction project in which the central office server 10 needs to be updated continually by all of the lead or supervisory workers in the field, each of which has a tablet 20 with an instance 242 of the application database 240. The synch method described herein provides each tablet 20 owner and the central office server 10 with automated data synchronization such that any tablet 20 owner or office worker with access to the server 10, can both update the application database 240 as needed and also get up-to-date project information on labor costs, expenditures and progress from all the other tablet 20 owners. Even though this is the application described herein, it is obviously not limited to construction projects, and can be used by any application requiring remote synch between a server 10 and multiple tablets 20.
The useful synch method disclosed herein thus provides a largely automated service of affording remote tablet 20 data entry for use by other tablets 20 and by central management on an up-to-the-minute basis without the previously used methods of direct connection and manual intervention to effect synchronization.
The synch method consists of both manual and automated data entry on the tablets 20 and automated synchronization procedures executed by the software. In essence, database updates are initiated by tablet 20 owners and persons with central server 10 access. The synch then creates a data structure called a Data Synchronization Object (referred to here as “DSO”) 30 to effect the synchronization.
The DSO 30 contains control information, priority information, originating user information and the database update data itself. The DSO 30 is then placed into a queue on the initiating tablet 20 or server 10, and if it is a queue on a tablet 20, it awaits a connection with the server 10 for transmission. When the DSO 30 is transmitted to the server 10, it contains control information as to what the server 10 should do with the update, i.e. which application database 240 tables and tablets 20 (“network peers”) should receive the updates.
When a DSO 30 is generated, it is inserted into one or more synch queues 316. Each synch queue 316 is a priority queue holding all DSO's 30 scheduled to be sent to a particular peer 20 in the system.
An instance of synch manages one or more synch queues depending on whether it's a server instance 10 or a tablet instance 20. The priority is based on a strict weak ordering defined by first comparing the priority which the user assigns to a DSO 30, and then the order in which DSO's 30 are inserted into the queue 316.
Once a synch queue 316 has at least one element, the synch software tries to connect 610 to the peer 20 assigned to that queue 316. If the peer 20 is not available on the network, a retry 610 is scheduled using an exponential falloff scheme to avoid the “thundering herd” problem.
Once a connection is made 620, DSO's 30 are transmitted according to their position in the synch queue 316.
Synch queues 316 are preemptable. When a DSO 30 with a higher priority than the currently processing DSO 30 is inserted into a queue, the current transfer is suspended so that the new transfer begins immediately. This continues until the queue is empty.
When a DSO 30 is received it is parsed and applied to the local instance of the database. The next DSO 30 is not sent until the current DSO 30 is processed by the receiving database.
In this way the user can work with a local copy of the application database 240 no matter what the status of the network, and the synch software opportunistically tries to synchronize the local instance 240 of the database with the server instance 241.
A DSO 30 is a text file created in a particular format. It is named according to the following scheme that guarantees a particular DSO 30 will have a unique name across all machines being synchronized:
The DSO 30 format is line based. It is divided into a header and body. The header consists of two lines followed by a blank line:
The body of the DSO 30 consists of one or more blocks, each block containing data for one table. The first line of a block contains the name of the table. The second line contains the column names. Then one or more lines of text follow, each line containing one row of data from the originating table. Each field within a row is delimited by a special character (ascii code 255, y umlaut). The end of a block is indicated by a blank line.
There are three types of DSO's:
On startup the synch software binds to a port in order to accept incoming connections and then connects to a database instance. The port and database instance are specified in a configuration file 230. This database connection 245 is held open for as long as the synch software is running. First, queries are made to the database 230 to obtain configuration information. In particular, the working directory for DSO's 30 and the table of IP addresses corresponding to synch peer 20 instances 242 are obtained. Synch then registers with the database as a listener 247 of a particular named event. When this event is fired by code executing in the database, the synch software receives a notification on its database connection 620 which it regards as a signal that new items have been inserted into the synch queue (see section 5). Finally, it makes an initial query 249 to build its internal representation of the synch queue 316 (see section 5 for more information about the structure of the synch queue 316).
After all database queries 249 have completed, the synch software connects to all peer instances 242 it knows about and informs these instances that it is up and running and ready to exchange data. Any successful connections transition into the queue transmission state. Unsuccessful connections are scheduled for retry if the peer in question has a non-empty synch queue 316.
DSO 30 creation is begun by setting a column of a table named ‘sstat’ to the value ‘ ’ (null). All tables that are synched must have this column. A stored procedure then runs that creates the DSO 30 file corresponding to that row of the table and any other rows in other tables that are referred to. The relationship between tables is encoded in various stored procedures that are assigned to each table 240 as appropriate.
Once the DSO 30 is created it is inserted into the synch queue 316 in order to be sent to the designated peers. A new row has to be inserted in the synch queue 316 for each peer 20 that the DSO 30 should be sent to. Each row 30 must contain the following fields:
Insertion into the synch queue 316 is accomplished by a standard insert operation into the database table that is the persistent representation of the queue. The synch software itself must maintain an internal representation of the synch queue 316. It does this by first informing the database 240, on startup, that it is a subscriber to a database event named “synch”. When an insert is made to the table 240, the database raises the named event “synch”. No data can be sent along with this notification. Synch receives this notification by maintaining a file descriptor that corresponds to the open connection to the database 240.
When the database raises the event “synch” 310, the operating system Input/Output facility informs synch that there is data pending on that file descriptor. Synch then queries the database 240, via the open file descriptor, for any pending events. If the event “synch” has been raised, then synch regards its queue representation as stale and queries the database 240 to refresh its queue. This query returns the top 100 entries in the synch queue 316 for each peer. For each row returned, synch checks to see if that entry is already stored 410 in its internal queue 316. If not, it inserts the row. If a peer's queue changes state from empty to non empty, a connection attempt 610 is scheduled. If the entry at the top of a queue is different than the current executing DSO 30, then the synch software will preempt the current transfer (see section 6, Queue Transmission).
When a DSO 30 has been transmitted to a peer, the corresponding row is removed from the internal queue 316 and an insert to the database 240 is sent to mark the corresponding row in the synch table as finished. When the internal queue for a connected peer 20 becomes empty 550, synch makes a modified query to the database to return the next items scheduled to be sent, if any.
Some further actions are taken when a DSO 30 is inserted into the internal queue 316. First, the size of the DSO 30 is checked. If it less than one megabyte, an SHA1 checksum 40 is computed 510 and stored in the internal queue 316. If it is greater than one megabyte 414, the DSO 30 is broken up in to one megabyte chunks 420. An extra file is created that lists each chunk and the name of the original DSO 30 so that the receiver can reassemble the chunks. This file is called a manifest 430. This extra file is sent to the receiver by inserting it into the internal queue 316 right after the last chunk. All chunks, and the manifest 430 are then assigned 510 their SHA1 checksum 40.
The first part of queue transmission is connection management. Since network connectivity is not guaranteed for individual tablets 20, the system has to be robust in the face of total, but temporary, network outage. As soon as a queue becomes non empty 312, a connection attempt 610 is made. If that connection attempt 610 fails, another connection attempt 610 is scheduled. The scheduling of the next connection attempt 610 is done as follows. First, a time interval is chosen. This interval is seeded with the number of seconds since the last known network activity, or one if this connection is the first one to be attempted 610. Each time a connection attempt 610 fails this number is doubled. A random number between one and the minimum of the maximum interval (assigned as a configuration variable) and the current interval is generated, and taken to be the number of seconds to wait before making the next connection attempt 610. This exponential falloff is done to avoid the “thundering herd” problem, where due to network conditions many peers 20 regain connectivity at the same time and all try to connect at the same time, overwhelming the server 10 machine.
Once a connection is successful 620, a handshake 700 is executed where the software queries the peer 20 for its id and application version. If the id returned isn't the expected one, the connection is immediately terminated as erroneous. The application version is stored to compare against the application version associated with DSO's 30. If the handshake is successful 700, queue transmission begins. If both connected instances have DSO's 30 queued up, queue transmission occurs in parallel.
The queue is processed in the order defined by the user assigned priority and the order in which DSO's 30 were inserted. For each entry in the synch queue 316, the same steps are followed.
When a DSO 30 arrives at its destination/receiver the following steps are taken:
|Cited Patent||Filing date||Publication date||Applicant||Title|
|US6223343 *||Apr 3, 1998||Apr 24, 2001||State Farm Mutual Automobile Insurance Co.||Computer system and method to track and control element changes throughout application development|
|US6317754||Jul 3, 1998||Nov 13, 2001||Mitsubishi Electric Research Laboratories, Inc||System for user control of version /Synchronization in mobile computing|
|US6343299||Nov 16, 1998||Jan 29, 2002||International Business Machines Corporation||Method and apparatus for random update synchronization among multiple computing devices|
|US6389423||Dec 3, 1999||May 14, 2002||Mitsubishi Denki Kabushiki Kaisha||Data synchronization method for maintaining and controlling a replicated data|
|US6952708||Jun 27, 2001||Oct 4, 2005||Microsoft Corporation||Method and system for using a sync key|
|US6976077 *||Jul 6, 1999||Dec 13, 2005||Microsoft Corporation||Automatic and transparent synchronization of server-side state information with a client application|
|US7032033||Nov 30, 2001||Apr 18, 2006||Microsoft Corporation||Handling collisions during synchronization of data between client and server computers|
|US7035879||Dec 26, 2002||Apr 25, 2006||Hon Hai Precision Ind. Co., Ltd.||System and method for synchronizing data of wireless devices|
|US7065658 *||May 18, 2001||Jun 20, 2006||Palm, Incorporated||Method and apparatus for synchronizing and recharging a connector-less portable computer system|
|US7606881 *||Apr 25, 2002||Oct 20, 2009||Oracle International Corporation||System and method for synchronization of version annotated objects|
|US20030131087 *||Jan 4, 2002||Jul 10, 2003||Shippy Keith L.||Method of using billing log activity to determine software update frequency|
|Citing Patent||Filing date||Publication date||Applicant||Title|
|US8200626 *||Sep 18, 2009||Jun 12, 2012||Sprint Communications Company L.P.||Mobile device file management|
|US8965954||Oct 21, 2009||Feb 24, 2015||Google Inc.||Always ready client/server data synchronization|
|US20100100590 *||Oct 21, 2009||Apr 22, 2010||Palay Andrew J||Always ready client/server data synchronization|
|US20100121874 *||Oct 21, 2009||May 13, 2010||Palay Andrew J||Search based specification for data synchronization|
|US20110022575 *||Jan 30, 2008||Jan 27, 2011||Paul Leslie Tomkins||System and method of conclusively verifying the correctness of an information system without needing to test every combination of behaviour at run-time|
|U.S. Classification||707/610, 707/656, 707/617, 707/618, 707/620, 707/614|
|International Classification||G06F17/00, G06F7/00|
|Dec 21, 2007||AS||Assignment|
Owner name: SHARECHIVE, LLC, CALIFORNIA
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:AYYAD, TARIQ;REEL/FRAME:020297/0604
Effective date: 20061023
|Nov 3, 2009||AS||Assignment|
Effective date: 20071205
Owner name: FIELD AUTOMATED COMMUNICATION SYSTEMS, LLC, CALIFO
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:SHARECHIVE LLC TO REMINGTON PARTNERS, INC;REMINGTON PARTNERS, INC. TO FIELD AUTOMATED COMMUNICATION SYSTEMS, LLC;REEL/FRAME:023463/0223
|Mar 31, 2014||FPAY||Fee payment|
Year of fee payment: 4