ScimoreDB uses a abstract message-based network communications architecture. The default server comes with a TCP backend. More can be implemented in future if required, such as named pipes, UDP or any other protocol capable of supporting fast message communications. 

Although TCP is the currently the default connection protocol, communications always travel as paged messages with a maximum of 8 kB. This is to ensure that no one server-client or server-server connection will starve other connections of bandwidth by sending large continuous streams of data. This kind of architecture is absolutely necessary for ScimoreDB to maintain it's high thoughput capability. 

Client Connections 

When a client connects, the nodes will communicate in the binary tree structure. Upon initial connection, if an instance is not specified, it will pick a random instance to connect to. 

If the client uses concurrent connections, subsequent connections will be made to subsequent instances. The binary tree will then be in a different order. 

This policy provides a pseudo-load-balanced behaviour. In high-load environments, the random instance connections followed by subsequent concurrent connections distribute the load amongst server instances effectively. 

Server Instances Checking 

A cluster of servers will ensure that they are connected to each other by sending keep alive signals around in a loop. 

If one instance goes down, all of the other instances will learn about it as the message gets passed. Then no new connections will be accepted. Queries on current connections that don't need the server instances will run. Queries that do need to use the inactive instances will receive a network error. 

Related 

• ScimoreDB Architecture