1. 2013 Jornadas de Tiempo Real de España
Valencia, 31 enero-1 Febrero 2013
Fine tuning and evaluation
of multiplexing facilities
in Java’s Remote
Method Invocation*
P. Basanta-Val,
M. García-Valls,
I. Estévez-Ayres ,
J. González-Fernández
http://www.it.uc3m.es/drequiemi
Universidad Carlos III de Madrid
* Published in Concurrency and Computation: Practice and Experience (IF:0,6)

2. Outlined presentation
• Context and motivation
– Efficient multiplexation in Java’s RMI
• Background on JRMP and Java´s RMI
– Stream
– SingleOp
– Multiplex
• Approach
– ConnectionLess
• Empirical Results
– Bandwidth, response-time, footprint, and latency
Valencia, JTR 2013 2

3. Context
• Benefits of Java
– Reduced development time, automatic memory
management, syntax
• Real-time Java as of today
• RTSJ (Real-Time Specification for Java)
– Implementations ready for development
• SCJ (Safety Critical Java)
• DRTSJ (Distributed Real-Time Java)
– no implementations or specifications
• Distributed real-time Java requires
– End-to-end programming abstractions
– Predicable end-to-end resource management
• Memory, CPU and Network
Valencia, JTR 2013 3

4. The contribution
• An efficient multiplexing protocol for RMI
– For JRMP(Java’s Remote Method Protocol)
– Idea: ConnectionLess subprotocol for JRMP
• To allow multiple threads invoke the same remote node “in parallel” and
“efficiently”, without penalties
– Advance:
• Flexibility
Only one TCP-IP connection required per each client-server pair !!
– Drawback
• Constant overhead in communications
• Related work:
– Some researchers proposed to add new JRMP headers to JRMP (York,
JSR-50, UPM, UC3M) in order to produce a RT-JRMP protocol
Valencia, JTR 2013 4

5. ConnectionLess as a transport subprotocol
for distributed real-time Java
• JRMP default protocol
– Stream
• Other optional
subprotocols
– SingleOp
– StreamOp
• Proposed approach
– ConnectionLess
Valencia, JTR 2013 5

6. Remote
The three JRMP Object
subprotocols and the Stub
ConnectionLess Stub
TCP/IP
Client VM Server VM
Valencia, JTR 2013 6

7. Background on JRMP
• Described as “wired
protocol” in the Java’s RMI
specification
• Subprotocols
– SingleOp
– Stream
– Multiplex
• Messages
– DGCAck
– CALL
– RETURN
– PING
– PINGAck
Valencia, JTR 2013 7

8. Remote Invocation for SingleOp
• They always involved a TCP/IP connection
– Very inefficient !!
Valencia, JTR 2013 8

9. Remote Invocation with Stream
• It may reuse an negotiated stream
subconnection for further2013
Valencia, JTR
sequential invocations 9

10. Remote Invocation with Multiplex
• It allows multiple remote invocations “in parallel” from the same client
• However, it is very inefficient
– Three negotiations (TCP, RMI connection, Multiplex connection)
– Multiple copies to buffers Valencia, JTR 2013 10

11. Remote Invocation with ConnectionLess
• Based on Stream and Mux:
– VCs managed dynamically
by the client
• Allows efficient remote
invocations in parallel
Valencia, JTR 2013 11

12. Supporting ConnectionLess
• At JRMP protocol messaging level:
– Protocol definition with 0x60
– A new VC(2 bytes) header
Valencia, JTR 2013 12

13. Supporting ConnectionLess
VC management
• The VC used in RETURN
is equal to the VC used
in CALL
• VCs are
– generated in order
– Reused after the remote
invocation
Valencia, JTR 2013 13

14. Implementation
• Based on RTSJ-RI by TimeSys
– Compliant with RTSJ 1.0.2
• RMI-OP for J2ME
– Supports Stream
• (We) added implementation for
– SingleOp
– Multiplex
– ConnectionLess
Class diagram for ConnectionLess
implementation
Valencia, JTR 2013 14

15. Evaluation
• Features
• Local or remote
configuration Traffic Traffic
• 1300 Mhz machines x 2 generator generator
• 100Mbits SW-Ethernet client server
connection RMI_OP RMI_OP
• Evaluation metric (stream, singleop, ..) (stream, singleop, ..)
– Response-time
– Memory RTSJ RTSJ
– Bandwidth
– Footprint
Traffic
Analizer
Valencia, JTR 2013 15

16. End-to-End Response time
Minimal application payload
Valencia, JTR 2013 16

17. End-to-End Response
time
With appl. payload
• Trends
– SingleOp is the worst
protocol
– Stream is the best
• ConectionLess is the
second
Valencia, JTR 2013 17

18. End-to-End Response time
With appl. payload
• Stream is the worst
protocol
• ConnectionLess is
the best protocol
Valencia, JTR 2013 18

19. Bandwidth results
Valencia, JTR 2013 19

20. Bandwidth results
• In permanent regime
– Stream is the best in
perforamnce
– ConnectionLess is the
second
• For concurrent invocations
– Connectionless is the best
in perfomance
Valencia, JTR 2013 20

21. Memory Allocation Results
(bytes in Heap)
Valencia, JTR 2013 21

22. Memory Allocation Results
(bytes in Heap)
• In permanent regime
– Stream is the best
protocol
– ConnectionLess is the
third !!!
• It uses preallocation
Valencia, JTR 2013 22

23. Memory Allocation Results
(bytes in Heap)
• In concurrent invocations
– Multiplex is the best in
dynamic memory
consumption metrics
– ConnectionLess is the one
with less footprint
Valencia, JTR 2013 23

24. Conclusions and ongoing work
• This work evaluated a new JRMP subprotocol
(ConnectionLess) for parallel remote
invocations
– Results are satisfactory
• Low overhead & parallel invocation supported via VCs
• Ongoing work
– Impact on control applications
– Serialization impact on JRMP communications
– Integration of RT-JRMP with ConnectionLess
Valencia, JTR 2013 24

25. 2013 Jornadas de Tiempo Real
Valencia, 31 enero-1 Febrero 2013
Valencia, JTR 2013