Terminology

<< Click to Display Table of Contents >>

Navigation:  Developer's Guide > uniGUI HyperServer >

Terminology

There are several new terms which are introduced with HyperServer. Before going any further it is good to become familiar with them:

 

HyperServer

 

HyperServer is main entry point for all requests. It will filter requests and direct them to corresponsing Node. If request is not associated with a Node then HyperServer will direct it to an arbitrary Node based on a load distribution algorithm. HyperServer is also responsible for creating new Nodes and recycling them when needed.

 

Needless to say that HyperServer itself is a uniGUI application which is designed for this specific purpose. HyperServer is deployed in form of pre-compiled binary files (Exe and Dll). Available deployment options are: Standalone Server, ISAPI Module and Windows Service. In future HyperServer components will be included in uniGUI library, so developers will be able to create their own custom HyperServers.

 

Node

 

A HyperServer Node is actually a worker process. At the same time it is the uniGUI application itself which is deployed in standalone EXE mode. Developers will deploy their applications in form of a Node. Developers do not need to take any special action when designing a Node application. They can develop and test their applications as they're developing any standard uniGUI application.

 

ServerNode

 

A ServerNode is a slave HyperServer instance which is part of a HyperServer Server Farm. A ServerNode is usually a computer or a VM which runs a HyperServer instance. ServerNodes can also be separate instances of HyperServer running in same PC. A ServerNode exists only in a Server Farm configuration.

 

Node Id

 

Each Node has a unique Node Id. A Node Id is assigned at the time the Node is created. Node Ids will be re-used when Nodes are recycled.

 

Transport

 

HyperServer uses Transport channels to internally communicate with Nodes. Currently only HTTP Transport channel is implemented. In future various other Transport channels will be implemented based on various technologies such as Wiidows Pipes,  TCP and UDP.

 

Node Recycling

 

Nodes will be recycled based on a predetermined scenario. When a Node should be recycled, the associated process will be requested to terminate itself. After this request is acknowledged, Node will start to terminate all of its session and finally terminating its process. If a Node doesn't acknowledge a recycle request then it will be forcefully terminated by the HyperServer.

 

Active Node

 

Active Nodes are those Nodes which are actively serving sessions. They are able to accept new sessions.

 

Suspended Node

 

A suspended Node is a Node which has failed to communicate with HyperServer. Under normal operations HyperServer polls all of its Nodes at certain intervals. If one of the Nodes fails to respond then it will be marked as suspended. If a Node fails to respond after a certain amount of retry then it will be considered as a failed Node and it will be purged.

 

Purged Node

 

A Purged Node is a Node which is removed from active Nodes list and sent to recycle queue. A Purged Node neither will accept new sessions nor will process any incoming request. It will be removed from process space next time recycle queue is cleaned.

 

Discarded Node

 

A Discarded Node is a Node which actually owns a number of sessions, but it won't accept new sessions. It will continue to exist until all of its sessions are terminated. At the time when there are no more remaining sessions it will be purged.

 

Persistent Node (version 1.95 and later)

 

Starting with version 1.95 uniGUI introduced a new HyperServer feature named Persistent Node which replaces Persistent Node Zero which was introduced in previous versions of HyperServer. As you can see word Zero is no longer included in the name of this property because a persistent node not always requires to own an id equal to zero. i.e. you can have persistent nodes with different id values. Main reason for this change is that now you can assign persistent Nodes to HyperServer Applications as well. In previous versions only HyperServer default application could own persistent Nodes, but now each application can own its persistent Node. Which means a HyperServer instance can host multiple persistent Nodes which belongs to different applications.

 

So what is a Persistent Node and why we need one?

 

Persistent Node is a Node which is guaranteed to run continuously, i.e. it will never be permanently unloaded. However, it will be occasionally recycled like any other Node. Again, it is guaranteed that it will be reloaded immediately after it is recycled. Main purpose of a Persistent Node is to make sure that you have at least one Node running at any time. Consider a scenario where your uniGUI application should perform some background tasks in a dedicated thread, possibly in a TUniThreadTimer placed on ServerModule.

 

In a classical uniGUI app there is only one process, so your background task is guaranteed to run in form of a Singleton. However, in HyperServer  where multiple copies of same process are running concurrently, there should be a mechanism to ensure that your Singleton method will run only in one of the Nodes. Persistent Node option perfectly serves this purpose. All you need to do is enabled this option and checking the PersistentNode property in your uniGUI application. If boolean property in ServerModule named PersistentNode is True, then it is safe to run your background task.

 

In below code ThreadTimer event is executed only if current Node is a Persistent Node.

 

procedure TUniServerModule.UniThreadTimer1Timer(Sender: TObject);
begin
  if PersistentNode then // run task if I'm a Persistent Node 
  begin
 
    // Your task here
 
  end;
end;

 

Please note that property PersistentNode will also return True when your application is not a Node and is not a part of a HyperServer cluster. It helps you to use above code without any modification regardless of the deployment mode.

 

Another major improvement here is that in previous versions of HyperServer Persistent Node could only be enabled for the default application of HyperServer:

 

[hyper_server]
binary_name=dbdemo.exe

persistent_node=1 

 

Starting with version 1.95 now you can enable persistent nodes for HyperServer Applications too.

 

[application-0]
enabled=1
alias=fishfacts
binary_name=fishfacts.exe
persistent_node=1
max_nodes=4

 

This means that you can run certain background tasks not only in your default application but also in any of the applications that requires running such tasks. This also means that a HyperServer instance can run multiple Persistent Nodes. One for HyperServer default application and others for HyperServer Applications.

 

Important note: In order to make sure that only ONE Persistent Node will run for any application in your HyperServer cluster, you must make sure that persistent_node parameter is only configured for ONE of the HyperServer instances. i.e. if your cluster consists multiple HyperServer instances only one of the instances should be configured to own a Persistent Node. Otherwise multiple HyperServer instances may run multiple Persistent Nodes simultaneously which is not a desired situation.

 

clip0333

 

 

Starting from version 1.95 Persistent Nodes will be shown in bold in HyperServer monitor screen. So you distinguish them from other Nodes. In above picture there are three Persistent Nodes. One of then belongs to HyperServer default application and other two belong to additional applications configured for this HyperServer instance.

 

Persistent Node Zero (deprecated, please see Persistent Node section above)

 

Persistent Node Zero is a Node with Id = zero (0) and it is guaranteed to run continuously, i.e. it will never be permanently unloaded. However, it will be occasionally recycled like any other Node. Again, it is guaranteed that it will be reloaded immediately after it is recycled. Main purpose of a Persistent Node is to make sure that you have at least one Node running at a time. Consider a scenario where your uniGUI application should perform a background task in a thread, possibly in a TUniThreadTimer placed on a ServerModule. In a classical uniGUI app there is only one process, so your background task is guaranteed to run in form of a Singleton. However, in HyperServer  where multiple copies of same process are running concurrently, there should be a mechanism to ensure your Singleton method will run only in one of the Nodes. Persistent Node Zero option perfectly serves this purpose. All you need to do is enabled this option and checking Node Id in your uniGUI application. If boolean property in ServerModule named NodeZero is True, then it is safe to run your background task.

 

In below code ThreadTimer event is executed only if current Node is Node Zero ( Node Id = 0 ).

 

procedure TUniServerModule.UniThreadTimer1Timer(Sender: TObject);
begin
  if NodeZero then // run code if I'm Node #0 
  begin
 
    // Your task here
 
  end;
end;

 

Or you can use below syntax if you plan to deploy your app both with HyperServer or in classical single process mode.

 

procedure TUniServerModule.UniThreadTimer1Timer(Sender: TObject);
begin
  if NodeZero or (not NodeMode) then // run code either if I'm Node #0 or I'm not a Node!
  begin
 
    // Your task here
 
  end;
end;