WO2006046070A1

WO2006046070A1 - Decentralised database network

Info

Publication number: WO2006046070A1
Application number: PCT/GB2005/004189
Authority: WO
Inventors: Richard Punter; Cameron Fletcher; Derek Orr
Original assignee: Contextus Limited
Priority date: 2004-10-27
Filing date: 2005-10-27
Publication date: 2006-05-04
Also published as: GB0423815D0

Abstract

A decentralised database network in which the functionalities required for operation of the database and/or network are distributed between the nodes within the network. The system has a number of nodes each of which have a number of states including client and server components for both the database and a network. The extent of use of each of the components on each node is optimised depending upon the overall requirements of the database system.

Description

Decentralised Database Network

The present invention relates to a decentraILised database network and in particu-lar to a system in which the functionalities requinred for operation of tine database and/or network is distributed between the nodes within the network.

Simple peer-to-peer (P2P) network file sharing applications are known in the art. Typical examples of such systems include Mapster and Limewire. The purpose of these systems is to pr-ovide an 'on-line community' in which a decentralised group of machines pooX their resources for mutual t>enefit.

In general, the nature of P2P file sharing applications allows individuals to join communities and fco share media with one another for mutual benefit . Very few restrictions on participation are imposed and there is little overall structure to the system. For example, one feature of Napster is that it allows music file sharing, therefore, when additional participants join the networte, more music files and usually a greater variety of such files are made available to the participants.

Traditional databases are used for a variety of purposes, for example storing bank records, information on membership of an organisation, or the like. Databases a_cre structured to ha-ve a one or more tables containing data which may be inserted, removed, updated, or queried. Logs may be generated to monitor and record changes to the data contained in the database. A database that can stoztre data in a structure consisting of one or more tables that may be interconnected is referred to as a relational database. Typically databases use Structured Query Language (SQL) for data definition, data management, ancϋ data access and retrieval.

Existing P2P systems do not allow the creation of traditional data-bases or relational databases in which the data is held, in locations across the network. This functionality is one object of the present invention. It is a further obj ect of the present invention to provide secure authentication of database users.

In accordance wd_th a first aspect of the present invention there is provided a system for operating a distributed database, the system comprising a plurality of nodes wherein each of said nodes has a plurality of node states including client and server components for both the database and the network and wherein the externa of use of each of said functionalities on each node is optimised by optimisation means dependent upon the overall requirements of the database system. The present invention provides a distributed database in which nodes form a multi-level hierarchical structure in multiple planes of varying capacities and can dynamically move between levels in the hierarchy under control of the network providing different node functionality.

Preferably, the extent of use or loading of said functionality on tlie node is dependent upon the performance and resource capability of the node to carry out different functionality.

Preferably, each node is a device with a central processing unit and. memory.

Optionally, the node is a personal computer.

Optionally, the node is a mobile communications device.

Preferably, the performance capability of the node may be determined by one or more of the following variables: processor power; memory (hard drive and ram) ; traffic throughput, available resource, network access time; up- time, and speed of connection of the node to the network.

Preferably, the piresent invention further comprises a bootstrapping means for connecting a node to the network.

Preferably, the piresent invention further comprises an authentication means for connecting the node to a network. Optionally, the optimisation means is provided by the network functionality.

Preferably, the optimisation means is capable of selecting the client and/or server functionality for use in a node.

Optionally, the network server functionality may be implemented as a communicat ions node and/or communications standby node .

Preferably, the database server functionality may be implemented as an infrastructure node and/or infrastructure backup node.

Preferably, the optimisation means is provided through: node identification means; analysis means for analysing the performance capability of each node; ranking means for arranging each node in order in a rank; assigning means for assigning one or more functions to each node based on their rank.

Preferably, the ranking means ranks nodes depending upon node performance and resource capability.

The architecture of the system consists of a database layer operating on top of a network layer. This functionality can be implemented using network and database algorithms in conj -unction with optimisation using defined protocols for network and database communication. A network protocol can be ixsed to facilitate communication between nodes . The software used to implement the network protocol may be built in modules.

The database layer of the present invention is de- centralised and self-optimi.sing to ensure overall database integrity and is distributed among nodes.

Preferably, each node is capable of adopting the functionality of any other node in the system.

Therefore, no one node is explicitly dependant on any other node and any node can do the job of any other node and, consequently, there is never a scenario in which any given node is considered crritical for the network and/or database components to function. Therefore, that any node in the network is never dependant upon any other specific; node

Preferably, data tables forr all data in the database network are divided in sucrα a manner that any one record is split such that each whole record is located on more than one node and never just one node.

The nodes may be connected via a public or a private network. A node can be a PC, workstation or server on any platform or a mobile or fisced communications device with or without embedded processing technology. Each node may be loaded with the same software to implement the invention on the node. 1 The present invention consists of interlinked, nodes

2 containing the same software. The software peαrforms tasks

3 for the database, network and tasks for the end-user. 4

5 Typically, a mult±-state model can be defined in which

6 the functionality of each node is dependant upon its

7 state which in turn may be based on optimisation. In this

8 model, each physical node such as a PC or mobile device

9 is defined in terms of functionality that is enabled by .0 the software made in accordance with the present

.1 invention.

.2

.3 The functionality is def ined in accordance wi th the

.4 overall network requirements upon optimisation of the

.5 network . These can be identif ied as the following node

.6 states .

.7

.8 Client node (Tert±ary role) _/ having client functionality

.9 Typically, a Client node connects to one comnrunications

> 0 node and all communication with the network i s performed

I l via that communications node . Each node has c lient

>2 functionality regardless of state .

>3

.4 Communications node (Secondary role) ; having

.5 communications functionality

.6 A communications node is a routing node with the ability

.7 to route coitimunication throughout the network: .

_8 Communications nodes are typically connected to one

-9 infrastructure node and authentication is ach-ieved via

30 this link. Communications nodes are nodes tha.t have been

31 assigned that functionality by the network.

32 Communications nodes may have client functionality. 33 Infrastructure node (Primary roj_e) ; having communications and database functionality Infrastructure nodes form the backbone of the database network. Each infrastructure noole can connect to all other infrastructure nodes. Between them they house the distributed database in its entirety. Infrastructure nodes may have communications fxαnctionality and client functionality.

Preferably, the network component of a node comprises a seamless communications layer upon which the database component resides

Preferably, the the optimisation component of a node resides on the communications layer.

Preferably, the network component allows additional nodes to join the network and remove themselves from the network without affecting node communication or network integrity.

The functionality of this component uses algorithms in^" order to achieve these criteria..

Preferably, the network component interfaces each dependant component on a networ-Ik level and provides for a means by which the components can communicate.

Preferably, the network component (server-side) allows _ new nodes to join the network and for existing nodes to leave the network. Preferably, the network component (client-side) provides the means to request a connection and request disconnection to/from the networrk.

Optionally, every node generates a loading figure, which is typically calculated from a combination of the processing power, memory, available resource, up-time, openrating system, traffic throughput and connection speed to other nodes on the network. The loading figure may determine the node state of the node on the network which. in turn determines the functionality of that node.

The end-user is typically unawarre of their node state as it only affects the nature of ttα.e background interaction between the nodes.

Preferably, each node contains information on it's performance from which the loading figure may be derived. The network optimisation process can dynamically change the node state.

Optionally, it is the infrastructure nodes that are responsible for the continuous optimisation of the entire network. In effect, the performance of each node determines the structure of the network.

Optionally, the nodes communicate via a secure connection.

Opt ionally, there is a management interface for the management of the network . Optionally, there is an administration account logon to allow management of the network.

Preferably, the infrastructure nodes store the decentralised database. If a node state is changed to an infrastructure node some of the database data contained upon other infrastructure nodes will be passed to it . If a node state is changed from an infrastructure node thie database data contained upon that node will be passed to other infrastructure nodes.

Optionally, if a node state is changed to a communications node or an infrastructure node it will assume the additional functionality associated with its new state .

Optionally, load figure statistics can be passed to tine infrastructure nodes, which in turn may optimise network configuration. Ttie resultant network changes are appl-±ed via algorithms implemented within each node. The infrastructure nodes may manage the implementation of auxiliary backup and standby nodes.

Below is a simple algorithm that the current inventiom. may use to ensure that any node in the network is awa:re of all other nodes in the network at any time.

Each node contains a table which includes node identities for each node and. the identity of the node it is currently connected to. See Fig 18.

Within the network there is always one node that acts in a serving capacity only and does not have a client connection to another node. This is the primary node and serves as the authority for the rest of the nodes within the network. The primary node is usually the first node in the network.

When a node joins the network it may attempt to connect to a non-specific node in the network.

Example, if node n tries to connect to node 5:

1. Node 5 identifies the primary node from its node table and connects to it. 2. Node 5 tells the primary node that a node is trying to connect to it. 3. The primary node assigns the new node a node identity (node 7) . 4. The primary node informs all of its clients (nodes 2 and 4) that node 7 is connected to node 5. 5. The primary node informs node 5 that the new node is node 7 and it can now connect. 6. The server element of the network component on each node (from the Primary, in tiαrn) informs its clients of the addition of the new node until total propagation throughout the network is actαieved.

If a node disconnects:

1. Its clients connect to the node to which it was connected. 2. The client tables are revised to reflect the changes and the primary node is infonrmed. 3. Propagation occurs. If the Primary node disconnects:

1. Node 2 and 4 acknowledge the disconnection (or are aware when triey try to connect to it) . 2. As node 2 is higher in the node table both nodes know that node 2 d_s to assume primary node. 3. Node 4 revises its table (removes entry 1, and replaces any l's in Connected To, to 2's) and informs its clients. 4. Node 4 connects to node 2 which is expecting a connection. 5. Node 2 revises its table and informs its clients.

Preferably, clients may be informed earlier than a full propagation, if the server node serving them has lost communication w±th the primary node.

Preferably, the process should allow propagation of oth&r information.

A simple node connection/disconnection scenario showing resilience can be seen in fig 17:

Fig 17-1 shows two nodes, node 2 connecting to node 1 (Primary node) • Node 1 authenticates node 2 and propagates the node table to it.

Fig 17-2 shows three nodes, node 2 connected to node 1 (Primary node) and node 3 connecting to node 1 (primary) Node 1 authenticates node 3 and propagates the node tabILe to all of its clients. Fig 17-3 shows four node£3 , node 2 connected to node 1 (Primary node) , node 3 connected to node 1 (Primary node) and node 4 connecting to node 3. Node 3 creates a proxy connection to node 1 and node 1 authenticates node 4 and sends the authentication response to node 3. node 3 sends authentication response to node 4 and node 1 propagates the node table to all of its clients, which in turn propagate the node table to all of there clients.

Fig 17-4 shows five nodes, node 2 connected to node 1 (Primary node) , node 3 connected to node 1 (Primary node) and node 4 connected to rxode 3 and node 5 connected to node 4. Node 4 creates a proxy connection to node 1 and node 1 authenticates node 5 and sends the authentication response to node 4. node 4 sends authentication response to node 5 and node 1 propagates the node table to all of its clients, which in turrn propagate the node table to all of there clients, which then in turn propagate the node table to all of there clients.

Fig 17-5 shows four nodes, node 2 connected to node 1 (Primary node) , node 3 connected to node 1 (Primary node) and node 5 connected to node 3. node 4 has disconnected, node 5 consulted its node table and connected to the node to which node 4 was connected (node 3) . Node 3 informed nodell (via proxy) that node 4 has disconnected, node 1 amends its node table ancL performs node table propagation.

Fig 17-6 shows three nodes, node 3 connected to node 2 (new Primary node), node 5 connected to node 3. node 1 (old primary node) disconnected. Node 2 assumed primary. 1 Node 3 consulted its node table and connected to node 2

2 (new Primary node) 3

4 Preferably, the database component provides SQL-based

5 relational database client/server functiona_lity that

6 conforms to the following criteria: 7

8 Preferably, the stored data always resides in more than

9 one location. 0

1 Pref erably, therre is no central database server . 2

3 The conventional, relational database is comprised of

4 three core elements ; client , server and communications .

5 The manner in whLich these elements interact in the

6 present invention varies substantially from a traditional

7 relational database . 8

9 The database client is an element of the database

0 component that provides database client functionality on

1 all nodes . 2

3 The database server element of the database component on

4 an infrastructure node provides database server

5 functionality to all nodes. ,6

:7 The database server as a whole is comprised! of a

:8 collection of database server elements (of the database

:9 component) on infrastructure nodes, connected via the

>0 network component. il

12 The database client will provide a means of allowing SQL

13 statements to be communicated to and from the database server(s) . It is effectively an interface to the database server (s) .

In respect of the database component the following should be true.

Preferably, the database client is able to connect, authenticate and disconnect from the server (s) .

Preferably, the database client is able to parse SQL statements to the server(s) .

Preferably, the database client has the ability to receive record-sets and messages from the server(s) .

Preferably, the network client element of the network component handles all database client/server communication to and from the client. The network component upon which the database client resides may be optimised.

For database client inbound traffic, an event will be raised to perform a procedure related to it. The database client may have to interpret the data which will be comprised of but not limited to one of the following three types: partial record set data with a segment identity; record-set segment structlire data; and/or server messages.

Upon receipt of one of tlxese 3 data types the database client may take the appropriate action which may be as follows: 1 interpret the data and store it until the record set is

2 complete then output the data ( optionally, raise a

3 progress event to allow the interface to display

4 progress) ;

5 interpret the data and use it to join together

6 stored/future record sets relating to that transaction;

7 raise a. local event pertaining to the specific error

8 stored in the data. 9

LO In order to allow the client to make sufficient use of

Ll the data it may also be stored locally in a record-set

L2 variable. L3

14 The database server is to process and respond to SQL

15 requests from the database client. An algorithm for

16 distributed processing of data as a data command may be

17 communicated through only one cLatabase server but may be

18 returned by many database servers. In addition, an

19 algorithm may control the connection and disconnection of:

20 database server (s) . 21 2 Prefer-ably, the database serve.tr is able to interpret and 3 process SQL statements. 4

25 Preferably, the database server has the ability to returra.

26 record sets and errors to the client. 27

28 Preferably, the database serve.tr is able to communicate

29 with all other database servers.

30

31 Prefer-a.bly, the database servear can accept incoming

32 commun.ication from all other database servers. 33 Preferably, the database server can store partial recorcl- set data locally.

Preferably, the database server can pinpoint data stored! on other database servers with ease.

Preferably, the database server holds a partial record.

Preferably, the server element of the network component handles all database client/server communication to and from the database server.

Inter server communication between database servers may be required within the database model . It may be necessary for the servers to communicate with each othexr in matters relating, but not limited to query result timing, data storage, transaction processing, and allowing for connection and disconnection to/from the server pool .

Optionally, incoming SQL statements may be processed, interpreted, and compiled into an internal database server request fox record-sets.

A communication protocol may provide for (but is not limited to) all aspects of database communication. The complexities of tliis may be handled by the network laye=r^λ

The network layer" may accommodate for the following elements of interaction necessary for database functionality:

Preferably, Client Requests Preferably, Server Responses Preferably, Inter Server Communication

Connections to/from the database servers are complex in their nature. In respect of this the network layer may handle communication.

Database control overheads are kept to a minimum so as not to use bandwidth from data queries/results.

When a node is connected to the network, the ability of each node to function as a particular component of the network is known to the network. This is achieved through.. a load analysis performed on each node taking into consideration items such as , but not limited to; bandwidth, processor speed, available resource, access time (ping), etc. The network also determines when each node or nodes are required to change state.

The table in figure 8 is an. example illustration of a possible relationship between the load figure on a node and the resultant node functionality. Nodes may operate with more than one level off functionality (multiple node states) at the same time i. e. in this example a node of value 3 is both a Client aixd a Communication Standby. Therefore the nodes can be ranked according to the load analysis and functionality can be ascribed to each node on the basis of the rank gd-ven;

Additional node types can also be specified.

Within the network every node whose presence is critical to communication within the network can have standby L node ( s) that are in a position to immediately replace a

2 node so that communication (both for network and

3 database) i s never compromised . The numbers of standby

1 nodes per node may be determined by network topology . 5

S Similarly, within the database every node with data

7 critical to the database network can have backup node (s)

8 that synchronise this data so that it: is not solely

9 located in one place . The number of backup nodes per node 0 may be determined by network topology .

1

2 The node state of any one node determines its

3 functionality. A node can function on more than one level

4 at the same time on different threads, depending upon

5 network requirements e.g. a backup for a node may also be

6 a standby Eor another node. 7

8 The more functional nodes (the communications and

9 infrastructure nodes) synchronise copies of their data

0 and node connections with standby/backup nodes so that in

1 the instance in which a node is disconnected another may

2 replace it . 3

4

5 The data tables for all data in the database network can

6 be divided in such a manner that no one infrastructure

:7 node ever houses an entire record, omly ever a segment of

: 8 the record - This ensures that the da_ta cannot be

!9 comprised at node level .

I O

>1 The physica.1 location of the data ca_n be concealed in the

52 background,, the data is constantly r~oaming (as part of

!3 the optimisation process) . This ensu.res it is not 1 possible for an end-user to determine which nodes contain

2 the data. 3

4 Certain fields contain 'locked' data. Their values may be

5 queried but not returned, set but not modified. This

6 ensures that sensitive data is never t-transmitted in a

7 whole form across the network. 8

9 The result of these constraints is suchi. that when a user

LO connects arαd authenticates, their password and username

Ll are passed (e.g. their password as an encrypted

L2 signature) , queried remotely, and either authenticated or

L3 not - remotely. In the case of a successful

L4 authentication a session variable is set remotely and

L5 locally which is then used for all communication

L6 thereafter. This has the additional benefit of ensuring

L7 that no one user can log on to the database network in

L8 two or more separate instances. 19

20 Consequently, as a result of that process, there is in

21 effect the successful implementation of a managed

22 network. Security profiles may be set, logs may be taken

23 - all of which happens remotely. As every database query

24 requires the user to be authenticated for communications

25 purposes the database network cannot be compromised. 26

27 In accordance with a second aspect of "the present

28 invention, there is provided a computeir program for 29 causing a computer to become a node of a distributed

30 database in accordance with the first aspect of the 31 present invention.

32 1 In accordances with a third aspect of th.e present

2 invention, tlxere is provided a distribu ted f ile sharing

3 system compri sing a distributed databas e in accordance

4 with the first aspect of the invention. 5

6 In accordance with a fourth aspect of t he invention,

7 there is provided a software validation, tool comprising a

8 distributed database in accordance witlx the f irst aspect

9 of the invention . .0

.1 In accordance with a f if th aspect of thie invention, there

.2 is provided a. telecommunications infrastructure

.3 comprising a distributed database in accordance with the

.4 f irst aspect of the invention .

-5

16 In accordance with a sixth aspect of trie invention, there

L7 is provided an Air traffic control and communication

L8 system comprising a distributed database in accordance

L9 with the first aspect of the invention-

20

21 In accordance with a seventh aspect of the invention,

22 there is pro-vided a Military command and control network

23 comprising a distributed database in accordance with the

24 first aspect of the invention. 25 6 The benefits include: 7 8 Self optimising architecture as the infrastructure nodes 9 endeavour to maintain the most efficient node structure 0 for the network. This helps make the database as 1 efficient as possible. 2 A high level resilience as in the instance in which a node is removed the database remains intact.

The distributed (database network offers an extremely high level of security.

The present invention follows an inverse capacity model. When a node is introduced to the network of the present invention, it serves to increase the network and database capacity, not decreasing it as would be the case with traditional databases and or networks.

There are multiple applications of the technology.

The present invention will now be described by way of example only with reference to the accompanying drawings in which:

Fig . 1 is an illustration of conventional database architecture;

Fig. 2 is an illustration of any one node in accordance with one example of the present invention;

Fig. 3 is an illustration of connectivity associated with the functionalities present in examples of the present invention;

Fig . 4 is an illustration of the authentication procedure used with the present invention;

Fig . 5 shows a three- tier database network in accordance with the present invention; Fig . 6 shows the database component back up conf iguration ;

Fig 7 shows the network component standby configuration;

Fig 8 shows a simple nocLe functionality table configuration and associated node capacities/roles in accordance with the present invention;

Fig 9 shows a typical virtual connection diagram for primary nodes (infrastruicture) ;

Fig 10 shows a typical virtual connection diagram for secondary nodes (communication) ;

Fig 11 shows a typical virtual connection diagram for tertiary nodes (client) ;

Fig 12 shows a typical network architecture overview in accordance with the present invention;

Fig 13 shows typical database client/server communication interfaces in accordance with the present invention;

Fig 14 shows typical database server/server communication interfaces in accordance with the present invention;

Fig 15 shows a typical network interface overview in accordance with the pre sent invention ;

Fig 16 shows a detailed overview of the pref erable (and optional ) interfaces in accordance with the present invention ; 1

2 Fig 17 shows a simple node c onnection/disconnection

3 scenario for the present invention ; and 4

5 Fig 18 illustrates a primary node collection

6 ( infrastructure) algorithm example . 7

8 Fig . 1 illustrates a convent ional database architecture

9 that represents the current state of the art . In this , a LO client [1] is typically a user ' s PC or other similar

Ll device and is connected to a. central server which

L2 contains the database [2 ] . Clearly, where a number of

L3 clients [ 1 ] are using the central server [2 ] , an increase

L4 in the number of clients wil l decrease the ef f iciency of

L5 the server and the database contained on the server .

16

17 Fig. 2 shows the overall architecture of a physical node

18 [3] in accordance with the present invention. The presen-t

19 invention provides for splitting the functionality of 0 each node [3] such that it can act as an infrastructure 1 node [7] , communications node [8] , or a client node [9] . 2 As has been described previously use of the physical nod.e 3 is optimised in accordance with the requirements of the 4 overall network such that each node [3] may include one 5 or more of the abovementioned functionalities. 6 7 Fig. 3 shows the connectivity between each type of

28 functionality (node role) . This connectivity can extend 9 beyond each physical node to other nodes. Therefore, eac:h

30 client (N_τ) [9] is connected! [14] to a communications nocle

31 (N_s) [8] and this communications node (N_s) [8] provides

32 communication between clierxts (N_τ) . In addition, each

33 communications node (N₃) [8] is connected [13] to an 1 inf rastructure node (N_P) [ 7] which provides additional

2 server and database functionality . 3

4 Fig . 4 shows trie connectivity between the inf rastructure

5 node [7] , communications node [8] and the client node [9]

6 for the present invention and also shows the steps

7 required for authentication . As shown, the end. user

8 enters login details and this information is transmitted

9 via the communications node [ 8 ] to the inf rastructure

0 node [ 7 ] . The present invention authenticates the login

1 details ; the session variable is set and returned to the

2 client node [ 9 ] . 3

4 Fig . 5 shows an embodiment of a three- tier database

5 network in accordance with the present invention . In this

6 example of the present invention a number of cXient nodes

7 (N_τ) [ 9 ] are sriown, these are each connected to the

8 communication nodes (N₅) [ 8] which are connected to a

.9 primary node collection [ 15 ] . The overall architecture of

0 this embodiment of the present invention is similar to

1 that discussed above . 2

3 Fig . 5 is designed to show the functionality of the

:4 various parts of a network made in accordance with the

: 5 present invention . It should be noted that the

: 6 arrangements shown do not necessarily represent physical

17 connections between separate physical locations in a

18 network system . ! 9

10 Fig . 5 shows an overall structure (excluding auxiliary

11 standby and backup nodes ) of a dynamic network system in

12 which addition of physical nodes to the network allows

! 3 the network to re- optimise itself in order to attain the 1 best overall network efficiency - This is achieved through

2 constant optimisation of the system in a manner as

3 described above. Nodes may have multiple physical access

4 connections and or points to the network e.g. broadband,

5 WiFi, r-adio, leased line, etc. 6

7 Fig 6 shows auxiliary backup nodes (N_AB) [10] which are

8 provided for the infrastructure nodes (N_P) [7] . 9

LO Fig 7 shows auxiliary standby nodes (N_AS) [11] which are

Ll provided for the communications nodes (N_s) [8] .

L2

L3 Fig 8 shows an example of a simple functionality table

L4 describing the relationship between a load figure upon a

L5 node and the resultant operational node capacity/role.

16 The diagram beneath the table i llustrates the possible

L7 combined capacity/roles of each node in the given example

L8 and in accordance with the present invention.

L9

20 Fig 9 shows the virtual connection path diagram for the

21 infrastructure layer. This embodiment of the present

22 invent±on also shows the mesh network connection [12] and

23 alternative connection paths wb_ich connect together all

24 of the nodes operating in a primary role (N_P) [7] in a

25 mesh structure, allowing direct communication between all

26 of the nodes operating in a primary role. 27

28 Fig 10 shows the virtual connection path diagram for the

29 communications layer.

30

31 Fig 11 shows the virtual connection path diagram for the

32 client layer. 33 1 Fig 12 is a depiction of the network architecture

2 overview showing the database component (client- side)

3 [4 ] , connecting through the network component [5 ] , to the

4 DDN 15 . 5

6 Fig 13 is a depiction of the typical database

7 client/server- communication interfaces, showing the

8 database component (client-side) [4] , connecting through

9 the network component [5], to the DDN [15] which then in

0 turn connects via the network component [5] again, to the

1 database components collection [16] . 2

3 Fig 14 is a depiction of the typical database

4 server/server: communication interfaces, showing the

5 database component (server-side) [4] , connecting through .6 the network component [5] , to the DDN [__5] which then in .7 turn connects via the network component [5] again, to the .8 database components collection [16] .

.9

!0 Fig 15 is a depiction of a typical network interface

!1 overview showing the interconnectivity between database

12 components through the DDN [15] .

>3

54 Fig 15 shows the database component (cli_ent-side) [4] ,

.5 connecting through the network component [5] , to the DDN

16 [15] which ttien in turn connects via the network

-7 component [5] again, to the database components

28 collection [1.6] .

29

30 Fig 15 also shows the database component ( server- side)

31 [4 ] , connect ing through the network comiponent [5] , to the

32 DDN [15 ] whi ch then in turn connects via. the network 1 component [5] again, to the database components

2 co llection [16] . 3

4

5 Fi g 16 shows a detailed overview of the preferable (and

6 optional ) interfaces in accordance with the present

7 invention . 8

9 Fd_g 17 is a depiction of a tyχ>ical simple node .0 connection/disconnection scenario . .1

.2 Fi.g 18 is a depiction of a typical primary node .3 collection algorithm example . .4

.5 A distributed database networrk (DDN) Description and Key .6 is provided as follows . L 7

L 8 Ar2y: IS

10 1 . Conventional Database Client ,

11 2 . Conventional Database Server ; 22

23 Wtien combined (in terms of functionali ty) , may be 4 considered : 5 6 3 . Any DDN Node ; 7 8 Comprising of the following components : 9 0 4. DDN Database Component (Client/Server 1 Interfaces) , 2 5. DDN Network Component (Client/Server 3 interfaces) , 1 6. DDN Client Component (Client Interface); 2

3 which, operatJ-ng in one of the following roles: 4

5 7. Primary Role (Infrastructure Node),

6 8. Secondary Role (Communications Node),

7 9. Tertiary Role (Client Node); 8

9 and, optionally in one or more of the following roles: 0

1 10. Auxiliary Backup Node (DDN Database Componant) ,

2 11. Auxiliary Standby Node (DDN Network Component); 3

4 Over the following network links: 5

6 12. Primary/Primary Communication ILink (optional

7 TCT/IP via DDN Network Component) ,

8 13 • Primary/Secondary Communication Link (optional

9 TCP/IP via DDN Network Component) ,

0 14. Secondary/Tertiary Communication Link (optional

1 TCP/IP via DDN Network Component) ; 2

3 which can be grouped as (if in a Primary Role) ; A

:5 15. Primary Node Collection;

'.6

17 comprised of :

!8

!9 16 . Prd_mary Node Collection (DDN Database i 0 Component) ,

S l 17 . Primary Node Collection (DDN Network

J 2 Component) ;

53 may be considered component of the DDN.

Primary State (Infrastructure Node) [7]

Secondary State (Communications Node) [8]

Tertiary State (Client Node) [8]

N_AB) Auxiliary Backup Node (DDN Database Component) [10 ]

N_{AS i} Auxiliary Standby Node (DDN Network Component) [11 ]

Primary Node (Primary Role)

Secondary Node (Primary Role)

Tertiary Node (Primary Role)

PRODUCTS LISTINGS

A number of products will now be described in which the various aspects of the present invention may be implemented.

PRODUCT ONE

A distributed fi3_e system. (DFS) This may be an iixternet based file sharing system with similarities to the existing software for file sharing communities. In the system, files that you want to share are placed in a Local directory for sharing and access to files from anyone else who is connected to the network from their local directory for sharing is provided.

The benefits of ixsing the present invention for this type of application would include:

1. A managed network; no other existing DFS operates on SL managed basis with secure login, logged and managed activity.

PRODUCT TWO

A commercial software validation tool.

A tool which wouILd enable all software that inherently uses a network to require authentication in order to function.

The benefits of msing the present invention for this type of application include:

2. Eradication of unauthorised software copying or use of illegal software on a system or network that requires access to the network running the DDN (e.g. internet, intranet) .

PRODUCT THREE A resilient database .

The benefits of using the present invention for this type of applicat±on include :

1 . Resilience as the data contained on the DDN remains live and accessible even when nodes are switched of f /disconnected . This is directly related to the optimising nature of the DDN . 2 . Security is high as there is no means of unauthorised access . No way of determining where the data actually is and as such no way of accessing it without authorisation . 3. The data capacity for the DDN is directly proportional to the number of nodes.

PRODUCT FOUR

A telecommunications infrastructure .

The benefits of using the present invention for this type of applicat±on include:

1. Inter-node communication. 2. No traditional infrastructure. 3. Wide bandwidth with spread-spectrum technology.

PRODUCT FIVE

An air traf f ic control and communication system

The benefits of using the present invention for this type of application include: L

1 1. Global awareness and proximity of all aircraft J 2 _ Secure communications between aircraft nodes

. 3. Eliminates the need for black box equipment as

5 aircraft data is distributed across nodes, e.g all

5 flight data is stored remotely.

7

3 PRODUCT SIX

9 A military command and control network

Tϊie benefits of using the present invention for this type of application include:

1. Increased reliability and functionality using a DDN technology in existing- drones. 2. To further advance military effectiveness and efficiency new drones may be developed based upon DDN technology combined with associated Artificial Intelligence allowing" many units to act as one.

Improvements and modifications may be incorporated herein without deviating from the scope of the invention.

Claims

1 Claims 2

3 1. A system for operating a distributed databases, the

4 system comprising a plurality of nodes wherein each of

5 said nodes has a plurality of node states including

6 client and server components for both the database and

7 the network and wherein the extent of use of each of said

8 components on each node is optimised by optimisati-on

9 means dependent upon the overall requirements of the .0 database system.

.1

.2 2. A system as claimed in claim 1 wherein, the extent

.3 of use or loading of said functionality on the node is

A dependent upon the performance and resource capabi-lity of

.5 the node to carry out different functionality.

16

L7 3. A system as cla.imed in claim 1 or claim 2 wherein,

L8 each node is a device with a central processing unit and

L9 memory.

20

21 4. A system as cla_imed in any preceding claim whαerein,

22 the node is a persorxal computer. 23

24 5. A system as claimed in any preceding claim wtierein,

25 the node is a mobile communications device. 26 7 6. A system as claimed in any preceding claim wtierein, 8 the performance capability of the node may be determined 9 by one or more of thie following variables: processor 0 power; memory (hard drive and ram) ; traffic throughput, 1 available resource, network access time; up-time, and 2 speed of connection of the node to the network. 3 7. A system as claimed in any preceding claim further comprising a bootstrapping means for connecting a node to the network.

8. A system as claimed in any preceding claim further comprising, an authentication means for connecting a node to the network.

9. A system as claimed in any preceding claim wherein, the optimisation means is capable of selecting the client and/or server functionality for use in a node.

10. A system as claimed in any preceding claim wherein, the network server functionality is implemented as a communications node and/or communications standby node.

11. A system as claimed in any preceding claim wherein, a database server is implemented as a infrastrαicture node and/or infrastructure backup node.

12. A. system as claimed in any preceding claiiti wherein, the optimisation means is provided through: node identification means; analysis means for analysing the performance capability of each, node; ranking means for arranging each node in order~ in a rank; and/or- assigning means for assigning one or more functions to each node based on their rank.

13. A. system as claimed in claim 12 wherein, the ranking means ranks nodes depending upon node performance and resourrce capability.

14. A system as claimed in any preceding claim wherein the system has an architecture comprising a database layer operating on top of a network layer.

15. A system as claimed in any preceding claim wherein a network protocol facilitates communication between nodes.

16. A system as claimed in claim 15 wherein the network protocol is implemented using software modules.

17. A system as claimed in any preceding claim wherein, each node is capable of adopting the functionality of any other node in the system.

18. A system as claimed in. any preceding claim wherein, data tables for all data in. the database network are divided in such a manner tbiat any one record is split such that each whole record, is located on more than one node.

19. A system as claimed in any preceding claim, wherein the functionality of each node is dependant upon its state.

20. A system as claimed in claim 19 wherein the state of each physical node is defined in terms of said functionality.

21. A system as claimed in claim 20 wherein the functionality is defined in accordance with the overall network requirements upon optimisation of the network.

22. A system as claimed in any preceding claim wherein the nodes are defined by node states.

23. A system as claimed in claim 22 wherein the clien_t node (tertiary) functionality comprises connection mea_ns for connecting to tine server element of the network component on an infrastructure or communications node.

24. A system as claimed in claim 22 wherein the Network component of the communications or infrastructure node comprises routing means for routing communication throughout the network.

25. A system as claimed in claim 24 wherein the communications node is connected to one infrastructure node and authentication is achieved via this link.

26. A system as claimed in any preceding claim wherei_n an infrastructure node is provided having communications and database functionality.

27. A system as claimed in claim 26 wherein the infrastructure node is connectable to all other infrastructure nodes.

28. A system as claimed in any preceding claim wherein, the network functionality comprises a seamless communications layer upon which the database component resides.

29 . A system as claimed in any preceding claim whered.n the optimisation means resides on the communications layer .

30. A system as claimed in any preceding claim wherein, the network component allows additional nodes to join the network: and remove themselves from the network without affecting node communication or network integrity.

31. A system as claimed in any preceding claim wherein, the network component interfaces each dependant component on a network level and provides for a means by which the components can communicate.

32. A system as claimed in any preceding claim wherein, the server element of the network componeixt allows new nodes to join the network and for existing^" nodes to leave the network.

33. A system as claimed in any preceding claim wherein, the client element of the network component provides the means to request a connection and request disconnection to/from the network.

34. A system as claimed in any preceding claim wherein every node generates a loading figure, calculated from a combination of the processing power, memozery, available resource, up-time, operating system, traffic throughput and connection speed to other nodes on the network.

35. A system as claimed in claim 34 wherein the loading figure may determine the node state of the node on the network which in turn determines the functionality of that node.

36. A system as claimed in any preceding claim wherein, each node contains information on. its performance from which the loading figure may be derived.

37. A system as claimed in claim. 27 wherein the infrastructure nodes are responsible for continuous optimisation of the entire netwoirk.

38. A system as claimed in claim 27 and claim 36 wherein the infrastructure nodes store ttxe decentralised database.

39. A system as claimed in claims 36 to 37 wherein the load figure statistics can be passed to the infrastructure nodes, which in tmrn may optimise network configuration.

40. A system as claimed in any preceding claim wherein, the database component provides SQL-based relational database client/server functionality.

41. A system as claimed in claim 40 wherein, stored data resides in more than one location.

42. A system as claimed in claim 40 and claim 41 wherein, the database client is able to connect, authenticate and disconnect from the database server(s) .

43. A system as claimed in any one of claims 40 to 42 wherein, the database client is able to parse SQL statements to the database servear (s)

44. A system as claimed ±n any one of claims 40 to 43 wherein, the database client has the ability to receive record-sets and messages from the database server(s) .

45. A system as claimed in any preceding claim, further comprising a client network interface which handles all database client/server communication to and from the client.

46. A system as claimed, in claim 40 wherein the network component upon which the database client resides is optimised.

47. A system as claimecl in claims 40 and 46 wherein, the database client has to ±nterpret the data which will be comprising: partial record set data with a segment identity; record-set segment structure data; and/or server messages.

48. A system as claimed in claims 40, 46 and 47 wherein, upon receipt of one of these 3 data types the database client may: Interpret the data and store it until the record set is complete then output the data (optionally raise a progress event to allow the interface to display progress) ; Interpret the data and "use it to j oin together stored/future record sets relating to that transaction; and/or raise a local event pertaining to the specific error stored in the data.

49. A system as claimed in claim 13 and claim 40 wherein the database server processes and responds to SQL requests from the database client.

50. A system as claimed in claims 13, 40 and 49 wherein, the database server is able to interpret and process SQL statements.

51. A system as claimed in claims 13, 40, 49 and 50 wherein, the database server has the ability to return record sets and errors to the client .

52. A system as claimed in claims 13, 40 and 49 to 51 wherein, the database server is able to communicate with all other database servers.

53. A system as claimed in claims 13, 40 and 49 to 52 wherein, the database server can accept incoming communication from all other database servers.

54. A system as claimed in claims 13, 40 and 49 to 53 wherein, the database server can store partial zrecord-set data locally .

55. A system as claimed in claims 13, 40 and.49 to 54 wherein, the database server can pinpoint data stored on other databa.se servers with ease.

56. A system as claimed in claims 13, 40 and 49 to 55 wherein, the database server has a database server network interface that handles database client/server communication to and from the database server. 1 57. A system as claimed in any preceding claim wherein,

2 each node whose presence is critical to communication

3 within the network can have standby node(s) tha_t are in a

4 position to immediately replace that node so tlxat

5 communication (both for network and database) i_s not

6 compromised. 7

8 58. A system as claimed in any preceding claim wherein,

9 within the database every node with data critical to the .0 database network has a backup node(s) that synchronise

.1 this data so that it is not solely located in one place.

.2

.3 59. A computer program for causing a computer to become

.4 a node of a distributed database in accordance with

L5 claims 1 to 58.

16

L7 60. A distributed file sharing system comprising a

L8 distributed database in accordance with claims 1 to 58.

L9

20 61 . A so f tware validation tool comprising a distributed

21 database in accordance with claims 1 to 58 .

22

23 62 . A te lecommunications infrastructure comprising a

24 distributed database in accordance with claims 1 to 58 . 5 6 63 . An air traf f ic control and communication system 7 comprising a distributed database in accordance with 8 claims 1 to 58 . 9 0 64 . A military command and control network comprising a 1 distributed database in accordance with claims 1 to 58 . 2