INtime SDK Help
Distributed Systems Manager (DSM)
The Distributed System Manager (DSM) is a cooperative, multiple process application that manages a distributed INtime system. The DSM tracks the state of the system, monitors the health of its components, and cleans up in the event of component termination or failure.
Applications are normally decomposed (i.e. split) into individual blocks where each block handles specific aspects of the application.
These individual blocks then cooperate with each other by means of interprocess communication (IPC) using objects like semaphores, mailboxes, mutexes, regions, shared memory etc.
While the performance of one node may be sufficient for moderately complex applications making up a system, there are many applications that need to be distributed across several nodes and/or hosts. Considerations for decomposing an application are discussed in Distributed Applications.
INtime provides support for distributed systems by two layers:
Distributed System Management (DSM) – monitors "health" of all nodes and handles dependencies between processes on any node of the system
Global Objects (GOBS) Technology – split into GOBSmgr and GOBSnet.
GOBSmgr: facilitates access to objects on other nodes (then named global objects) by means of a reference objects.
GOBSnet: if the global object resides on a node in another host, GOBSmgr transparently uses GOBSnet to access it.
The default as seen in the INtime Explorer Node Selector shows:
With WinNTXProxy running on the local system the INtime Explorer Node Selector shows:
When WinNTXProxy is running, all non-local ntx connections are dropped.
Remote nodes will see this system as a INtime for Windows node running WinNTXProxy on the local network
with: "NTX Proxy: " before the system name.
Used for remote debugging when the SDK host is not the target INtime for Windows system.
The nodes seen in the local INtime Explorer Node Selector shows:
NTX will see local nodes twice
The default as seen in a remote INtime Explorer Node Selector shows:
NodeA loads GOBs Net by default
Works on all visible nodes
Processes can be loaded and created on both the Windows and the RT side and typically there will be a relation between such processes. The Distributed System Manager (DSM) allows a process to indicate its dependency and triggers notifications if a process in a dependency disappears.
The bulk of the DSM work i performed on the Windows host using NTX calls.
The DSM performs these tasks:
The DSM processes communicate with one another via these avenues:
Sponsor: A Windows or RT process that provides a service to other processes. A sponsor must have a unique name in the whole system. A sponsor may have more than one unique name.
Dependent: A windows or RT process that requires services from a sponsor. A dependent can also be a sponsor.
Notification: A function that sleeps until the selected notification or a timeout.
System Notification: Tracks Windows and RT nodes and processes. Includes Windows shutdown and blue screen.
The DSM consists of the Windows DSM, a process that executes on the Windows host, and the RT DSM, a process that executes on each RT client. The bulk of the DSM work is performed on the Windows host. The processes cooperate to ensure the integrity of a distributed INtime system.
A sponsor process is a (Windows or RT) process that provides some service to other processes.
A sponsor process registers itself by a unique name with RegisterRtSponser or ntxRegisterSponser.
More than one sponsor name can be registered for the same process.
By registering itself, a process indicates that it provides some service to dependents; typically, this means that it will use an RT communication object, whose handle should then be cataloged. Note that INtime does not know the relationship between the sponsor name and the RT communication object.
A dependent is a (Windows or RT) process that requires some service from a sponsor.
A dependent process waits for the sponsor process to register itself.
A process can depend on more than one sponsor.
A process that requires services from a sponsor indicates this need by registering as a dependent of that sponsor with RegisterRtDependency or ntxRegisterDependeny.
If the sponsor has not been registered yet, the calling thread is put in a sleep state until the sponsor registers itself or until a timeout occurs.
A process may both depend on a sponsor process and be a sponsor itself.
When a dependent process no longer requires the sponsor, it should unregister itself by calling UnregisterRtDependency or ntxUnregisterDependency.
A sponsor process is notified of the registering or unregistering of a dependent process.
A dependent process is notified of the unregistering of its sponsor process.
The notification mechanism can also be used for process deletion.
The notification function, RtNotifyEvent or ntxNotifyEvent, puts the calling thread in a sleep state until a notification of the type indicated by dwFlags occurs, or until the request times out.
dwFlags can be a combination of system events, sponsor and dependent notifications (see the help file for the exact constant names). The event info structure receives details on the event.
To avoid wasting RT threads that wait on different kinds of notifications, waiting on the deletion message and waiting for notifications can be combined. In this case the main thread does not execute the ReceiveRtData(deletion_mbx,…) but instead calls RtNotifyEvent or ntxNotifyEvent.
Tracks Windows and RT nodes and processes.
Notifies Windows and RT processes:
When a Windows or an RT node stops
When a Windows or an RT process stops
Cleans up RT resources owned by a Windows process
Includes Windows shutdown
Includes Windows blue screen
Permits dependent processes to take appropriate action
Every RT process catalogs a data mailbox, catalogs its handle with the name "R?EXIT_MBOX" in its own object directory and then waits for messages; all of this is done by RtNotifyEvent.
Use TerminateRtProcess or ntxTerminateRtProcess to terminate a process.
This sends a 4-byte message containing 0x000000FF
The TERMINATE message results in a TERMINATE notification event.
Terminating a process must be done very carefully; for example, if a process is deleted while a region is in use, deletion waits until the region is free.
To avoid any cleaning problems, INtime uses a model where the process itself does the deletion; to ask a process to delete itself, you must use one of the terminate functions, which sends it a termination message.
Windows system shutdown is handled as multiple invocations of the process shutdown model. During controlled Windows system shutdown, every window application receives a message telling it to shut down. The DSM also receives the message and communicates the shutdown to the RT DSM Components in the system. The RT Client may choose to continue running based on its configuration. Uncontrolled Windows system shutdown is handled by RT nodes. Likewise, if an RT node is identified as shutdown, the Windows node handles the situation. All processes with RT dependents or RT sponsors are notified and the database is purged of the references to objects on the down node.
The RT process and system shutdown model is a mirror image of the Windows side. The only exception is that system shutdown is done as a message to the Process Deletion Mailbox of each process.
This lists common operations related to distributed system management, and the RT kernel system calls that do the operations:
| To . . . | Use this system call . . . |
|---|---|
| Register a dependency | ntxRegisterDependency RegisterRtDependency |
| Unregister a dependency | ntxUnregisterDependency UnregisterRtDependency |
| Register a sponsor | ntxRegisterSponsor RegisterRtSponsor |
| Unregister a sponsor | ntxUnregisterSponsor UnregisterRtSponsor |
| Find the location of a sponsor | ntxFindSponsor FindRtSponsor |
| Notify of an event | ntxNotifyEvent RtNotifyEvent |
| Register a DSM event handler | RegisterRtEventHandler |
| Unregister a DSM event handler | UnregisterRtEventHandler |
| Change event handler priority | SetRtEventHandlerPriority |
| Manage Windows shut down | RtContinueWindowsShutdown RtShutdownBlockReasonCreate RtShutdownBlockReasonDestroy |
This shows the order to make DSM calls:
