US6230165B1 - Method for encoding and transporting database objects over bandwidth constrained networks - Google Patents
Method for encoding and transporting database objects over bandwidth constrained networks Download PDFInfo
- Publication number
- US6230165B1 US6230165B1 US09/174,280 US17428098A US6230165B1 US 6230165 B1 US6230165 B1 US 6230165B1 US 17428098 A US17428098 A US 17428098A US 6230165 B1 US6230165 B1 US 6230165B1
- Authority
- US
- United States
- Prior art keywords
- card
- stack
- delta
- data base
- deltas
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/56—Provisioning of proxy services
- H04L67/562—Brokering proxy services
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/25—Integrating or interfacing systems involving database management systems
- G06F16/252—Integrating or interfacing systems involving database management systems between a Database Management System and a front-end application
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99951—File or database maintenance
- Y10S707/99952—Coherency, e.g. same view to multiple users
Definitions
- the present invention relates in general to the accessing of information that is stored on a network server.
- the present invention relates to the packaging and transport of information using a method that decreases the amount of network bandwidth required.
- the present invention accomplishes this objective by involving the application in the goal of reducing the bandwidth required. This involvement is realized in two ways: data representation, and communication of the data representation between client and server applications.
- the present invention stores data in a card and stack arrangement.
- a card is a database record that can be added, modified and deleted.
- a stack is a logical collection of cards. Essentially, a stack is also a type of data base record and is therefore also a type of card. A logical collection of stacks is therefore another stack. Therefore stacks may logically contain other or sub stacks.
- a schema object known as a “card form” describes cards.
- a card form consists of value specifications that describe the type and format of individual data items represented in an associated card.
- a schema object known as a stack form describes stacks.
- a stack form consists of column schema and column maps.
- the column schema and column maps describe the organization of a stack based on the stack form.
- the column schema defines a column in associated stacks. Any value associated with a column implies overview information.
- Each column map associates the value specifications of a particular card form to a column schema of the stack form. Therefore, this mapping associates values of a card to a column of a stack that refers to it. From a stack prospective, this association determines the values of a card providing an overview. Only overview values are required when viewing a card through an associated stack. An understanding of these relationships allows the present invention to algorithmically determine which values of a card that must be current from a stack's prospective.
- Cards include a collection of card deltas that describe the value of one or more card fields at a particular time of change.
- Stacks consist of a collection of stack deltas. Stack deltas describe the addition, modification and removal of a given card at a particular time of change.
- the client uses a pull model transfer to extract information from the server's database.
- the transfer of information is achieved by the client's database using four protocol primitives: add, get, refresh and delete.
- the client's database makes these requests on behalf of the application in sympathy to the application's making request of the database that cannot be directly satisfied.
- the protocol primitives are directed to the servers database broker.
- the client application need not request unchanged information multiple times.
- the following scenario describes the flow of information into a stack, where the flow of information is unknown to the client database.
- a stack e.g., e-mail list
- the client database not recognizing the stack, makes a request of the server broker.
- the broker looks up the stack in the server database and replies to the client database with the complete object.
- the client not recognizing the stack form associated with the stack, makes a request of the server broker.
- the broker looks up the stack form in the server database and replies to the client database.
- the client application For each card indicated by the stack, the client application will be required to get the cards in their overview state according to how their card form maps into the columns via the column map (e.g., most likely all fields except for the body of the e-mail message).
- the broker will respond to the overview request for each card.
- the client may now display the stack in whatever way is appropriate.
- the end-user indicates a desire to see the details of a particular card on the stack (e.g., read an e-mail message).
- the client database makes a request to the broker for the particular cards delta based on the known delta level.
- the broker responds with the remaining fields of the card (e.g., the body of the e-mail message).
- FIG. 1 is a schematic diagram of the client/server network
- FIG. 2 is a schematic diagram of the client/server subsystems and their interactions
- FIG. 3 is an object relationship diagram showing the four primary structures of the present invention's database
- FIG. 4 is an object relationship diagram showing the support structures that relate to cards and card forms
- FIG. 5 is an object relationship diagram showing the support structures that relate to stacks and stack forms
- FIGS. 6 are the schematic (FIG. 6.1) and the ASN. 1 (FIG. 6.2) representations of a database object header;
- FIGS. 7 are the schematic (FIG. 7.1) and the ASN. 1 (FIG. 7.2) representations of a card;
- FIGS. 8 are the schematic (FIG. 8.1) and the ASN. 1 (FIG. 8.2) representations of a card delta;
- FIGS. 9 are the schematic (FIG. 9.1) and the ASN. 1 (FIG. 9.2) representations of a card form;
- FIGS. 10 are the schematic and ASN. 1 representations of several general purpose Value Specifications: VSHeader (FIG. 10 . 1 ), VSInteger (FIG. 10 . 2 ), VSFloat (FIG. 10 . 3 ), VSBoolean (FIG. 10 . 4 ), VSTime (FIG. 10 . 5 ), VSDate (FIG. 10 . 6 ), and VSString ( 10 . 7 );
- FIGS. 11 are the schematic (FIG. 11.1) and the ASN. 1 (FIG. 11.2) representations of a stack;
- FIGS. 12 are the schematic (FIG. 12.1) and the ASN. 1 (FIG. 12.2) representations of a stack delta;
- FIGS. 13 are the schematic (FIG. 13.1) and the ASN. 1 (FIG. 13.2) representations of a stack form;
- FIG. 14 is the schematic and ASN. 1 representations of an add card request and response
- FIG. 15 is the schematic and ASN. 1 representations of an add card delta request and response
- FIG. 16 is the schematic and ASN. 1 representations of an add stack delta request and response
- FIG. 17 is the schematic and ASN. 1 representations of a delete object request and response
- FIG. 18 is the schematic and ASN. 1 representation of a get object request and response
- FIG. 19 is the schematic and ASN. 1 representation of a refresh object request and response
- a plurality of clients 2 are connected to a server 4 by a wireless network 6 .
- the present invention utilizes five subsystems 8 , 12 , 14 , 16 , and 18 spread across the clients 2 and server 4 as shown in FIG. 2 .
- the individual client applications 8 communicate directly with the client database 14 via an application programming interface (API) 10 .
- API application programming interface
- the client database 14 is the only database, as the application 8 is not aware of any direct communication between the client 2 and the server 4 .
- the client database 14 pulls data as needed, via the server's broker 16 , over a wireless network connection 6 .
- the broker 16 obtains information from the server's database 12 to satisfy the client request using the same type of API 10 used on the client.
- Server side applications 18 also interact with the database using the same type of API 10 .
- each of the client databases 14 and the server database 12 contain four data structures as shown in FIG. 3 : card, stack, card form and stack form.
- the card 22 is a collection of values.
- a card 22 represents the values associated with a particular e-mail message.
- the values without type information are of little use to the applications 8 , 18 . Therefore, information is required on the organization of the values of a card 22 .
- a card form 26 conveys this information on the organization of the values in a card 22 .
- a card form 26 represents each card 22 , and each card form may describe multiple cards; hence, there is a one-to-many relationship 32 between card forms 26 and cards 22 .
- a stack 24 is a collection of cards 22 .
- a stack 24 is of limited use unless the relationship between it and its cards 22 is understood.
- a stack form 28 conveys this information.
- a stack form 28 represents each stack 24 , and the stack form may describe a plurality of stacks 24 ; hence, there is a one-to-many relationship 32 between stack forms 28 and stacks 24 .
- Each of the primary structures (card 22 , stack 24 , card form 26 and stack form 28 ) are derived from a common abstract structure: DBObject 20 .
- This derivation (as indicated by the inheritance symbol 30 ) allows these objects to be stored in the databases 12 14 , accessed via the API 10 and communicated on the wireless connection 6 between the client database and the broker 16 .
- the inheritance relationship 30 between card 22 and stack 24 and between card form 26 and stack form 28 provides two additional capabilities to stacks 24 . First, it allows stacks 24 to contain stacks. Second, it allows stacks to have values. The values of a stack are referred to as properties of the stack.
- the card form 26 has a plurality of value specifications 40 (as indicated by the one-to-many aggregate relationship 34 ).
- Each value specification 40 describes a value 38 that will exist in a card 22 based on the card form 26 at hand.
- the zero based index of a particular value specification 40 in a card form 26 implies the zero based index of the corresponding value 38 associated with a card 22 .
- the card's values 38 are stored in a plurality of card deltas 36 .
- Each card delta 36 is only associated with one card (as shown by the one-to-many aggregation 34 ).
- a new card delta 36 is applied to the card 22 when the first value is set.
- Values 38 are added to the card delta 36 as they are set until the card 22 is stored in the database. For example, when the e-mail application on the server is creating a new e-mail card for a received message, in effect, it applies one delta 36 that contains all of the values 38 associated with that initial version of the card.
- the client would change this value from false (the initial value for unread mail) to true when the user reads the message.
- a new card delta 36 would be applied to the card 22 .
- This second card delta would contain only one value: the new value of the readFlag. Since values 38 are sparsely populated in the card delta 36 , they must be indexed. This index relates back to the value specification 40 in the card form 26 .
- the properties of a stack 24 behave exactly like the values 38 of a card 22 due to the inheritance relationship 30 .
- the stack form 28 has one column schema 48 as indicated by the aggregate relationship 50 and a plurality of column maps 52 represented by the one-to-many aggregate relationship 34 .
- the column schema 48 describes a plurality of columns associated with each stack 24 based on the stack form 28 .
- Each column represented by the column schema constitutes a category of information.
- a column schema 48 for a stack 24 containing both receive and sent messages would describe five columns: name, time, date, readFlag and subject.
- the column map 52 establishes a relationship between a stack form 28 and a card form 26 . This relationship implies that a stack 24 based on the stack form 28 may logically contain cards 22 based on the card form 26 . Moreover, the column map 52 establishes the mapping between the value specifications 40 of the card form 26 and the columns of the stack form 28 . Continuing the e-mail example, one will notice that the from value of a received e-mail card is mapped to the name column while the to value of a sent e-mail card is mapped to the same column. Value specification for the values time, date, readFlag and subject would map directly to their column schema 48 counterparts.
- the stack 24 includes a plurality of stack deltas 42 as indicated by the one-to-many aggregate relationship 34 .
- Each stack delta 42 represents an operation on the stack 24 with respect to a card 22 .
- Each stack delta 42 refers to a card reference 44 as indicated by the aggregate relationship 46 .
- each card reference 44 refers to a card 22 by the many-to-one relationship 32 .
- there is one card reference 44 that refers to a card 22 .
- Each card 22 may be referred to by many card references 44 ; therefore, a card 22 can be associated with one or more stacks 24 .
- the add operation indicates that the card 22 is being logically added to the stack 24 .
- the modify operation indicates that the card 22 has changed with respect to the stack 24 .
- the remove operation indicates that the card 22 has been logically removed from the stack 24 . Note, removing a card 22 from a stack 24 does not cause the card to be deleted, it only results in breaking the logical relationship between the card and the stack.
- a stack delta would be applied to the e-mail stack when a new mail message is received.
- This stack delta 42 would refer to the e-mail message card 22 via an unique card reference 44 and is marked as an add operation.
- a stack delta 42 marked as a modify operation would need to be added to the stack 24 to make observers of the stack aware of the card's changing.
- This modify stack delta would refer to the original card 22 via a unique card reference 44 .
- a third stack delta 42 is applied. The delete stack delta 42 indicates that the card 22 has been logically removed from the stack 24 . Again, this delta refers to the same card 22 via a unique card reference 44 .
- the client database 14 By maintaining the history of add, modify and remove operations on a stack 24 with respect to contained cards 22 , it is possible for the client database 14 to maintain an accurate representation of the stack 24 by requesting stack deltas 42 from the server database 12 via the broker 16 .
- the present invention uses the Basic Encoding Rules (BER) for encoding Abstract Synatx Notation One (ASN. 1 ) to encode database objects for persistent storage and network transfer.
- ASN. 1 format is recognized by the International Standards Organization (ISO). Both ASN. 1 and BER were developed and standardized by CCITT (X. 209 ) and the International Standards Organization (ISO 8825 ). Both standards are well known in the trade and employed in the construction of several network protocols.
- FIG. 6.1 shows the schematic and ASN. 1 representation of a DBObject header.
- the key data element defines the well-known name of the object.
- the owner data element is an encoded well-known name of another DBObject 20 derivative that is the logical owner of the present object 20 .
- the observers data element provides a list of zero or more applications 8 , 18 that are interested in being notified when the present object 20 receives a new delta 36 , 42 . (In FIG. 6.1, the schematic depicts two observers.)
- the encoding of a DBObject's 20 header consists of five steps.
- an ASN. 1 SEQUENCE to contain the header header sequence is constructed.
- a SEQUENCE is an ordered collection of ASN. 1 encodings that are logically related.
- the key (well-known name) of the object at hand is encoded as an ASN. 1 OCTET STRING and added to the header sequence.
- an OCTET STRING is a string of 8 bit ASCII characters.
- an ASN. 1 SEQUENCE that is to contain the registered observers of the present DBObject is constructed: observer sequence.
- a DBObject's 20 header can be decoded by following the same logic in reverse.
- a card's 22 encoding includes the following data elements: a DBObject header and a sequence of card deltas 36 .
- the preferred ordering of card deltas 36 within a card's 22 encoding is chronological order (oldest first). (In FIG. 7.1, the schematic depicts four deltas.)
- an ASN. 1 SEQUENCE to contain the card 22 is constructed: card sequence.
- the DBObject 20 header is encoded and added to the card sequence.
- an ASN. 1 SEQUENCE to contain the deltas 36 applied to the card 22 is constructed: card delta sequence.
- the card deltas are enumerated, individually encoded and added to the card delta sequence.
- the card delta sequence is added to the card sequence.
- a card's 20 encoding can be decoded by following the same logic in reverse.
- a card delta's 36 encoding includes a sequence of values 38 . (In FIG. 8.1 the schematic depicts two values.)
- an ASN. 1 SEQUENCE to contain the card delta 36 is constructed: card delta sequence.
- an ASN. 1 SEQUENCE to contain the values 38 of the card delta 36 is constructed: value sequence.
- the values 38 of the card delta 36 are enumerated, individually encoded and added to the value sequence.
- the value sequence is added to the card delta sequence.
- a card delta's 36 encoding can be decoded by following the same logic in reverse.
- a card form's 26 encoding includes the following encoded data elements: a DBObject header and a sequence of value specifications 40 . (In FIG. 9.1 the schematic depicts four value specifications.)
- an ASN. 1 SEQUENCE to contain the card form 26 is constructed: card form sequence.
- the DBObject header sequence is constructed and added to the card form sequence.
- an ASN. 1 SEQUENCE to contain the value specifications 40 of the card form 26 is constructed: value specification sequence.
- the value specifications 40 of the card form 26 are enumerated, individually encoded and added to the value specification sequence.
- the value specification sequence is added to the card form sequence.
- a card form's 26 encoding can be decoded by following the same logic in reverse.
- FIGS. 10.1 through 10 . 7 depict the present invention's schematic and preferred ASN. 1 encoding for particular general purpose value specifications 40 .
- the individual elements of the value specifications 40 are encoded into a sequence that represents the encoding of the value specification.
- each value specification 40 has a common header that consists of a tag (a symbolic name) encoded as an ASN. 1 OCTET STRING. This encoded tag is further encoded within another ASN. 1 SEQUENCE that represents the value specification header: VSHeader.
- an integer type is represented by a header and an optional integer that represents the default value of an associated integer value. If the author of an integer value specification does not wish to impose a default value, the default element may be encoded as an ASN. 1 NULL. (In ASN. 1 , NULL is a primitive type that represents no value or the lack of a value where one might be expected.) Otherwise, the default value is encoded as an ASN. 1 INTEGER. (In ASN. 1 , integer values are encoded using the INTEGER primitive.)
- a floating-point type is represented by a header and an optional integer that represents the default value of an associated floating-point value. If the author of a floating-point value specification does not wish to impose a default value, the default element may be encoded as an ASN. 1 NULL. Otherwise, the default value is encoded as an ASN. 1 INTEGER.
- a boolean type is represented by a header and an optional boolean that represents the default value of an associated boolean value.
- the required default value is encoded as an ASN. 1 APPLICATION IMPLICIT NULL with a tag of zero for false or a tag of one for true.
- a date type is represented by a header and two additional data elements: default and preset.
- the default data element represents the source of the default value: preset, none or current. If the default value is preset, the preset data element contains an integer representation of a date that is to serve as the default value of an associated date value. This value is encoded as an ASN. 1 INTEGER representing the number of milliseconds (thousandths of seconds) since midnight Jan. 1, 1970 Coordinated Universal Time. If the default value is none, no default value is defined. If the default value is current, an associated value is initialized to the current date at its time of instantiation. If the default value is either none or current, the preset element has no meaning. The preferred encoding of the preset element in this case is as an ASN. 1 NULL.
- a time type is represented by a header and two additional data elements: default and preset.
- the default data element represents the source of the default value: preset, none or current. If the default value is preset, the preset data element contains an integer representation of a time that is to serve as the default value of an associated time value. This value is encoded as an ASN. 1 INTEGER representing the number of milliseconds since midnight Coordinated Universal Time. If the default value is none, no default value is defined. If the default value is current, an associated value is initialized to the current time at its time of instantiation. If the default value is either none or current, the preset element has no meaning. The preferred encoding of the preset element in the case is as an ASN. 1 NULL.
- a string type is represented by a header and four additional data elements: makeUpper, type, default and preset.
- the makeUpper data element is a flag that indicates that the associated string value should be forced to an upper case representation.
- the type data element indicates the type of string represented: nornal or password. Using this type applications 8 18 may make provisions for handing sensitive password data.
- the default data element represents the source of the default value: preset, none or guid. If the default data element is preset, the preset data element contains a string representation of a value that is to serve as the default value of an associated string value. If the default data element is none no default value is defined.
- the default data element is guid
- a universally unique string identifier is generated as a default for the associated value at its time of instantiation. If the default data element is either none or guid, the preset element has no meaning.
- the preferred encoding of the preset element in this case is as an ASN. 1 NULL.
- a stack's 24 encoding includes the following encoded data elements: DBObject header, card encoding and a sequence of stack deltas 42 . Since a stack 24 is derived (inherited) from a card 22 , the card 22 elements must be encoded in the stack for accurate representation of the stack's 24 properties (values). (In FIG. 11.1 the schematic depicts four deltas within the stack delta sequence.)
- an ASN. 1 SEQUENCE to contain the stack 24 is constructed: stack sequence.
- the DBObject header of the stack is encoded and added to the stack sequence.
- the card sequence is encoded and added to the stack sequence.
- an ASN. 1 SEQUENCE to contain the deltas of the stack is constructed: stack delta sequence.
- the deltas of the stack are enumerated, individually encoded and added to the stack delta sequence.
- the stack delta sequence is added to the stack sequence.
- the preferred ordering of stack deltas 42 within the stack delta sequence is chronological order (oldest first).
- a stack's 24 encoding can be decoded by following the same logic in reverse.
- a stack delta's 42 encoding includes two data elements: an operation and a card reference.
- the operation data element can be one of three values: add, modify or remove.
- the operation indicates the disposition of the card 22 referred to by the card reference data element with respect to the stack delta's 42 stack 24 .
- stack delta sequence a sequence to contain the stack delta 42 is constructed: stack delta sequence.
- the operation is encoded as an ASN. 1 INTEGER and added to the stack delta sequence.
- the key of the associated card is encoded as an ASN. 1 OCTET STRING and added to the stack delta sequence.
- a stack form's 28 encoding includes four elements: a DBObject header, a card form sequence, a column schema and a column map.
- a DBObject header defining two columns and a column map containing two column map entries.
- Each column map entry contains two map items mapping values of the associated card form to each of the two columns.
- an ASN. 1 SEQUENCE to contain the stack form 28 is constructed: stack form sequence.
- the DBObject header sequence is encoded and added to the stack form sequence.
- the card form sequence is encoded and added to the stack form sequence.
- the column schema is encoded as a sequence and added to the stack form sequence.
- the column map is encoded as a sequence and added to the stack form sequence.
- column schema sequence a sequence to contain the column schema is constructed: column schema sequence.
- column schema sequence a sequence to contain the column schema is constructed.
- the columns of the stack form 28 are enumerated.
- the zero-based index of the column is encoded as an ASN. 1 INTEGER and wrapped in a sequence encoding: column sequence.
- each column sequence is added to the column schema sequence.
- an ASN. 1 SEQUENCE to contain the column map entry is constructed: column map entry sequence.
- the key (well-known name) of the card form 26 associated with the column map entry is encoded as an ASN. 1 OCTET STRING.
- the column map items associated with the column map entry are enumerated, individually encoded and added to the column map entry sequence.
- an ASN. 1 SEQUENCE to contain the column map item is constructed: column map item sequence.
- the zero based index of the associated column is encoded as an ASN. 1 INTEGER and added to the column map item sequence.
- the zero based value specification index of the associated value is encoded as an ASN. 1 INTEGER and added to the column map item sequence.
- a stack form's 28 encoding can be decoded by following the same logic in reverse.
- the communications between the client database 14 and the server broker 16 are pull oriented. That is to say, the client 2 makes a request to pull information from the server database 12 via its broker 16 .
- the pulling of information is achieved via four synchronous request/response pairs: add, delete, get and refresh. In each case, the request is sent by the client database to the broker 16 , and the broker responds in kind to the request.
- the add request has three varieties: add object, add stack delta and add card delta.
- the add object request is used to add a new object (one created on the requesting client 2 ) to the server's database 12 .
- the add object request consists of an ASN. 1 SEQUENCE with an encoded DBObject derivative as its content.
- the broker 16 will respond with one of two possibilities: an error response or an acknowledgement.
- the structure of an error response is common across all request/response pairs; however, the possible error codes vary according to the request.
- the authentication error code is returned if the client 2 has not been authenticated. (Authentication is an element of the protocol that neither significantly benefits nor adversely affects bandwidth utilization; therefore, the specific method of authentication is not discussed here.)
- the exists error code is returned if an object with the same name as the object being added already exists. Error responses are returned as an ASN. 1 INTEGER encoded in an IMPLICIT ASN. 1 SEQUENCE with a tag of zero.
- the acknowledgment response is simply an IMPLICIT ASN. 1 NULL with a tag of one. This response indicates that the object associated with the request was successfully created in the server's database 12 .
- the object associated with an add object request can only have one delta 36 , 42 . Therefore, the object representation as it exists on the client is the most compact representation for transmission.
- the add card delta request is used to add a new card delta 36 to an existing card 22 . Therefore, the add card delta is in effect a modify operation on a card 22 .
- the add card delta request consists of an ASN. 1 SEQUENCE. Two data elements are encoded within this sequence: a key and a card delta 36 .
- the key (well-known name) of the object is encoded as an ASN. 1 OCTET STRING and the card delta 36 is encoded as described above.
- the broker 16 can reply with two possible error codes: authentication and exists.
- exists error code refers to the fact that the named object, the card corresponding to the delta, does not exist in the server's database.
- the broker 16 can respond with one of two forms of acknowledgement: simple or complex.
- the simple form of the acknowledgement is an IMPLICIT ASN. 1 NULL with a tag of one. This form of the acknowledgement indicates that the card delta 36 was successfully applied to the named card 22 in the server database 12 .
- the complex form of the acknowledgement is an IMPLICIT ASN. 1 SEQUENCE with a tag of one. This form of the acknowledgement indicates that the card delta 36 was successfully applied to the named card 22 ; however, another client 2 (or the server 4 ) had already applied the delta index indicated.
- the sequence in this form contains an ASN. 1 SEQUENCE of card deltas 36 . These card deltas 36 represent the missing deltas (those not known to the requesting client) and lastly, the client's own delta.
- the broker 16 Rather than responding to the client with the two missing deltas 36 and the newly renumbered delta (three in total), the broker 16 sends a composite delta 36 (reflecting the net result of applying all three deltas) with the delta level of the card: three. From the client database 14 point of view, the result is the same; however, this reduction in deltas 36 is beneficial to bandwidth utilization.
- the add stack delta request is used to add a new stack delta 42 to an existing stack 24 . Therefore, the add stack delta is in effect a modify operation on the stack 24 .
- the add stack delta request consists of an ASN. 1 SEQUENCE. Two data elements are encoded within this sequence: a key and a stack delta. The key (well-known name) of the object is encoded as an ASN. 1 OCTET STRING and the stack delta 42 is encoded as described above.
- the broker 16 can reply with two possible error codes: authentication and exists.
- exists again refers to the fact that the named object, the stack corresponding to the delta, does not exist in the server's database 12 .
- the broker 16 can also respond with one of two forms of acknowledgment: simple or complex.
- the simple form of the acknowledgment is an IMPLICIT ASN. 1 NULL with a tag of one. This form of the acknowledgement indicates that the stack delta 42 was successfully applied to the named stack 24 in the server database 12 .
- the complex form of the acknowledgement is an IMPLICIT ASN. 1 SEQUENCE with a tag of two. This form of the acknowledgment indicates that the delta 42 was successfully applied to the named stack 24 ; however, another client 2 (or the server 4 ) had already applied the delta index indicated by the delta 42 .
- the response sequence in this case contains an ASN. 1 SEQUENCE of stack deltas 42 . These stack deltas represent the missing deltas (those not known to the requesting client 2 ) and lastly, the clients own delta 42 .
- the broker Rather than responding to the client with the two missing deltas 42 and the newly renumber delta 42 (three in total), the broker sends a reduced set of deltas 42 (reflecting the net result of applying all three deltas) ending with the delta level of the stack: five. From the client database's 14 point of view, the result is the same; however, this reduction in deltas 42 is beneficial to bandwidth utilization.
- the following two algorithms are considered by the broker 16 in its attempt to reduce the number of stack deltas 42 .
- the delete object request is used to delete an existing object in the server's database 12 .
- the delete object request consists of an ASN. 1 SEQUENCE with the well-known name of the object encoded as an ASN. 1 OCTET STRING.
- the broker will respond with one of two possibilities: an error response or an acknowledgement.
- the broker 16 can reply with three possible error codes: authentication, access and exists.
- the access error code indicates that the requesting client does not have the appropriate level of access to perform the operation.
- the exists error code refers to the fact that the object does not exist in the servers database.
- the broker will respond with a simple acknowledgement: an IMPLICIT ASN. 1 NULL with a tag of one.
- the get object request is used to obtain an object that exists in the server's database 12 .
- the get object request consists of an ASN. 1 SEQUENCE with the well-known name of the object encoded as an ASN. 1 OCTET STRING.
- the broker 16 will respond with one of two possibilities: an error response or an acknowledgement.
- the broker can reply with three possible error codes: authentication, access and exists.
- the access error code indicates that the requesting client 2 does not have the appropriate level of access to perform the operation.
- the exists error code refers to the fact that the object does not exist in the server's database 12 .
- the broker 16 can responds to a successful get object request with an ASN. 1 SEQUENCE containing a card 12 , card form 26 , stack 24 or stack form 28 object encoding.
- the encoded object returned is the object named in the request.
- the refresh object request is used to obtain an update to an object that exists in the server's database 12 .
- This request is used when the client 2 has a version of the object at hand cached in its local database 14 .
- the refresh object request consists of a SEQUENCE containing both the encoded well-known name of the object at hand and the most recent delta index known to the client.
- the broker 16 will respond with one of two possibilities: an error response or an acknowledgement.
- the broker can reply to a refresh object request with one of four error codes: authentication, access, exists and unsupported.
- the access error code indicates that the requesting client 2 does not have the appropriate level of access to perform the operation.
- the exists error code refers to the fact that the object does not exist in the server's database 16 .
- the unsupported error code is returned if the broker does not support the refresh object request for the requested object type: only cards 22 and stacks 24 are supported.
- the broker 16 can responds to a successful refresh object request with an IMPLICIT ASN.
- the broker could respond with an IMPLICIT ASN. 1 NULL with a tag of one. This will be the client's indication that the request object is up to date.
Abstract
Description
Claims (9)
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US09/174,280 US6230165B1 (en) | 1998-10-16 | 1998-10-16 | Method for encoding and transporting database objects over bandwidth constrained networks |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US09/174,280 US6230165B1 (en) | 1998-10-16 | 1998-10-16 | Method for encoding and transporting database objects over bandwidth constrained networks |
Publications (1)
Publication Number | Publication Date |
---|---|
US6230165B1 true US6230165B1 (en) | 2001-05-08 |
Family
ID=22635572
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US09/174,280 Expired - Fee Related US6230165B1 (en) | 1998-10-16 | 1998-10-16 | Method for encoding and transporting database objects over bandwidth constrained networks |
Country Status (1)
Country | Link |
---|---|
US (1) | US6230165B1 (en) |
Cited By (18)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20030014495A1 (en) * | 2001-07-10 | 2003-01-16 | Jogen Pathak | System, method, and apparatus for preventing data packet overflow at node in wireless packet data services network |
WO2003007163A2 (en) * | 2001-07-10 | 2003-01-23 | Cyneta Networks, Inc. | Information push through simulated context activation |
US20030035407A1 (en) * | 2000-03-27 | 2003-02-20 | Rangaprasad Govindarajan | Packet retransmission in wireless packet data networks |
US20030063581A1 (en) * | 2001-10-02 | 2003-04-03 | Vyankatesh Shanbhag | System, method and apparatus for seamless interaction between wireless local area network and wireless packet data network |
US20030086407A1 (en) * | 2001-11-07 | 2003-05-08 | Yogesh Bhatt | Resource aware session adaptation system and method for enhancing network throughput |
US20030092392A1 (en) * | 2001-11-09 | 2003-05-15 | Sridhar Komandur | Weighted wireless early detection |
US20030095526A1 (en) * | 2001-11-07 | 2003-05-22 | Froehlich Robert W. | Cell level congestion policy management |
US20030137948A1 (en) * | 2001-06-19 | 2003-07-24 | Sridhar Komandur | Retransmission control in wireless packet data networks |
US20070078908A1 (en) * | 2005-05-17 | 2007-04-05 | Santu Rohatgi | Method and system for child safety |
US20070245152A1 (en) * | 2006-04-13 | 2007-10-18 | Erix Pizano | Biometric authentication system for enhancing network security |
US20070255963A1 (en) * | 2006-04-28 | 2007-11-01 | Erix Pizano | System and method for biometrically secured, transparent encryption and decryption |
US20080086646A1 (en) * | 2006-10-05 | 2008-04-10 | Ceelox, Inc. | System and method of secure encryption for electronic data transfer |
US20080091833A1 (en) * | 2006-10-13 | 2008-04-17 | Ceelox Inc | Method and apparatus for interfacing with a restricted access computer system |
US20080162527A1 (en) * | 2006-12-29 | 2008-07-03 | Ceelox Inc. | System and method for secure and/or interactive dissemination of information |
US20080162646A1 (en) * | 2006-12-29 | 2008-07-03 | Ceelox Inc. | System and method for secure and/or interactive dissemination of information |
US7424736B2 (en) | 2004-03-10 | 2008-09-09 | Combrio, Inc. | Method for establishing directed circuits between parties with limited mutual trust |
US20150242161A1 (en) * | 2014-02-26 | 2015-08-27 | Canon Kabushiki Kaisha | Information processing apparatus, distributed printing system, and method of controlling printing |
US20230134004A1 (en) * | 2012-10-18 | 2023-05-04 | Yahoo Assets Llc | Systems and methods for processing and organizing electronic content |
Citations (13)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5706435A (en) * | 1993-12-06 | 1998-01-06 | Panasonic Technologies, Inc. | System for maintaining data coherency in cache memory by periodically broadcasting a single invalidation report from server to clients |
US5734898A (en) * | 1994-06-24 | 1998-03-31 | International Business Machines Corporation | Client-server computer system and method for updating the client, server, and objects |
US5829001A (en) * | 1997-01-21 | 1998-10-27 | Netiq Corporation | Database updates over a network |
US5857203A (en) * | 1996-07-29 | 1999-01-05 | International Business Machines Corporation | Method and apparatus for dividing, mapping and storing large digital objects in a client/server library system |
US5870759A (en) * | 1996-10-09 | 1999-02-09 | Oracle Corporation | System for synchronizing data between computers using a before-image of data |
US5895471A (en) * | 1997-07-11 | 1999-04-20 | Unwired Planet, Inc. | Providing a directory of frequently used hyperlinks on a remote server |
US5898836A (en) * | 1997-01-14 | 1999-04-27 | Netmind Services, Inc. | Change-detection tool indicating degree and location of change of internet documents by comparison of cyclic-redundancy-check(CRC) signatures |
US5931904A (en) * | 1996-10-11 | 1999-08-03 | At&T Corp. | Method for reducing the delay between the time a data page is requested and the time the data page is displayed |
US5946697A (en) * | 1997-04-22 | 1999-08-31 | Microsoft Corporation | Rapid transfer of HTML files |
US5991760A (en) * | 1997-06-26 | 1999-11-23 | Digital Equipment Corporation | Method and apparatus for modifying copies of remotely stored documents using a web browser |
US5999947A (en) * | 1997-05-27 | 1999-12-07 | Arkona, Llc | Distributing database differences corresponding to database change events made to a database table located on a server computer |
US6003087A (en) * | 1996-02-15 | 1999-12-14 | International Business Machines Corporation | CGI response differencing communication system |
US6119155A (en) * | 1995-12-11 | 2000-09-12 | Phone.Com, Inc. | Method and apparatus for accelerating navigation of hypertext pages using compound requests |
-
1998
- 1998-10-16 US US09/174,280 patent/US6230165B1/en not_active Expired - Fee Related
Patent Citations (13)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5706435A (en) * | 1993-12-06 | 1998-01-06 | Panasonic Technologies, Inc. | System for maintaining data coherency in cache memory by periodically broadcasting a single invalidation report from server to clients |
US5734898A (en) * | 1994-06-24 | 1998-03-31 | International Business Machines Corporation | Client-server computer system and method for updating the client, server, and objects |
US6119155A (en) * | 1995-12-11 | 2000-09-12 | Phone.Com, Inc. | Method and apparatus for accelerating navigation of hypertext pages using compound requests |
US6003087A (en) * | 1996-02-15 | 1999-12-14 | International Business Machines Corporation | CGI response differencing communication system |
US5857203A (en) * | 1996-07-29 | 1999-01-05 | International Business Machines Corporation | Method and apparatus for dividing, mapping and storing large digital objects in a client/server library system |
US5870759A (en) * | 1996-10-09 | 1999-02-09 | Oracle Corporation | System for synchronizing data between computers using a before-image of data |
US5931904A (en) * | 1996-10-11 | 1999-08-03 | At&T Corp. | Method for reducing the delay between the time a data page is requested and the time the data page is displayed |
US5898836A (en) * | 1997-01-14 | 1999-04-27 | Netmind Services, Inc. | Change-detection tool indicating degree and location of change of internet documents by comparison of cyclic-redundancy-check(CRC) signatures |
US5829001A (en) * | 1997-01-21 | 1998-10-27 | Netiq Corporation | Database updates over a network |
US5946697A (en) * | 1997-04-22 | 1999-08-31 | Microsoft Corporation | Rapid transfer of HTML files |
US5999947A (en) * | 1997-05-27 | 1999-12-07 | Arkona, Llc | Distributing database differences corresponding to database change events made to a database table located on a server computer |
US5991760A (en) * | 1997-06-26 | 1999-11-23 | Digital Equipment Corporation | Method and apparatus for modifying copies of remotely stored documents using a web browser |
US5895471A (en) * | 1997-07-11 | 1999-04-20 | Unwired Planet, Inc. | Providing a directory of frequently used hyperlinks on a remote server |
Non-Patent Citations (2)
Title |
---|
Peter King et al. ed., Unwired Planet, "Handheld Device Markup Language Specification", http://www.w3.org/TR/, May 1997, 33 pages. * |
Tim Hylan, Unwired Planet, "Handheld Device Markup Language FAQ", http://www.w3.org/TR/, Apr. 1997, 4 pages.* |
Cited By (33)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20030035407A1 (en) * | 2000-03-27 | 2003-02-20 | Rangaprasad Govindarajan | Packet retransmission in wireless packet data networks |
US20030137948A1 (en) * | 2001-06-19 | 2003-07-24 | Sridhar Komandur | Retransmission control in wireless packet data networks |
WO2003007163A2 (en) * | 2001-07-10 | 2003-01-23 | Cyneta Networks, Inc. | Information push through simulated context activation |
WO2003007163A3 (en) * | 2001-07-10 | 2003-04-10 | Cyneta Networks Inc | Information push through simulated context activation |
US20030014495A1 (en) * | 2001-07-10 | 2003-01-16 | Jogen Pathak | System, method, and apparatus for preventing data packet overflow at node in wireless packet data services network |
US20030063581A1 (en) * | 2001-10-02 | 2003-04-03 | Vyankatesh Shanbhag | System, method and apparatus for seamless interaction between wireless local area network and wireless packet data network |
US20030095527A1 (en) * | 2001-11-07 | 2003-05-22 | Vyankatesh Shanbhag | Gb parameter based radio priority |
US20030095526A1 (en) * | 2001-11-07 | 2003-05-22 | Froehlich Robert W. | Cell level congestion policy management |
US6937570B2 (en) | 2001-11-07 | 2005-08-30 | Tektronix, Inc. | Resource aware session adaptation system and method for enhancing network throughput |
US20030086407A1 (en) * | 2001-11-07 | 2003-05-08 | Yogesh Bhatt | Resource aware session adaptation system and method for enhancing network throughput |
US7855998B2 (en) | 2001-11-07 | 2010-12-21 | Tektronix, Inc. | Gb parameter based radio priority |
US20030092392A1 (en) * | 2001-11-09 | 2003-05-15 | Sridhar Komandur | Weighted wireless early detection |
US7424736B2 (en) | 2004-03-10 | 2008-09-09 | Combrio, Inc. | Method for establishing directed circuits between parties with limited mutual trust |
US20070078908A1 (en) * | 2005-05-17 | 2007-04-05 | Santu Rohatgi | Method and system for child safety |
US20070245152A1 (en) * | 2006-04-13 | 2007-10-18 | Erix Pizano | Biometric authentication system for enhancing network security |
US8225384B2 (en) | 2006-04-13 | 2012-07-17 | Ceelox, Inc. | Authentication system for enhancing network security |
US20110060908A1 (en) * | 2006-04-13 | 2011-03-10 | Ceelox, Inc. | Biometric authentication system for enhancing network security |
US7962755B2 (en) | 2006-04-28 | 2011-06-14 | Ceelox, Inc. | System and method for biometrically secured, transparent encryption and decryption |
US20070255963A1 (en) * | 2006-04-28 | 2007-11-01 | Erix Pizano | System and method for biometrically secured, transparent encryption and decryption |
US20080086646A1 (en) * | 2006-10-05 | 2008-04-10 | Ceelox, Inc. | System and method of secure encryption for electronic data transfer |
US8412947B2 (en) | 2006-10-05 | 2013-04-02 | Ceelox Patents, LLC | System and method of secure encryption for electronic data transfer |
US20080091833A1 (en) * | 2006-10-13 | 2008-04-17 | Ceelox Inc | Method and apparatus for interfacing with a restricted access computer system |
US7818395B2 (en) | 2006-10-13 | 2010-10-19 | Ceelox, Inc. | Method and apparatus for interfacing with a restricted access computer system |
US20110066509A1 (en) * | 2006-12-29 | 2011-03-17 | Ceelox, Inc. | System and method for secure and/or interactive dissemination of information |
US7945520B2 (en) | 2006-12-29 | 2011-05-17 | Ceelox, Inc. | System and method for secure and/or interactive dissemination of information |
US20080162646A1 (en) * | 2006-12-29 | 2008-07-03 | Ceelox Inc. | System and method for secure and/or interactive dissemination of information |
US20110238990A1 (en) * | 2006-12-29 | 2011-09-29 | Ceelox, Inc. | System and method for secure and/or interactive dissemination of information |
US20080162527A1 (en) * | 2006-12-29 | 2008-07-03 | Ceelox Inc. | System and method for secure and/or interactive dissemination of information |
US8275718B2 (en) | 2006-12-29 | 2012-09-25 | Ceelox, Inc. | System and method for secure and/or interactive dissemination of information |
US8756422B2 (en) * | 2006-12-29 | 2014-06-17 | Ceelox Patents, LLC | System and method for secure and/or interactive dissemination of information |
US20230134004A1 (en) * | 2012-10-18 | 2023-05-04 | Yahoo Assets Llc | Systems and methods for processing and organizing electronic content |
US20150242161A1 (en) * | 2014-02-26 | 2015-08-27 | Canon Kabushiki Kaisha | Information processing apparatus, distributed printing system, and method of controlling printing |
US9691010B2 (en) * | 2014-02-26 | 2017-06-27 | Canon Kabushiki Kaisha | Information processing apparatus, distributed printing system, and method of controlling printing |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US6230165B1 (en) | Method for encoding and transporting database objects over bandwidth constrained networks | |
US7162486B2 (en) | System and method for representing named data streams within an on-disk structure of a file system | |
US8898147B2 (en) | Method and system for a transparent application of multiple queries across multiple data sources | |
US6636875B1 (en) | System and method for synchronizing related data elements in disparate storage systems | |
US6804671B1 (en) | Pluggable tablespaces for database systems | |
US7599948B2 (en) | Object relational mapping layer | |
US6684222B1 (en) | Method and system for translating data associated with a relational database | |
US20060212795A1 (en) | Scalable computing system for managing annotations | |
US6542515B1 (en) | Profile service | |
US7487168B2 (en) | System and method for loading hierarchical data into relational database systems | |
US20090055430A1 (en) | Method and system for model-based replication of data | |
US20020032775A1 (en) | System and method for transmitting and retrieving data via a distributed persistence framework | |
US7571441B2 (en) | Efficient retrieval of information from a network service using soap | |
Bearman et al. | Federating Traders: An ODP Adventure. | |
GB2396933A (en) | Parsing medical data between databases employing a parse tree | |
US6549901B1 (en) | Using transportable tablespaces for hosting data of multiple users | |
US20080168071A1 (en) | Storing Data in Predicted Formats | |
US20030028620A1 (en) | Method of handling a data request | |
US20050080759A1 (en) | Transparent interface to a messaging system from a database engine | |
US20060129522A1 (en) | Subscription service for access to distributed cell-oriented data systems | |
US20050160101A1 (en) | Method and apparatus using dynamic SQL for item create, retrieve, update delete operations in a content management application | |
US20230359354A1 (en) | Composite operations using multiple hierarchical data spaces | |
CN114780635A (en) | Block chain taking structured document data as center and application method thereof | |
Rykowski et al. | Generic architecture of web servers supporting cooperative work | |
AU2001216013A1 (en) | Method and system for translating data associated with a relational database |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: CERULEAN, MASSACHUSETTS Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:COOK, JOHN L., III;REEL/FRAME:009526/0947 Effective date: 19981015 |
|
AS | Assignment |
Owner name: IMPERIAL BANK, CALIFORNIA Free format text: SECURITY INTEREST;ASSIGNOR:CERULEAN TECHNOLOGY, INC.;REEL/FRAME:009978/0810 Effective date: 19990517 |
|
AS | Assignment |
Owner name: AETHER SYSTEMS, INC., MARYLAND Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:CERULEAN;REEL/FRAME:012539/0483 Effective date: 20020104 |
|
AS | Assignment |
Owner name: AETHER SYSTEMS, INC., MARYLAND Free format text: SECURITY AGREEMENT;ASSIGNORS:BIO-KEY INTERNATIONAL, INC., A MINNESOTA CORPORATION;PUBLIC SAFETY GROUP, INC., A DELAWARE CORPORATION;REEL/FRAME:015242/0052 Effective date: 20040930 |
|
AS | Assignment |
Owner name: BIO-KEY INTERNATIONAL, INC., MINNESOTA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:AETHER SYSTEMS, INC.;REEL/FRAME:015918/0896 Effective date: 20040930 |
|
FPAY | Fee payment |
Year of fee payment: 4 |
|
REMI | Maintenance fee reminder mailed | ||
AS | Assignment |
Owner name: LAURUS MASTER FUND, LTD., NEW YORK Free format text: SECURITY INTEREST;ASSIGNOR:BIO-KEY INTERNATIONAL, INC.;REEL/FRAME:015487/0020 Effective date: 20040929 |
|
REMI | Maintenance fee reminder mailed | ||
LAPS | Lapse for failure to pay maintenance fees | ||
STCH | Information on status: patent discontinuation |
Free format text: PATENT EXPIRED DUE TO NONPAYMENT OF MAINTENANCE FEES UNDER 37 CFR 1.362 |
|
FP | Lapsed due to failure to pay maintenance fee |
Effective date: 20090508 |
|
AS | Assignment |
Owner name: CERULEAN TECHNOLOGY, INC., MASSACHUSETTS Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:COMERICA BANK, A TEXAS BANKING ASSOCIATION, SUCCESSOR IN INTEREST TO IMPERIAL BANK;REEL/FRAME:026365/0651 Effective date: 20110523 |