A whitepaper: The LiveDist product
n Galiel-3.14 Ltd. has intellectual property rights relating to implementations of the technology described in this white-paper. All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form, or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written consent of the publisher.
n This presentation is provided “AS IS” without warranty of any kind, either express of implied, including, but not limited to, the implied warranties of merchantability, fitness for a particular purpose, or non-infringement. This presentation could include technical inaccuracies or typographical errors. Changes are periodically added to the information herein. These changes will be incorporated in new editions of the presentation. Galiel-3.14 Ltd’ May make improvements and/or change in any technology, product, or program described in this presentation at any time.
· Delivers information to all required clients, in less than 0.5 seconds.
· Can scale to support a practically unlimited number of clients.
· Preserve transactional integrity.
· Enables new clients to join the network automatically and swiftly.
· Dynamic change of subscription.
· No administration.
· The marginal cost of server side hardware for each additional 300 clients is about $1000.
LiveDist is a robust C#
web-application product, used for swiftly and selectively distributing database
modifications to a large number of clients, while preserving transactional
The updates made by each committed transaction are distributed in 0.2 - 0.5 seconds to a
practically unlimited number of interested clients.
LiveDist is written in C#. LiveDist servers run on dedicated low-cost machines and not on the application servers.
LiveDist intercepts database modifications in one of two mechanisms:
· By using database triggers (currently only supported for Oracle), which accumulate log of inserts, updates, and delete operations, in a shadow-table. The data is periodically fetched from the shadow-table, packed into a single buffer, and passed to LiveDist (by inserting the buffer into LiveDist’s log-table). This mechanism is transparent to the application, but has an overhead of executing the triggers and writing into the shadow-table. The overhead does not depend on the number of clients.
· When the application has access to the log of all database changes in the current transaction, the application can directly pass that log to LiveDist (via C# API), bypassing the triggers and the shadow-table.
LiveDist clients receive distributed data in one of two mechanisms:
· LiveDist clients use HTTP to access the distribution servers. The delta information is XML encoded (the column names are configurable), and thus the client can be written in any language and on any platform. Browsers, palm computers, and cellular phones can also be clients of LiveDist.
· Alternatively the delta information can be encoded in a more efficient binary encoding, and the client uses a C# API (provided by the product) for receiving distribution data and for decoding the binary data.
Main features of the LiveDist product:
· Fully scalable, can grow to support an unlimited number of clients, with no reduction in performance:
Most of the LiveDist software is deployed as C#-web-components (http-handlers). In each site, the web-components can be deployed upon any number of machines, utilizing ordinary HTTP load balancing. The machines have symmetrical functionality, and thus the system is linearly scaled when more machines are added. Additionally, no load is added on the application servers and the database servers, when more users are added. Thus the product is linearly scalable.
· Runs on low-cost hardware with no expensive third-party software:
The LiveDist servers require only CPU power and memory, with no use of internal databases or large files. Thus they are not required to run on expensive server machines. They can run on low-cost hardware, each machine supporting 300-1000 users (depending on load). Additionally, no expensive third party software is required (only standard C# is used). The used container is IIS.
· Supported databases:
The current release of the product supports SQL-server
and Oracle database engines.
· Short latency in delta-distribution:
Database modifications are distributed, to
all connected clients, in less than 0.5 seconds (when the communication
bandwidth is not a bottleneck). There is no degradation in latency when some of
the clients are loading snapshots (as long as the communication bandwidth is
not too small). Also, there is no degradation in latency when more clients are
added. When the communication to a client fails, other clients do not suffer
degradation in performance.
The product automatically recovers from all possible failures.
· Fast and concurrent cached snapshots:
When a new client first joins the system, a snapshot of a portion of the database (for all topics of interest declared by the client) is downloaded to the client machine. After the loading of the snapshot is completed, normal delta distribution begins (starting from the point in time when the snapshot has begun). Clients with local database can bypass the snapshot. When a client changes its topics subscription, a partial snapshot for the newly acquired topics of interest is downloaded to the client. The partial snapshot is synchronized with normal delta distribution, to preserve integrity. The cache servers contain live copies of customer chosen database tables. When a client needs to download a snapshot, it is already prepared in the memory of the cache servers (for cached tables). Thus no load is imposed on the application servers or on the database, to prepare the snapshot. The cache server also eliminates the lengthy process of fetching all snapshot rows from the database, by keeping a live copy of database tables in its own memory.
· Small overhead on the application servers and the database servers:
When using triggers, the overhead on the database servers is that of writing into the shadow-table. That overhead depends on the updates rate. Each modification fires a trigger, which executes an insert into the shadow-table (a small table without any indices). Periodically, and in a separate transaction, all rows from the shadow-table are read, packed into a single-buffer, inserted into a log-table, and removed from the shadow-table.
When not using triggers, there is almost no overhead on the database-servers. Just before the end of each transaction, a buffer containing all the modifications done in the current transaction is appended (in a single INSERT operation) into the log-table.
In both cases, there is almost no overhead on the application servers. All newly appended rows are periodically passed to the delta server, and that is the entire overhead.
Everything else is done inside the delta servers and the cache servers (running on other machines).
· No locking:
No database rows are ever locked by LiveDist.
· No 2-phase commit is required:
The passing of delta information to LiveDist does not require 2-phase commit transactions (in either mechanism). Note: using 2-phase commit causes transactions to take longer.
· Selective distribution using topic-subscription:
Each row can contain a field, which holds a comma-separated list of topics (alternatively the triggers can call application supplied routines for calculating the list of topics, which is based on the value of the row's columns). The row is distributed (published) to all the listed topics. The application fills in the value of this field. The application can update the topic-list (adding new topics to the list, and removing existing topics from the list). Each client, at anytime, is subscribed to a list of topics-of-interest. All rows, which are distributed to at least one of the topics-of-interest, are distributed to the client. It is possible to distribute all rows of a table to the same topic-list, in which case no column or function is required.
· New clients can join at any time:
The LiveDist product does not assume a stable network. On the contrary, it assumes that new clients can join the network at any time, and that some known clients can leave the network or become disconnected any time. The product guarantees stable performance to existing clients, even though the topology is continuously changing.
· Clients are frequently change their topic subscription:
It is quite normal for clients to change
their topics-of-interest from time to time.
The cache server enables these changes to be fast and not traumatic.
· Supports multi-site distribution (an hierarchy of sites model):
LiveDist supports a hierarchy of sites. Information is passed only once from a mother-site to every child-site. In each site we can run the servers on any number of machines, and thus each site is separately scalable. The support of this topology enables better utilization of the physical network.
· Highly available, guaranteed delivery, and automatic recovery from all possible failures:
When deploying the delta servers and the cache servers on multiple machines, the machines backup each other. When any machine fails, the others continue to function, and the clients continue to be served unnoticeably. When a new (or repaired) machine is added to the cluster, it automatically joins the load balancing task. When all LiveDist servers fail, the recovery is automatically done from the log-table in the database.
· Pluggable security framework:
The LiveDist product integrates with the application security subsystem, to authenticate clients, to encrypt messages between clients and servers, and to determine which topics are allowed to each client. LiveDist does not provide any security solution. Instead it interacts with the security solution used by the application.
· No code generation, fully configured by XML file:
The product does not need to change, when the data-dictionary is changed. The data-dictionary defines which columns from which tables to distribute. The data-dictionary is defined using an XML configuration file. No code generation is required when the data-dictionary (schema) is changed.
· Supports on-the-fly data-dictionary modifications:
When the data-dictionary is changed, the XML configuration-file is updated. The LiveDist product senses that change (at a single location), and automatically adapts to the new data-dictionary. The system needs no reboot, or even suspension.
· Zero administration:
No administrator or operator is required, when using LiveDist. The software components are deployed once on all participating machines. After deployment, LiveDist servers can be considered as black boxes, and they require no administration.
· Oracle 8i or above
· SQL-server 2000 or above
On Web-server machines (one for each 300-1000 users):
· .Net 2.0 or abover.
· 2 Giga-Bytes memory.
On client machines:
Nothing, when client is receiving XML buffers (over HTTP connection).
.Net runtime environment version 2.0 or above (when client is receiving C# objects).
No special memory or CPU requirements.