Download Distributed Real-Time in the RTSJ

Distributed RealTime in the RTSJ
Andrew Borg
Presentation

RMI – A brief introduction

The RTSJ – A (very) brief introduction

The DRTSJ – The 3 Levels of Integration

RMI+RTSJ: Concerns, Issues and Solutions
Presentation

RMI – A brief introduction

The RTSJ – A brief introduction

The DRTSJ – Current Status

RMI+RTSJ: Concerns, Issues and Solutions
The RMI Specification
RMI is very minimal.
 Assumes a homogeneous environment of
JVMs.


There is no ORB concept (see later)
Goals







Support seamless remote invocation on objects.
Retain most of the Java language's object
semantics.
Make differences between the distributed object
model and local Java object model apparent.
Make writing reliable distributed applications as
simple as possible.
Preserve the type-safety provided by the Java
runtime environment.
Various reference semantics for remote objects; for
example live (nonpersistent) references, persistent
references, and lazy activation.
Enforce the safe Java environment provided by
security managers and class loaders.
A simple HelloPerson example

Client sends name to a server.

Server returns “hello ” +the name passed
The interface
public interface HelloPersonInterface
extends java.rmi.Remote
{
public void sayHello() throws
java.rmi.RemoteException;
}
The Implementation
public class HelloPerson implements HelloPersonInterface
{
public HelloPerson () {}
public String sayHello(String S)
{
return new String("Hello World"+S);
}
}
Generate Stub Using rmic

… See later
Launching the Server
{
Registry r= createRegistry(4321);
HelloPersonImpl x = new HelloPersonImpl();
Remote s =
UnicastRemoteObject.exportObject(x);
r.bind("MyHelloServer",s);
}
Invoking the Server
HelloServerInterface H =
(HelloServerInterface)
r.lookup("MyHelloServer");
System.out.println(H.sayHello("Andrew"));
The RMI Classes
Interface
ServerStub
Server
The Stub
public final class HelloServerImpl_Stub
extends java.rmi.server.RemoteStub
implements HelloServerInterface
{
public java.lang.String sayHello(java.lang.String
$param_String_1)
throws java.rmi.RemoteException
{
Object $result = ref.invoke(this, $method_sayHello_0,
new java.lang.Object[] {$param_String_1},
8370655165776887524L);
return ((java.lang.String) $result);
}
Distributed vs. Centralised




Clients of remote objects interact with remote
interfaces
Non-remote arguments to, and results from, an
RMI call are passed by copy.
A remote object is passed by reference, not by
copying the actual remote implementation.
Since the failure modes of invoking remote
objects are inherently more complicated than the
failure modes of invoking local objects, clients
must deal with additional exceptions.
The DGC
Is part of the specification
 Uses a lease-mechanism with reference
counting
 Internally also keeps the VM alive when
remote objects exist

JRMP
Serialization Protocol
 HTTP Protocol


Output defines sub-protocol:
 single-op
 stream
 multiplex
Presentation

RMI – A brief introduction

The RTSJ – A brief introduction

The DRTSJ – The 3 Levels of Integration

RMI+RTSJ: Concerns, Issues and Solutions
The Real Time Specification for Java (RTSJ)

The 7 enhanced areas over Java:
 Thread
Scheduling and Dispatching
 Memory Management
 Synchronization and Resource Sharing
 Asynchronous Event Handling
 Asynchronous Transfer of Control
 Asynchronous Thread Termination
 Physical Memory Access
JSR 50

… extends RMI in the RTSJ to provide
support for predictability of end-to-end
timeliness of trans-node activities.

Expert group has published a framework
for the implementation of JSR 50,
describing three levels of integration.
The 3 levels of Integration

Level 0: RTSJ + RMI

Level 1: RTSJ + Realtime RMI

Level 2: RTSJ + Realtime RMI +
Distributed Threads
Two Requirements for RT-RMI

Requirement 1: Real-time Invocation
 End-to-End
timeliness in the invocation
process

Requirement 2: Support for RT-RMI
 Serialization,
the DGC, etc.
Real-time Invocation Control in RT-RMI
Application
Application
RMI Framework
RMI Framework
Unicast Classes:
Define Both threading
and Network Logic
VM
Network
RMI in Java
Threading
Concerns
RTVM
Network
Concerns
Network
RT-RMI
The RMI Classes
Exporting Server Parameters

Export methods defined in subclass of
RealtimeRemoteServer:
public static RealtimeRemoteServer exportObject
(
RealtimeRemote obj, int port,
SchedulingParameters sp, NetworkParams np,
Threadpool pool
)

Realtime-parameters passed up to

Network parameters stay with subclass
RealtimeRemoteServer
Propagating Client Parameters

Assigning parameters to a
RealtimeRemoteStub instance.

Implicitly inheriting or deriving the
parameters from the client Schedulable
object.

Explicitly specifying parameters for
each invocation.
RT-RMI Server Thread Model

Single Acceptor Thread associate with each
exported object
 Acceptor
is most eligible thread if CP
 Accepts call and deserialises RT parameters

Handler Thread
 Deserialises
non RT parameters
 Makes Upcall on Object
 Serialises the result and sends back to the server

Threadpool of handler Threads
Memory Considerations in
implementation

Problems for the application developer:
 Parameters
exported are used in the
Schedulables created.
 RTSJ scoping rules must be respected in
the upcall

Problems for the developer:
 Threadpools
implementation in not trivial
 Proper scoping should be used to free
objects after invocation
The DGC

If scoped memory removes GC, can it also
be used to solve DGC?

What are the semantics involved?

In particular, what is a remote object?
Connections
Should be part of a spec?
 Attach connections to pools?
 Can we assume connection-oriented
protocols
 RSVP

Carrying out distribution

How would a correct RTSJ be moved to a
distributed environment?
Asynchronicity

What are the semantics of AIEs across
node boundaries?

2 levels to address
CORBA and DRTSJ

Is RTSJ + RTCORBA = DRTSJ?

Must RTCORBA be Java aware?

How would a mapping work?
Conclusion