Philip K. McKinley - PowerPoint PPT Presentation

About This Presentation
Title:

Philip K. McKinley

Description:

Philip K. McKinley. Software Engineering and Network Systems Laboratory ... One CompactFlash type I card slot. Ports. One RS-232C serial port. One IrDA port. Battery ... – PowerPoint PPT presentation

Number of Views:106
Avg rating:3.0/5.0
Slides: 46
Provided by: liji
Learn more at: http://www.cse.msu.edu
Category:

less

Transcript and Presenter's Notes

Title: Philip K. McKinley


1
Adaptive Middleware for Heterogeneous Collaborativ
e Computing
  • Philip K. McKinley
  • Software Engineering and Network Systems
    Laboratory
  • Department of Computer Science and Engineering
  • Michigan State University

2
Outline
  • SENS Lab and Communications Research Group
  • Summary of prior research activities
  • Issues in anytime, anywhere, anyhow computing
  • Ongoing Projects
  • Pavilion web-based collaborative toolkit
  • RAPIDware adaptive middleware framework
  • Meridian automated development of distributed
    applications
  • Summary

3
MSU SENS Laboratory
  • The Software Engineering and Network Systems
    Laboratory supports research in
  • software engineering
  • distributed computing
  • network protocols and real-time systems
  • fault tolerance and security
  • formal methods, code generation
  • compilation/analysis of concurrent systems
  • Six faculty members and their students
  • Research sponsored by NSF, DARPA, DOE, NASA, EPA,
    and several industrial partners

4
Communications Research Group
  • A research group within the SENS Laboratory
  • Much of our research addresses the design and
    performance of multiparty applications,
    protocols, and services. Prior research
  • Parallel processing
  • collective communication in MPPs and NOWs
  • Distributed Computing
  • reliable multicast in Linux kernel and in NT
  • Networking
  • hardware-based flooding in ATM networks
  • efficient leader election, routing protocols

5
Motivations for Current Work
  • Anytime, anywhere data access and communication
    is quickly becoming reality, due to
  • development of world-wide web
  • large scale deployment of wireless services
  • advances in handheld/wearable computers
  • One class of applications that will likely
    benefit from this infrastructure is collaborative
    computing systems
  • Examples CSCW, remote instruction, factory
    management, medical diagnosis, command and
    control
  • Users will access services through a variety of
    network connections and computing devices

6
Example Scenario
  • Remote collaboration among researchers

Same technology will also be used for everyday
collaboration among family members, etc.
7
Pavilion Project
  • A Java-based middleware framework for
    web-oriented collaborative applications
  • By default, provides collaborative browsing
  • More importantly, supports development of new
    applications by reusing/extending components
  • Reliable Multicast Protocol (WBRM)
  • Web Browser Interfaces
  • Leadership Protocol
  • Extensible HTTP Proxy
  • Plug-ins for thin clients
  • etc...

8
Default Pavilion Operation
9
WBRM Protocol Architecture
Packets
In-order Resources
Resend Non-data
Re-ordered Resources
NAKs
Resend Data
RTT info
Echo messages
10
WBRM Performance
  • Over 8Mbps throughput on 10Mbps Ethernet and
    around 50Mbps on 100Mbps Ethernet, depending on
    processors
  • Performance approaches that of our Linux kernel
    protocol, H-RMC, with much less development effort

11
WBRM on 100 Mbps Ethernet
  • Performance approaches that of our Linux kernel
    protocol, H-RMC, with much less development effort

12
Pavilion Proxy Servers
  • Proxies can be used to provide transparent
    services to collaborative web-based applications
  • Local proxies execute on client's local host and
    are typically used to enhance application
    functionality
  • Remote proxies execute on other systems and
    enhance performance by tailoring data streams to
    match client capabilities
  • A key design principle in Pavilion (and follow-on
    RAPIDware project) is to provide such services in
    the form of data- and application-specific
    plug-ins

13
Building Applications with Pavilion
  • Pavilion may be extended by implementing
    application-specific plug-ins (loaders, filters,
    etc) for various proxies.
  • Plug-ins used to perform the following tasks
  • Distill data stream to reduce bandwidth
    consumption or client processing overhead
  • Modify the web resources according to
    application-specific needs
  • Wrap the resource in another file that is
    returned to the browser (used to load associated
    applet). Such applets can communicate with other
    participants via local Pavilion worker threads.

14
HTTP Plug-in Operation
Notify users
Browser Interface
Multicast to users
HTTPProxy
Request starts here
Filter
Loader
Filter
Browser Address Space
Application Address Space
15
Example VGuide
  • VGuide is a Pavilion-based synchronous virtual
    reality tool
  • leader selects (arbitrary) VRML world and guides
    other participants through that world
  • Uses/extends several Pavilion components
  • reliable multicast protocol to distribute VRML
    file and associated applets
  • proxy server plug-ins to intercept file and
    wrap it in an html file containing an
    application-specific applet
  • applets and worker threads to monitors viewpoint
    changes and multicast them to other group members

16
VGuide Demonstration
17
VGuide Component Overview
Leader Browser
Client Browser
  • VRML plug-in to Http proxy wraps VRML file in
    html file with embedded applet
  • Http proxy distributes VRML file and associated
    applet
  • Applet uses External Authoring Interface (EAI) to
    access the VRML world
  • Applet forwards viewpoint updates to VRML thread
    using socket
  • VRML thread sends viewpoint updates to other
    participants using IP multicast

EAI Applet
EAI Applet
socket
socket
VRML Thread
VRML Thread
IP Multicast
Browser Interface
Browser Interface
VRML Plug-in
Http proxy
Http proxy
Reliable Multicast
18
Handling VRML Requests
  • Requests for VRML files are intercepted by the
    proxy and passed to a plug-in
  • As required by EAI, the monitoring thread must
    run in the same address space as the VRML browser
  • HTML wrapper used to embed VRML file and applet
    into browser address space

EaiApplet
ltHTMLgt ltHEADgt ltTITLEgt VGuide lt/TITLEgt lt/HEADgt ltEMB
ED . SRC"world.wrl"gt ltAPPLET code"EaiApplet.cla
ss" . gt lt/APPLETgt lt/BODYgt lt/HTMLgt
19
VGuide Initialization Steps
Web Browser
Web Browser
Vrml.htm EaiApplet.class world.wrl
Vrml.htm EaiApplet.class world.wrl
Local Disk
Local Disk
Http//localhost1111/ltvrml.htm, world.wrl,
EaiApplet.classgt
Http//localhost1111/vrml.htm
EaiApplet
EaiApplet
Http///world.wrl
Main
Proxy
VRML Plug-in
Proxy
Retrieve .wrl file
VrmlThread
VrmlThread
Web Server
Pavilion (leader)
Pavilion (client)
20
Platform Heterogeneity
  • The time needed to read/modify object in a VRML
    word varies on each machine.
  • Time to modify an object depends highly on video
    adapter performance
  • Time to read an object depends on CPU speed.
  • Presence of heterogeneous participants could lead
    to high jitter and buffer overflow.
  • Updates filtered by proxies for slow clients in
    order to improve performance

21
Jitter Results
  • Jitter measured over 500 consecutive viewpoint
    updates
  • On slow receivers (upper figure), jitter is
    higher (50 ms avg) because viewpoints accumulate
    at the receivers buffer.
  • On fast receivers (lower figure), jitter is lower
    (0.33 ms avg) because receiver can keep up with
    sender.
  • Recent tests show we can obtain low jitter (near
    zero) in both cases by having proxy discard
    viewpoints that arrive too close together.

22
Pocket Pavilion Subproject
  • Goals
  • To design a web-based application that extends
    collaborative browsing to wireless handheld
    computing platforms running Windows CE
  • To demonstrate reuse of Pavilion components in
    supporting heterogeneous clients
  • To evaluate the performance of using a wired
    proxy on behalf of wireless clients
  • Key issue accommodating limitations of handheld
    PCs and the Windows CE environment

23
Handheld/Palm-Sized PCs
  • No disk, only ROM and RAM
  • Can be connected to a desktop to synchronize data
  • Run PalmOS, Windows CE, ...

24
HP 620LX/660LX Handheld PC
  • 75MHz RISC processors (Hitachi SH-3)
  • Display
  • 256-color LCD
  • 640240 pixels on screen
  • 32MB/16MB RAM
  • Card Slots
  • One PC card type II card slot
  • One CompactFlash type I card slot
  • Ports
  • One RS-232C serial port
  • One IrDA port
  • Battery
  • Rechargeable Lithium-Ion Battery
  • CR2032 coin-cell backup battery
  • Windows CE 2.0

25
Windows CE
  • Modular, real-time OS for embedded and dedicated
    systems
  • Written in C
  • Delays are bounded
  • Many modules are optional

26
Windows CE Characteristics
  • Limitations
  • At most 32 processes can be running concurrently
  • Pocket IE supports only HTML and embedded images
  • Supports only a subset of Win32 API
  • Version 2.0 does not support IP multicast
  • No DDE support, COM is only partially supported
  • Programming Environments
  • Visual C, Visual Basic and Visual J
  • Third-party support for Basic and C
  • All of the above use cross-compilers

27
Experimental Configuration
28
Implementation Issues
  • Programming Language
  • Pocket Pavilion Client Visual C
  • All other parts of Pavilion are written in Java
  • Inter-process Communication
  • No DDE support
  • COM not supported for Pocket Internet Explorer
    (PIE)
  • Hence, we use native windows messaging for
    communication between the PP client and PIE
  • IP Multicast support
  • Windows CE 2.0 supports a subset of WinSock 1.1
    (no IP multicast support)
  • Hence, we use unicast channels for communication
    between the proxy and the H/PCs
  • Proxy performs data caching services in order to
    improve performance

29
Pocket Pavilion Operation
30
Performance small files
31
Sample Performance
32
Performance large files
33
Performance Near Cell Periphery
34
RAPIDware Project
  • Extends Pavilion by addressing automatic
    instantiation and adaptation of the middleware
    layer
  • Key objectives
  • Automatically accommodate heterogeneity of among
    computing devices and network connections
  • Adapt to failures, changes in channel quality,
    etc.
  • Provide support for reuse of middleware
    components
  • Offer a unified methodology for three types of
    adaptation communication services, user
    interfaces, fault tolerance
  • Observers monitor system and detect changes
  • Responders handle such events by instantiating
    new components or changing their behavior

35
Adaptive Component Interaction
36
Pavilion/RAPIDware Subprojects
  • VGuide is a synchronous collaborative virtual
    reality tool
  • Pocket Pavilion extends multicast-based
    collaborative browsing to wireless handheld PCs
  • Proxy-based adaptive forward error correction for
    video/audio streaming, as well as reliable
    multicasting,

37
Subproject Adaptive FEC for Reliable
Multicasting on WLANs
  • Forward Error Correction (FEC) can be introduced
    at a WLAN proxy to mitigate potentially high
    packet loss rates
  • Losses among multiple receivers in WLANs are
    often uncorrelated, since they depend on the
    distance from the access point and environmental
    conditions
  • Objective experimentally evaluate effectiveness
    of proxy-based FEC on multicast data streams in
    WLANs, and explore how to adapt FEC to changing
    conditions
  • Proxy runs two instances of protocol, one tuned
    for wired network, and one tuned for wireless
    network

38
Experimental Environment
  • Computing Platforms
  • SMP Workstations/PCs (Sun, Dell), Laptops (Dell
    Latitudes), Handhelds (HP 620, 660)
  • Networks
  • Switched Ethernet and Fast Ethernet
  • Three WLANS Lucent WaveLAN (2 Mbps), Proxim
    RangeLAN2 (1.6 Mbps), Cisco/Aironet WLAN (11 Mbps)

39
WLAN Loss Characteristics
  • Traces in our testbed showed that, while large
    burst errors can occur, many burst errors are
    very short (usually 1 packet)

40
Receiver Throughputs without Proxy and with Proxy
41
(n,k) Block Erasure Codes
  • Divide data (audio) stream into groups of k
    packets
  • For each group, send k data packets and n-k
    parity packets
  • Receipt of any k packets enables reconstruction
    of data

42
FEC Proxy Design
  • Reuses several classes from WBRM protocol
  • Adaptive components operate as plug-in modules

43
Proactive Parity Transmission
  • In the presence of high losses, it usually takes
    multiple NAKs (and hence RTTs) to correct losses
    in a group since the correction packets
    themselves are susceptible to losses
  • Sending immediate redundant information along
    with the data and NAK responses may help in
    solving this problem
  • Can adjust proactive rate a proportionally to
    loss rate
  • Experiments show that throughput is less affected
    by an over-estimate of the proactive parameter
    than by an under-estimate

44
Adaptive FEC Parameters
  • a - Proactive percentage
  • amin Minimum value of a
  • ainc Amount by which a is increased based on
    the feedback information from receivers
  • M scale factor used to increment a
  • adec Amount by which a is decreased based on
    the feedback information from receivers
  • W Number of groups after which a is decreased
  • G FEC group identifier
  • LC Number of packets lost in a group G
    (obtained from NAKs)

45
Results for Fixed a
46
The Adaptive Algorithm
  • Initially a amin
  • While transmitting a group of k packets, the
    proxy also immediately sends ka parity packets
  • In response to a NAK of the form (G, LC), the
    proxy
  • sends LC(1a) parity packets
  • sets ainc M LC/k
  • sets a a ainc
  • If there are no NAKs for a period of W groups,
  • set a a - adec

47
Evaluation of the Adaptive FEC Algorithm
  • Based on our observations, ainc needs to be
    sufficiently large to reduce further NAKs and
    increase throughput
  • We can afford a larger value of M as opposed to a
    smaller value that under-estimates the value of a
  • But a large M may result in reduced bandwidth
    efficiency through unnecessary traffic
  • To control losses, some of our tests use
    emulation. Others use experimentation on our
    testbed.

48
If W is too low...
M3, W3, loss20
M2, W3, loss20
49
Changing the value of M
M3, W10, loss20
M2, W10, loss20
M4, W10, loss20
50
Results with M3, W10
5 loss
10 loss
20 loss
51
Sample Results (Emulation)
5 loss
10 loss
20 loss
52
Accommodating Burst Losses
  • Many losses in wireless networks occur in bursts
  • The bursts seem to be clustered around adjacent
    groups for short periods
  • A desirable decrement function would be one that
    starts decreasing slowly and then decreases
    rapidly over time
  • We use an adec 2i 0.02 as the decrement
    function after W (10) groups where i (number
    of consecutive groups without NAKs) / W

53
Sample Results (Experimental)
adec0.02
adec2i(0.02)
adec2i(0.02) lower bound 1
54
Throughput Results
  • Emulated loss rate varied up to 0.20
  • Compared no FEC, static FEC, adaptive FEC

55
Subproject Mobile Composable Filters
  • Questions
  • can we apply mobile agent concepts to
    instantiation and population of proxies?
  • Can we dynamically insert filters into running
    communication streams without disruption?
  • Goal identify and evaluate glue mechanisms
    needed for dynamic construction of lightweight
    proxies in which components are created,
    migrated, composed as necessary to accommodate
    heterogeneous and dynamic environments
  • Example proxy services FEC, filtering, web
    clipping

56
Proxy Framework
  • Mobile Composable Filters enable proxy filters to
    be uploaded and dynamically inserted into
    (running) data streams

57
The Classes
  • To facilitate the making and breaking of data
    flow inside the Proxy Container two new classes
    were created
  • DetachableInputStream
  • DetachableOutputStream
  • These streams have all the methods available in
    PipedInputStream and PipedOutputStream classes of
    the Java2 API.
  • They also have additional methods that allow us
    to handle diverse data streams.
  • The ControlThread communicates with a
    ControlManager and implements the proxy
    management.
  • The ControlManager class serves to control the
    proxy framework remotely. It can be easily
    integrated to a browser.

58
DIS/DOS Interaction
  • Similar to other Java I/O streams, except that
    they can be paused, reconnected, restarted

59
Filter Configuration
Filter Code
DIS
DOS
  • The DIS and DOS are setup by the ControlThread.
  • The developer writes filter code that gets its
    input form the DIS and sends output to the DOS.
  • Otherwise, no restrictions on the developer.
  • All filter writers extend the Filter interface
    and also use the setDIS and setDOS methods that
    define the DIS and DOS to the filter

60
Remote Code Control
  • A Control Manager provides an interface to the
    system and interacts with a Control Thread on the
    proxy
  • The current framework uses simple serialization
    to enable filters to be remotely instantiated on
    a proxy
  • The Control Thread has methods to handle the
    following tasks
  • Indexed filter insertion and removal
  • Remote filter reception
  • Generation of a map of the current system
  • A cache of available filters, based on a custom
    FilterContainer class

61
Screen Shot of Control Manager
62
Current Status
Web Location
Control Manager
Internet
Mobile Device
F4
Wireless link
Local Proxy Host

PROXY
Control Thread
Socket Thread I/P
Socket Thread O/P
F1
F2
F3
F4
63
Current Status
  • Presently, we are refactoring various Pavilion
    proxy filters to work within the new framework
  • Example FEC insertion in video streams

64
Meridian
  • Large multi-investigator project supported by NSF
    grant
  • Goal Develop an end-to-end, integrated set of
    tools that automate the development and
    maintenance of interactive distributed
    applications
  • Case studies from several industrial partners
    involving on-board control, web-based
    collaboration, mobile telecommunications

65
Interactive Distributed Applications
Interact with users processing/data distributed
across network.
  • Examples
  • On-board driver/pilot navigation systems.
  • Computer-supported collaborative work
    environments.
  • Distributed interactive simulation.

66
Characteristics of IDAs
  • Interactivity
  • Must interact with one or more human users.
  • Design requires prototyping and experimentation.
  • Concurrency
  • Comprise levels of communicating, concurrent
    components.
  • Analysis requires formal reasoning.
  • Reuse
  • IDAs built primarily from reusable components.
  • E.g., comm. protocols, resource managers, data
    displays.
  • Design involves selecting/specializing components.

67
Research goals
  • Improve quality of IDAs.
  • Better IDAs (reliable, maintainable, extensible).
  • Better development (faster, cheaper).
  • Advance state of automated software-engineering
    (ASE) practice.
  • Incorporate ASE techniques into mainstream
    development.
  • Apply various formal methods in a new domain.
  • Identify end-to-end automation techniques that
    take advantage of multiple phases of development.

68
Practical goals
  • To have techniques adopted in practice
  • Must complement existing design methods and
    notations.
  • Otherwise, acceptance must overcome stiff
    economic hurdles.
  • Implications
  • Designers should not reformulate designs in a
    formal notation.
  • Designers should not have to view the output of a
    formal analysis tool.
  • We chose (UML) for representing IDA designs.

69
Meridian Methodology
  • Developers create UML models of system
    components, based on requirements, using Model
    Editor, which also produces formal specifications
  • Formal specifications analyzed for correctness,
    temporal consistency, deadlock freedom, race
    conditions, etc
  • OO code synthesized from specifications, inserted
    into reuse framework
  • Code input to emulators/simulators for
    performance testing
  • Continuous feedback in terms of original
    requirements

70
Meridian Vision
Refined Specifications
Design Processing
Specifications
Specification Analysis
Testing/ Simulation
Model Editing
Code
Requirements
Feedback
User
Test Cases
71
Enabling Technologies
  • Formal representations throughout development
    process
  • facilitates requirements analysis and
    traceability,
  • enables reasoning about concurrency properties,
    and
  • supports reuse.
  • Visualization insulates designers from formal
    representations.
  • Code generation/selection synthesizes systems
    from models.
  • Simulation/prototyping tests non-functional
    requirements
  • (e.g., usability, responsiveness, etc.)

72
Model Editor
  • Supports editing of UML models.
  • Incorporates reusable IDA models.
  • Generates formal representations of the models
  • Supports automated analysis of graphical models

73
Reuse Environment
  • Supports browsing/selection from reuse
    repositories.
  • Component-based
  • Index components by formal specs
  • Search and retrieve based on specs

74
Tool suite (contd)
  • Temporal Analyzer
  • Augments UML models with temporal constraints.
  • Graphical spec of timing constraints
  • Design Processor
  • Automatically refines UML models.
  • Generates code and selects reusable components
  • Adapts components to satisfy interface
    constraints
  • Checks consistency between refinements

75
Emulation/Simulation of Synthesized Components
  • MX simulator supports emulation of code identical
    to that used in experiments, via a socket-level
    system call interface
  • Provides both C and Java APIs

Process Thread Placement Module
Application Code
Host/Network Configuration File
Network Module (Routing Domains, Wired/Wireless
Channels, Routers, Wireless Access Points, etc.)
76
Case studies
  • Web-based multiparty applications
  • WebClass/Pavilion web-based collaborative
    environment
  • NetMapper network management utility.
  • On-board control systems
  • Automotive applications (e.g., cruise control,
    steering)
  • Fault protection system (NASA/JPL).
  • Wireless telecommunication services
  • Emergency telecomm services implemented over a
    digital radio infra-structure.

77
Overview of talk
  • Interactive distributed applications (IDAs).
  • Goals and vision.
  • Proposed research.
  • Validation and contributions.

78
Validation and deliverables
  • Validation through extensive case studies.
  • Each case study comprises two parts
  • Definition existing application guides tool
    development and repository population.
  • Validation test framework on a different
    application.
  • Deliverables in three increments
  • Core suite of tools validated on Web-based
    multi-party apps.
  • Incorporate on-board--control domain.
  • Incorporate wireless-telecom domain.

79
Meridian Contributions
  • Automates end-to-end development of IDAs
  • Extends visual development to encompass formal
    reasoning.
  • Supports reuse at many levels of abstraction
    using a common notation UML
  • Integrates formal analysis and testing/simulation.
  • Enables tracing of requirements from diagrams to
    code
  • Facilitates evolution of software to accommodate
    new technologies
  • Holds promise of Internet-Speed development.

80
Summary
  • Pavilion (present) focuses on communication
    protocols for interconnecting heterogeneous
    mobile nodes and on reuse of collaborative
    components
  • RAPIDware (short term) seeks to develop a
    unified methodology for design of adaptive
    middleware and automate its operation
  • Meridian (long term) seeks to automate many
    aspects of the development of interactive
    distributed applications in order to improve
    their quality and maintainability

81
Related Work
  • Groupware Toolkits
  • JETS, Promondia, TANGO, Habanero, DISCIPLE,
    MultiTel, and others
  • Adaptive Middleware Frameworks
  • Rover, TAO, MCF, DaCapo, Odyssey, QuO,
    Mobiware, Remulac, Sync, MOST, Limbo, ...
  • Configurable Proxies
  • Transend, MPA, Mobiware, Alpine, Active Names,
  • FEC for multicast
  • RMDP protocol (Rizzo and Vicisano, 1998
  • NP (Nonnenmacher et al., 1998)
  • ECSRM (Gemmell, et al. 1998)

82
Related Work (FEC Multicast)
  • RMDP protocol (Rizzo and Vicisano, 1998)
  • hybrid FECARQ with parameters set according to
    network type
  • expansion factor D is similar to a, except that a
    applies to all transmissions
  • adaptation handled by changing (n,k) values
  • NP (Nonnenmacher et al., 1998)
  • integrated FECARQ protocols, targeting
    Internet-wide applications
  • minimizes number of parity packets sent, at
    expense of latency
  • pipelining to improve throughput, as does
    W-WBRM
  • ECSRM (Gemmell, et al. 1998)
  • FEC and global NAK suppression for Internet
    telepresentations
  • no adaptation to changing conditions

83
Ongoing/Future Work
  • Studies of FEC applied to live audio streams (ACM
    MM00) and video streams (IEEE MNS01)
  • Design of interfaces for composable proxy filters
    (IEEE WNMC01)
  • Further study of the various parameters in the
    adaptive FEC algorithm through experimentation
  • Development of a simulator, MX, to study
    performance of communication protocols in
    wireless and other environments
  • Study of extensions and scalability of the proxy
    through simulation

84
Further Information
  • Project descriptions, including related papers
    and technical reports, are available at
  • Email address mckinley_at_cse.msu.edu
  • This research was supported in part by National
    Science Foundation grants DUE-9551180,
    CCR-9503838 CDA-9617310, NCR-9706285, and
    CCR-9912407, and EIA-0000433.

http//www.cse.msu.edu/mckinley
Write a Comment
User Comments (0)
About PowerShow.com