The Design and Performance of a Pluggable Protocols Framework for Real-time Distributed Object Computing Middleware

Transcription

1 The Design and Performance of a Pluggable Protocols Framework for Real-time Distributed Object Computing Middleware, Fred Kuhns, Douglas C. Schmidt, Ossama Othman and Jeff Parsons coryan@uci.edu Motivation: Rapid Growth in Hand-held Devices ' & Lewis:98 (IEEE Computer Jan 98) ' $ & % Comerford:98 (IEEE Spectrum May 98) Devices! PDAs, WebPhones, WebTVs, handsets Requirements! Low power consumption, small memory/message footprint, efficient/predictable performance $ % University of California, Irvine 1 Candidate Solution: CORBA Caveat: Limitations of CORBA for Wireless Goals of CORBA Simplify distribution by automating Object location & activation Parameter marshaling Demultiplexing Error handling Provide foundation for higher-level services Requirements Location transparency QoS transparency Minimal footprints Limitations Lack of appropriate protocols Lack of real-time and async QoS features Lack of performance optimizations University of California, Irvine 2 University of California, Irvine 3

2 OMG Approach: Wireless CORBA Wireless Access & Control RFI.html! Overview Mobility domain and fixed domain bridges handle mobility e.g., relocatable object references via location register Lightweight ESIOP reduces message footprint University of California, Irvine 4 Our Approach: The ACE ORB (TAO) TAO! Overview An open-source, standards-based, real-time, high-performance CORBA ORB Runs on POSIX/UNIX, Win32, & RTOS platforms e.g., VxWorks, Chorus, LynxOS Leverages ACE University of California, Irvine 5 Motivation ' Middleware should exploit the good features of its environment The Middleware Hypocratic Oath CORBA is increasingly being used in distributed embedded systems. Protocol selection must be done as late as possible in the design cycle & Lewis:98 (IEEE Computer Jan 98) & % Comerford:98 (IEEE Spectrum May 98) Devices! PDAs, WebPhones, WebTVs, handsets Requirements! Low power consumption, small memory/message footprint, efficient/predictable performance % ' $ $ University of California, Irvine 6 University of California, Irvine 7

3 Problem: Hard-coded ORB and Transport Protocols GIOP/IIOP are not sufficient for all environments, e.g.: GIOP messages may be too large lacks necessary QoS Legacy commitments to certain protocols Existing ORBs don t support pluggable protocols Both ORB messaging and transport protocols must be pluggable Context: CORBA Protocol Architecture COMPONENT ADAPTER COMPONENT TRANSPORT LAYER NETWORK LAYER STANDARD CORBA PROGRAMMING API GIOP IIOP IP GIOPLITE -IOP ESIOP PROTOCOL CONFIGURATIONS ATM-IOP RELIABLE SEQUENCED AAL5 ATM protocols.ps.gz! Features Presentation layer e.g., CDR Message formats e.g., GIOP, DCE Transport assumptions e.g.,,atm Object addressing e.g., IIOP IOR University of California, Irvine 8 University of California, Irvine 9 Solution: TAO s Pluggable Protocols Framework Design Challenge: Adding New Protocols Dynamically STUBS CLIENT COMPONENT GIOP GIOPLITE REAL-TIME IOP RELIABLE, BYTE-STREAM ATM IN ARGS operation (args) OUT ARGS & RETURN VALUE ESIOP MULTICAST IOP UDP ADAPTER COMPONENT EMBEDDED IOP SKELETONS ADAPTIVE Communication Environment (ACE) COMMUNICATION INFRASTRUCTURE Pluggable ORB messaging and transport protocols OBJECT (SERVANT) ORB MESSAGE FACTORY ADAPTER FACTORY OBJECT ADAPTER OTHER ORB CORE SERVICES POLICY CONTROL CONCURRENCY MODEL REAL-TIME I/O SUBSYSTEM HIGH SPEED NETWORK INTERFACE MEMORY MANAGEMENT Highly efficient and predictable static and/or dynamic configuration REGISTRY IIOP ATM-IOP SERVICE CONFIGURATOR <<INSTANTIATES>> <<INSTANTIATES>> Problem: the range of protocols available can be modified late in the development cycle. Solution: Use the Service Configurator pattern to: Dynamically load the registry class or, dynamically load a registry class that dynamically loads its contents University of California, Irvine 10 University of California, Irvine 11

4 Embedded System Benchmark Configuration Ethernet & Two-way Latency Results VxWorks running on Mhz PowerPC over 320 Mbps & 10 Mbps Ethernet Data Type long seq <long> short seq <long> long seq <octet> short seq <octet> struct /GIOPlite avg. long /GIOP avg. octet Ethernet/GIOPlite avg. short void Latency (usec) Synopsis of Results protocol is much faster than Ethernet No application changes are required to support University of California, Irvine 12 University of California, Irvine 13 Pinpointing ORB Overhead with tro Timeprobes ORB & One-way Overhead Results usecs 100% 90% 80% 70% 60% 50% 40% 30% 20% 10% 0% OS overhead ORB client pre-write ORB client post-write ORB server overhead Sequence length (bytes) Synopsis of Results ORB overhead is relatively constant and low e.g., 110 secs per endto-end operation Bottleneck is driver and OS, not ORB Timeprobes use tro monitor, which measures end-to-end time Timeprobe overhead is minimal, i.e., 1sec University of California, Irvine 14 University of California, Irvine 15

5 Workstation Benchmark Configuration Loopback vs. Local IPC Results IDL STUBS CLIENT MARSHAL PARAMS SEND MESSAGE REAL-TIME I/O INTERFACE obj->op (params) BUFFER MANAGEMENT NETWORK LINK DEMARSHAL PARAMS ORB CORE DISPATCH MESSAGE DEMUX OBJECT (SERVANT) IDL ACTIVE OBJECT SKELETON MAP OBJECT ADAPTER REAL-TIME I/O INTERFACE Calls per Second void short octet long struct small seq<octet> large seq<octet> Data Type small seq<long> IIOP IIOP/GIOPlite UIOP UIOP/GIOPlite Performance Increase large seq<long> small seq<struct> large seq<struct> 60.00% 50.00% 40.00% 30.00% 20.00% 10.00% 0.00% Performance Improvement (%) Significant improvements when using Local IPC for all cases The effect of message footprint is small But would be more significant for low bandwidth links Debian Linux running on 400 Mhz workstation over Local IPC University of California, Irvine 16 University of California, Irvine 17 ORB & Transport Overhead Results Open Issues for Wireless CORBA Total Time (usecs) IIOP IIOP w/gioplite UIOP UIOP w/gioplite Transport Protocol OS and I/O ORB Transport Messaging Synopsis of Results ORB overhead is relatively constant and low e.g., 49 secs per two-way operation Bottleneck is OS and I/O operation COMPONENT ADAPTER COMPONENT TRANSPORT LAYER NETWORK LAYER STANDARD CORBA PROGRAMMING API GIOP IIOP IP GIOPLITE -IOP ESIOP PROTOCOL CONFIGURATIONS ATM-IOP RELIABLE SEQUENCED AAL5 ATM Where should terminal mobility be supported? i.e., inrequest Bridge vs. Mobile IP What types of ESIOPs are necessary? e.g., IIOP variants or entirely new ORB messaging protocols How will CORBA services be affected? University of California, Irvine 18 University of California, Irvine 19

6 Concluding Remarks Web URLs for Additional Information Pluggable protocols are essential to meet the needs of many CORBA applications, such as wireless and embedded systems Currently there are several efforts in the OMG to standarize pluggable transport and signaling protocols The Portable Interceptors specification will define standard interfaces for serialization These slides: schmidt/tao/pluggable protocols4.ps.gz Information on pluggable protocols: schmidt/pluggable protocols.ps.gz Information on CORBA: schmidt/corba.html InformationonACE: schmidt/ace.html InformationonTAO: schmidt/tao.html University of California, Irvine 20 University of California, Irvine 21