© 2006 The MITRE Corporation. All rights reserved A Status Report 11 October 2006 4th International...
-
date post
18-Dec-2015 -
Category
Documents
-
view
213 -
download
0
Transcript of © 2006 The MITRE Corporation. All rights reserved A Status Report 11 October 2006 4th International...
© 2006 The MITRE Corporation. All rights reserved
A Status Report
11 October 2006
4th International Workshop on Java Technologies for Real-time and Embedded Systems (JTRES 2006)
JSR-50: The Distributed Real-Time
Specification for Java
Jonathan S. [email protected]
Lead EngineerThe MITRE Corporation
JSR-50 Implementation Lead
Dr. E. Douglas [email protected]
Consulting ScientistThe MITRE Corporation
JSR-50 Expert Group Lead
Slides available at http://andersoj.org/jtres06
2
© 2006 The MITRE Corporation. All rights reservedRevised 11 October 2006
Agenda
Key Principles from the DRTSJ Expert Group (JSR-50) Elements of the evolving DRTSJ
• Distributable Threads Programming Model
• Distributable Thread Integrity
• RTSJ Relationships DRTSJ Reference Implementation Schedule and Future Work
3
© 2006 The MITRE Corporation. All rights reservedRevised 11 October 2006
Key Principles of the DRTSJ EG
Bring distributed real-time to Java, not bring Java to traditional distributed real-time
Provide support for end-to-end application properties Distributed objects and operations are distinguished
from local objects and operations, for the obvious reasons of latency, partial failures, and concurrency control
Address current real-time system practice, as well as allow future implementations to include advanced features
RTSJ applications should run unmodified on DRTSJ-compliant JVMs, with some caveats on their distributed behavior
Do not dictate the use of an RTSJVM or real-time transport
• Spec should not limit interoperability across RT and non-RT platforms
4
© 2006 The MITRE Corporation. All rights reservedRevised 11 October 2006
Key Principles:Bring distributed real-time to Java
It is the intention of the JSR-50 Expert Group to bring facilities required for constructing the DRTSJ style of distributed real-time systems into the Java programming environment in a way that is least disruptive to experienced Java programmers
Build upon (not replace) Java's distributed object model as expressed in the Java RMI specification (as proposed in JSR-50)
• New wire protocol(s) are likely required Therefore, DRTSJ is specifically for Java, and is not
intended to be language agnostic (as, for example, CORBA is more or less intended)
5
© 2006 The MITRE Corporation. All rights reservedRevised 11 October 2006
Key Principles:(Don’t) Bring Java to distributed real-time
The opposite approach of bringing Java to distributed real-time could conceivably be performed with a binding of the RTSJ to Real-Time CORBA
• but that would require Java programmers to learn about how to use CORBA
Each approach is reasonable for some contexts• our choice for the DRTSJ is not intended to compete with
that alternative (should it eventually materialize)
• but instead to complement it and provide the users two options
Nothing constrains a vendor from implementing the DRTSJ with IIOP or even full RT-CORBA underneath
• In principle, DRTSJ threads can map to RT-CORBA 1.2 threads
6
© 2006 The MITRE Corporation. All rights reservedRevised 11 October 2006
Key Principles:Support end-to-end application properties
Properties such as timeliness and fault management Raison d'être of distributed real-time systems By definition, some multi-node behaviors in distributed
real-time systems have end-to-end time constraints which must be respected
Other end-to-end properties may also be required, such as fault management, security credentials, serialization, etc.
Traditionally ensuring these end-to-end properties has been forced on the application designers
• who must create ad-hoc (and error-prone) mechanisms to attain them
• typically without proper experience or education
• and at high recurring and non-recurring costs Maintaining end-to-end properties requires providing
and using appropriate end-to-end context
7
© 2006 The MITRE Corporation. All rights reservedRevised 11 October 2006
Key Principles:Support end-to-end application properties
Existing Java distribution models (e.g., JMS, JXTA) do not provide appropriate end-to-end context…
… and thus force any end-to-end timeliness and integrity to be a higher level – usually application programmers’ – responsibility, at greater recurring costs
DRTSJ must provide basic mechanisms for passing and acting upon the required end-to-end context among the nodes participating in any given distributed behavior, respecting the desired end-to-end properties
8
© 2006 The MITRE Corporation. All rights reservedRevised 11 October 2006
Key Principles: Address current real-time system practice while allowing advanced features
DRTSJ will provide a specification which targets those technologies, techniques, and interfaces that have been well-tested, subjected to review, and successfully employed in the construction of non-trivial distributed real-time systems
Additional promising technologies under development by the research community which fail to meet those specification criteria may be provided in versions of the DRTSJ Reference Implementation (RI)
Such versions of the RI serve as an active testing ground for innovative technologies which may appear in future versions of the specification
9
© 2006 The MITRE Corporation. All rights reservedRevised 11 October 2006
Key Principles:Not dictate use of RTSJVM or real-time transport
Some practitioners who misinterpret “real-time” as being only the special case of “hard real-time” consequently misinterpret “distributed real-time” systems as requiring deterministic (synchronous) networks
The DRTSJ allows the inevitable mixtures of regular and RTSJ-compliant JVMs, and specifies the timeliness behaviors that result
Deliberately silent on the topic of the transport, which is regarded as a quality of implementation issue
As with Real-Time CORBA, pluggable, real-time, and application-specific transports may be addressed in a subsequent specification
10
© 2006 The MITRE Corporation. All rights reservedRevised 11 October 2006
Key Principles led to minimum required components for final DRTSJ specification
A distributable threads programming model A distributable thread integrity framework A scheduling framework
11
© 2006 The MITRE Corporation. All rights reservedRevised 11 October 2006
Distributable threads programming model
Many distributed system applications (or portions of applications) are most naturally structured as
• a multiplicity of sequential (i.e., linear) flows of execution and data
• within and among known objects (i.e., that do not need discovery)
• asynchronously and concurrently A distributable thread is a single logically distinct (i.e.,
having a globally unique identifier) locus of control flow movement that extends and retracts through local and (potentially) remote objects
The presence of a distributed object model (RMI) in the Java platform makes the distributable thread concept a straightforward step for Java programmers into the world of distributed real-time programming
12
© 2006 The MITRE Corporation. All rights reservedRevised 11 October 2006
A distributable thread extends and retracts among objects and (potentially) nodes
Object A Object B Object C Object D
dthread 1 dthread 2 dthread 3
Returns have not yet occurred
13
© 2006 The MITRE Corporation. All rights reservedRevised 11 October 2006
Example Application:battle management sensor-to-shooter chain
PlotCorrelatorSensors
TrackHdlr
TrackDB
IDData
ThreatAssessor
TrackID
StoresMgr
WeaponCtlrs
ThreatData
14
© 2006 The MITRE Corporation. All rights reservedRevised 11 October 2006
Distributable thread model: causal sequential control/data flow among known objects
Model imposes no constraints on the presence, size, or structure of the data that may be propagated as part of the thread's flow
Commonly, input parameters may be propagated with thread invocations, and results may be propagated back with returns
When the principal purpose for a thread is movement of associated data, the model can be viewed as a data flow one as much as, or more than, a control flow one
Each invoked object's ID is known by the invoking object (i.e., the invoked object does not have to be discovered)
There are end-to-end properties that must be maintained, including timeliness, fault management, and control (e.g., concurrency, pause/resume, signaling of state changes)
15
© 2006 The MITRE Corporation. All rights reservedRevised 11 October 2006
Distributable thread propagates context for end-to-end scheduling on the nodes transited
A distributable thread carries its execution context as it transits (object and) node boundaries, including its scheduling parameters (e.g., time constraints, execution time), identity, and security credentials
The propagated thread context is intended to be used by node schedulers for resolving all node-local resource contention among threads such as that for node's
• physical (e.g., CPU, I/O, memory, disk)
• and logical (e.g., locks)
resources, according to a discipline that provides acceptably
optimal and predictable system-wide timeliness
16
© 2006 The MITRE Corporation. All rights reservedRevised 11 October 2006
A distributed thread’s multi-node behavior may have end-to-end time constraints
Object A Object B Object C
end-to-end time constraint
time constraint
scope
BEGIN
END
current head of the thread
root of the thread
17
© 2006 The MITRE Corporation. All rights reservedRevised 11 October 2006
Time constraints are lexically scoped attributes of a schedulable entity (e.g., thread) activity
code
BeginTimeConstraint (t)
EndTimeConstraint
thread
tc scope
thread is “non-real-time”
thread is “non-real-time”
thread is “real-time” system callscheduling event
18
© 2006 The MITRE Corporation. All rights reservedRevised 11 October 2006
Remote invocation propagates a time constraint to (and enforces it on) remote nodes
code
BeginTimeConstraint (t)
EndTimeConstraint
thread
tc scope thread is “real-time”invokereturn
19
© 2006 The MITRE Corporation. All rights reservedRevised 11 October 2006
Distributed systems are subject to partial failures
Non-trivial dynamic distributed systems should be presumed to always be partially failed
Provisions must be made to ensure the end-to-end integrity of distributable threads at a level appropriate for the application
Perhaps more importantly for the construction of large, complex distributed real-time systems, the integrity abstraction must be one that programmers and designers can reason about
The DRTSJ reference implementation provides • example implementations of prior art integrity (e.g.,
orphan detection and elimination) policies
• APIs allowing applications to provide their own integrity policies
• example implementations of new research focused on thread integrity in mobile, ad-hoc networks
20
© 2006 The MITRE Corporation. All rights reservedRevised 11 October 2006
DRTSJ’s threads model is deliberately intended to be similar to that of Real-Time CORBA 1.2
The Real-Time CORBA 1.0 (“fixed priority scheduling”) specification used the activity abstraction as an analysis/design concept for end-to-end predictability of timeliness, but it left the details of the abstraction undefined
The Real-Time CORBA 1.2 (“dynamic scheduling”) specification defines a distributable threads model as the schedulable entity to provide for end-to-end timeliness
Many of the prospective users of either the DRTSJ or Real-Time CORBA 1.2 compliant products express the desire
• to use the other also
• for them to be tightly interoperable at the application programmer level
21
© 2006 The MITRE Corporation. All rights reservedRevised 11 October 2006
DRTSJ will extend Real-Time CORBA 1.2 constructs with thread integrity and scheduling
Real-Time CORBA 1.2 specification silent on thread integrity
• hadn’t become well enough understood yet
• it was left as an ORB vendor added value or an application-specific solution
The DRTSJ will include APIs allowing applications (or vendors) to provide their own integrity policies
Real-Time CORBA 1.2 specification • IDL for schedulers and scheduling segments
• Does not specify delivery of scheduling events to policies DRTSJ will include a scheduling framework
• Schedule arbitrary javax.realtime.Scheduleables
• Will be submitted to RTSJ EG for consideration
• Extensions to support distributable thread scheduling
• Support advanced application-specific policies
22
© 2006 The MITRE Corporation. All rights reservedRevised 11 October 2006
Distributable Thread Integrity:Distributable Thread Primer
Thread is instantiated at its root (“root node”)
Thread may transit any node in the network, so that its call-graph is dynamic and difficult to measure
Goal of enforcing the predicate that only a single, unique point of control (in the application’s view) is active at any instant
The “distributable thread” is realized by a collection of local threads, called “segments”
Root
Head
Segment
Dow
nstr
eam
23
© 2006 The MITRE Corporation. All rights reservedRevised 11 October 2006
Distributable Thread IntegrityThread Polling & TPR
Phase I: Each thread’s root node broadcasts a “poll” message to all nodes
Phase II: Every node hosting a segment of the thread responds (“Ack”) with information about their segment and knowledge about the location of the head. The root assembles a tentative measure of the call graph.
Phase III: If a persistent “break” or missing head is discovered, the thread is paused, cleanup commences on nodes downstream of the break, and control is returned to a new head.
Root
Head
Segment
Dow
nstr
eam
X
24
© 2006 The MITRE Corporation. All rights reservedRevised 11 October 2006
Distributable Thread IntegrityThread Polling & TPR
Phase I: Each thread’s root node broadcasts a “poll” message to all nodes
Phase II: Every node hosting a segment of the thread responds (“Ack”) with information about their segment and knowledge about the location of the head. The root assembles a tentative measure of the call graph.
Phase III: If a persistent “break” or missing head is discovered, the thread is paused, cleanup commences on nodes downstream of the break, and control is returned to a new head.
Root
Head
Segment
Dow
nstr
eam
X
25
© 2006 The MITRE Corporation. All rights reservedRevised 11 October 2006
Distributable Thread IntegrityThread Polling & TPR
Phase I: Each thread’s root node broadcasts a “poll” message to all nodes
Phase II: Every node hosting a segment of the thread responds (“Ack”) with information about their segment and knowledge about the location of the head. The root assembles a tentative measure of the call graph.
Phase III: If a persistent “break” or missing head is discovered, the thread is paused, cleanup commences on nodes downstream of the break, and control is returned to a new head.
Root
Head
Segment
Dow
nstr
eam
Phase I: Poll
X
26
© 2006 The MITRE Corporation. All rights reservedRevised 11 October 2006
Distributable Thread IntegrityThread Polling & TPR
Phase I: Each thread’s root node broadcasts a “poll” message to all nodes
Phase II: Every node hosting a segment of the thread responds (“Ack”) with information about their segment and knowledge about the location of the head. The root assembles a tentative measure of the call graph.
Phase III: If a persistent “break” or missing head is discovered, the thread is paused, cleanup commences on nodes downstream of the break, and control is returned to a new head.
Root
Head
Segment
Dow
nstr
eam
Phase 2: Ack
OrphanX
27
© 2006 The MITRE Corporation. All rights reservedRevised 11 October 2006
Distributable Thread IntegrityThread Polling & TPR
Phase I: Each thread’s root node broadcasts a “poll” message to all nodes
Phase II: Every node hosting a segment of the thread responds (“Ack”) with information about their segment and knowledge about the location of the head. The root assembles a tentative measure of the call graph.
Phase III: If a persistent “break” or missing head is discovered, the thread is paused, cleanup commences on nodes downstream of the break, and control is returned to a new head.
Root
Head
Segment
Dow
nstr
eam
Phase 3: Refresh
New Head
Orphan
OrphanX
28
© 2006 The MITRE Corporation. All rights reservedRevised 11 October 2006
Distributable Thread IntegrityThread Polling & TPR Root
New HeadException Delivered
OrphanExceptions Delivered
X
Phase I: Each thread’s root node broadcasts a “poll” message to all nodes
Phase II: Every node hosting a segment of the thread responds (“Ack”) with information about their segment and knowledge about the location of the head. The root assembles a tentative measure of the call graph.
Phase III: If a persistent “break” or missing head is discovered, the thread is paused, cleanup commences on nodes downstream of the break, and control is returned to a new head.
29
© 2006 The MITRE Corporation. All rights reservedRevised 11 October 2006
Distributed thread model works with various JVMs and transport infrastructures
A distributed thread is capable of traversing nodes with standard, RTSJ, and DRTSJ virtual machines, yielding the best available timeliness behavior on each
The distributed thread abstraction appears like the RMI programming model, but has been decoupled from RMI to the extent possible
Implementers are able to implement distributed threads with any transport infrastructures (RMI, SOAP, Real-Time CORBA, etc.) that provides an interface comparable to that of RMI's RPC-style programming model
30
© 2006 The MITRE Corporation. All rights reservedRevised 11 October 2006
Optional Metascheduler allows arbitrary user-defined scheduling disciplines
Providing control for distributable threads in the presence of partial failures requires cooperation with processor schedulers on every node
Processor scheduling disciplines often need to be application-specific
The DRTSJ implementation team has implemented a set of low-level scheduling primitives called the Metascheduler
• facilitates the construction of arbitrary thread scheduling disciplines
• supports distributable thread integrity policies A variety of scheduling disciplines have been
implemented, ranging from traditional (e.g., fixed priority, EDF), to Time-Utility Function/Utility Accrual ones
The Metascheduler is most effective with JVM support for it, but functions in a degraded mode on any RTSJ-compliant JVM
31
© 2006 The MITRE Corporation. All rights reservedRevised 11 October 2006
Distributed RTSJ memory areas out of scope for JSR-50
The DRTSJ currently does not intend to address how distributable threads interact with remote memory areas, instead leaving that up to the implementers
Providing control over remote memory – e.g., a distributed way to name a scoped area from off the node – is difficult to make sense of semantically
The DRTSJ is currently silent about how distributable threads interact with memory management – the RTSJ community continues to explore best practices for RTSJ scoped memory,
When sufficient consensus emerges, we anticipate addressing memory areas from a distributed system standpoint
32
© 2006 The MITRE Corporation. All rights reservedRevised 11 October 2006
Asynchronous events in the DRTSJ
We are investigating the correct approach to DistributedAsyncEvents, but have made no commitment yet about their appearance in the DRTSJ or reference implementation
We are using AsyncEvents locally in the Metascheduler implementation of a scheduling framework for user space scheduling disciplines
We intend to allow the Metascheduler to facilitate user-defined scheduling policies capable of dealing with AsyncEventHandlers
33
© 2006 The MITRE Corporation. All rights reservedRevised 11 October 2006
DRTSJ development resumed after a pause
Work on the DRTSJ took place for about a year, and then gradually slowed and essentially paused for almost three years; it has recently resumed
Work paused due to…
• no COTS RTSJ products – consequently little pull from prospective DRTSJ users, and hence the work was low priority for the contributors
• problems getting Sun to grant a source license to the RTSJ RI
Work resumed for the following reasons…• several COTS RTSJ products became available
• Sun (and TimeSys) finally granted the source licenses
• but meanwhile Apogee agreed to incorporate the DRTSJ-specific changes into their RTSJ-compliant Aphelion Java runtime environment product
Reference Implementation incrementally developed and used driven by our own research needs
34
© 2006 The MITRE Corporation. All rights reservedRevised 11 October 2006
The DRTSJ software suite will have four parts
DRTSJ software suite, beginning with Early Draft Release 1, will consist of
• a set of DRTSJ class libraries (implementing a distributable-thread-aware RMI stack)
• an optional COTS binary DRTSJ-compatible JVM product from Apogee, who is implementing it collaboratively with us (the first such product, anticipating a corresponding update to the RTSJ)
• a set of external dependencies, including the Apache build environment and a Debian Linux system with Linux Kernel 2.6, patched with the most recent real-time extensions
• an optional demonstration application
35
© 2006 The MITRE Corporation. All rights reservedRevised 11 October 2006
DRTSJ applications do not require a DRTSJ-compliant RTSJVM
DRTSJ applications may comprise mixtures of standard JVMs, RTSJ-compliant JVMs, and DRTSJ-compliant JVMs
Distributable threads abstraction will run atop a regular JVM using java.lang.Thread sections, and the programmer may specify if transitions should be made to DistributableThread sections upon arrival in DRTSJ-compliant JVMs
Distributable threads have (dynamic) policy controlling allowable invocations
• Allow invocations on non-DRTSJ remote objects?
• Allow invocations from DRTSJ to RTSJ JVM?
• Allow invocations from DRTSJ to standard JVM? Some facilities unavailable on less compliant VMs, e.g.
• Distributable RealtimeThreads
• Advanced thread scheduling policies
36
© 2006 The MITRE Corporation. All rights reservedRevised 11 October 2006
The DRTSJ reference implementation and TCKwill be delivered in two forms
First, traditional tarball/jarfiles appropriate for cross-platform evaluation and use by JCP members
Second, because of the complexity and inherent dependencies, a parallel set of packages is being maintained to streamline the “getting started”' process on Debian Linux
A Debian package repository containing the DRTSJ core libraries, with references to all required dependencies will be provided, and constructing a test system will be as easy as “apt-get install drtsj-package”
37
© 2006 The MITRE Corporation. All rights reservedRevised 11 October 2006
DRTSJ Demonstration Application
Virginia Tech has written a demonstration application to help prospective users better understand the DRTSJ
The demonstration application also is providing essential feedback to the team designing and implementing the DRTSJ and RI
That work was performed in an ONR-funded Advanced Wireless Integrated Navy Network (AWINN) project at VA Tech
Both the AWINN project and the MITRE DRTSJ focus are on dynamic (e.g., mobile, ad hoc wireless) networks with end-to-end time constraints
38
© 2006 The MITRE Corporation. All rights reservedRevised 11 October 2006
Coastal Air Defense DemonstrationMotivating Scenario
1 Detect
2 Identify
3 Track and Engage4 Shoot
Coastline/boundary to protect
Challenge: How to detect and respond to partial (communications) failure in the midst of a sequential activity execution?
Approach: Implement mission in terms of distributable threads with thread integrity protocols
39
© 2006 The MITRE Corporation. All rights reservedRevised 11 October 2006
Scenario Communication Network
Coastal Air Defense DemonstrationScenario Deployment Diagram
ScenarioGenerator
andGUI
SensorTrackingService
C2Node
CannonInterceptor
DRTSJ Middleware / Apogee RTJVM
Detections, Commands
RadarPulse, Detection,Lock/Unlock Sensor
Lock/Unlock Interceptor
Distributed Application
Detection Events
Detections, Tracks,
Predictions
Weapon-toTargetPairing
RMI RMI RMI RMI
LaunchInterceptor
40
© 2006 The MITRE Corporation. All rights reservedRevised 11 October 2006
DRTSJ Present and Future
Early Draft Review #1 Delivery November 2006• Specification: Distributable Threads API
• Reference Implementation: DT API, DT Integrity policies and scheduling framework
Successful Demonstration Application Staffing challenges: Primary contributors are students
and engineers with other priorities Contributor focus on specifying and implementing
aspects of interest to our US DoD and academic sponsors
“Future draft releases and final submission depend on the quality and quantity of … implementation participation from the broader community”
Responses to the expert group regarding this presentation and accompanying paper are solicited!
© 2006 The MITRE Corporation. All rights reserved
A Status Report
11 October 2006
4th International Workshop on Java Technologies for Real-time and Embedded Systems (JTRES 2006)
JSR-50: The Distributed Real-Time
Specification for Java
Jonathan S. [email protected]
Lead EngineerThe MITRE Corporation
JSR-50 Implementation Lead
Dr. E. Douglas [email protected]
Consulting ScientistThe MITRE Corporation
JSR-50 Expert Group Lead
Slides available at http://andersoj.org/jtres06
© 2006 The MITRE Corporation. All rights reserved
BACKUPS
43
© 2006 The MITRE Corporation. All rights reservedRevised 11 October 2006
Excerpts from the JSR-50 proposal
The proposed JSR is for a distributed extension to the Real-Time Specification for Java.
One possible focus of the proposed Distributed Real-Time Specification for Java could be real-time RMI.
In this JSR (at least) “real-time RMI” … means that RMIs and returns preserve the timeliness semantics of the control flow in which they are performed.
Execution of the control flow is governed by its current execution scheduling parameters (in the context of the system's scheduling optimization criterion),
• regardless of the control flow's execution point transiting nodes
• (and taking into account scheduling parameters associated with the occurrence of relevant events, control flow control actions, and failure handling).
“
”
44
© 2006 The MITRE Corporation. All rights reservedRevised 11 October 2006
The DRTSJ adds real-time to Java RMI
Java RMI supports moving thread contexts across nodes “RT-RMI” has stricter semantics
where the RMI specification is silent• end-to-end time constraints and integrity
• more types of RemoteExceptions RT-RMI is wire-protocol compatible with Sun’s JDK1.4
RMI implementation,
while providing an extended wire protocol for invocations between DRTSJ-compliant JVMs
Additionally, a UDP-based RT-RMI implementation with application-level reliability mechanisms is provided to demonstrate and test DRTSJ applications in dynamic (e.g., mobile ad-hoc) networks, where TCP is unsuitable
RT-RMI is called the distributable threads model
45
© 2006 The MITRE Corporation. All rights reservedRevised 11 October 2006
The DRTSJ seeks to bring distributed real-time to Java
Not bring Java to distributed real-time
• a binding of the RTSJ to Real-Time CORBA might be one way to bring Java to distributed real-time, but requires CORBA knowledge in addition to Java programming
Distributed (i.e., multi-node) real-time activities require• satisfying end-to-end time constraints (such as deadlines)
• maintaining end-to-end integrity of the activity (and consistency of the system) despite node and network failures
• and thus providing and using appropriate end-to-end context Other Java distribution models (e.g., JMS, JXTA) do not
provide appropriate end-to-end context,
and thus force any end-to-end timeliness and integrity to be a higher level – usually application programmers’ – responsibility, at greater recurring costs
46
© 2006 The MITRE Corporation. All rights reservedRevised 11 October 2006
The DRTSJ adds real-time to Java RMI
Java RMI supports moving thread contexts across nodes “RT-RMI” has stricter semantics
where the RMI specification is silent• end-to-end time constraints and integrity
• more types of RemoteExceptions RT-RMI is wire-protocol compatible with Sun’s JDK1.4
RMI implementation,
while providing an extended wire protocol for invocations between DRTSJ-compliant JVMs
Additionally, a UDP-based RT-RMI implementation with application-level reliability mechanisms is provided to demonstrate and test DRTSJ applications in dynamic (e.g., mobile ad-hoc) networks, where TCP is unsuitable
RT-RMI is called the distributable threads model
47
© 2006 The MITRE Corporation. All rights reservedRevised 11 October 2006
A distributed thread is sequential rather than synchronous (“send/wait”)
The send/wait synchrony of a conventional method invocation (or RPC) is often cited as a concurrency limitation
But a distributed thread is a sequential entity like a local thread
A distributed thread is always executing somewhere, while it is the most eligible there – it is not doing send/wait’s as with conventional method invocations (or RPC’s)
Remote invocations and returns are scheduling events at both source and destination nodes
• each node’s processor is always executing the most eligible distributed thread there
• the other distributed threads there wait as they should Local method invocations/returns benefit from not requiring
context switches like threads normally do
48
© 2006 The MITRE Corporation. All rights reservedRevised 11 October 2006
Coastal Air Defense Demonstration
Single-node coastal defense example
Prosecuting missile threat is an inherently sequential mission:
1) Detect
2) Identify
3) Track/Engage
4) Shoot
… for which distributable threads are an ideal technical solution
Sensor Range
Weapons Range(beyond line of sight)
Incoming Threats
Coastline/boundary to protect
Fighter/InterceptorLaunched by our Ship
49
© 2006 The MITRE Corporation. All rights reservedRevised 11 October 2006
Coastal Air Defense Demonstration Scenario Activity Diagram (MANET)
NavyShip2 NavyShip3 NavyShip4 NavyShip5
newDetection()
getSensorLock()
launchInterceptor()
updateSensorLock() (periodically)newDetection()
getSensorLock()
launchInterceptor()
interceptorReturned()
Return from launchInterceptor()
Tim
e
(example target prosecution)
50
© 2006 The MITRE Corporation. All rights reservedRevised 11 October 2006
Coastline to Defend
Enemy Track(with status and velocity vector)
InterceptPoint
FriendlyShip
FriendlyInterceptor
SensorRange
Accrued Utility
Comm LinkStatus
Integrity Policy and
Comm Settings
ScenarioGen Tactical Display (Example)