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.

 

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 Zero

 

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;