1 / 15

Background

A Prototype Ptolemy II Domain for Studying Component Interactions in Distributed Systems Xiaojun Liu Yang Zhao May 15, 2002. Base Station. Background.

fifi
Download Presentation

Background

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. A Prototype Ptolemy II Domain for Studying Component Interactions in Distributed SystemsXiaojun LiuYang ZhaoMay 15, 2002

  2. Base Station Background • Complex distributed systems contain many loosely coupled components. These components may initiate interaction with other components via a distributed communication mechanism. • The flight management system of an aircraft can have multiple controllers integrated using OCP/TAO. • In a sensor network, the “motes” can adaptively reconfigure the network using their wireless communication interface.

  3. Difficulties and Solutions • Difficulties: • heterogeneity of hardware architectures, diversity of operating systems and communication platforms, different programming language • The correct behavior emerges from the interaction among loosely coupled components. • The correctness may not be obvious from the point of view of any component in the system. • other issues... • Solutions: • Provide high-level APIs for distributed communication and computation. • CORBA/Common Object Services, DCOM, OCP/TAO • Create simulation tools to help the designers understand the semantics of the API and evaluate their designs. Node A Node B Node C CORBA/DCOM TCP/IP Communication Systems Physical Network Node D Node E Node F

  4. CORBA • CORBA is a distributed object computing middleware standard. • ORB mediates the transfer of messages, hide underlying complexity of network communication. • IDL specifis a clearly defined interface for each CORBA object. • A typical CORBA Scenario:

  5. Component Interaction in the CORBA Event Service • Producer, Consummer, and Event Channel. • Support one-to-many, decoupled communication among components. • Both producers and consumers can initiate interaction.

  6. Modes of Interaction in the CORBA Event Service The Canonical Push Model The Canonical Pull Model The Hybrid Pull/Push Model The Hybrid Push/Pull Model

  7. Roles of Components in theCORBA Event Service Event-driven/data-driven component Demand-driven component Queuing component Active agent

  8. Other Examples of Push/Pull Interaction • A browser can pull a web page from a server using the HTTP GET method; it can push user data to the server using the POST method. • In the Click modular router architecture*, packet handoff along a connection may be initiated by either the source end (push processing), or the destination end (pull processing). • In a component model of an operating system, an application component reading a file makes pull requests to the OS kernel components that handle disk I/O. *: http://www.pdos.lcs.mit.edu/~rtm/papers/click.pdf

  9. A Component-Interaction Domain in Ptolemy II • The domain supports the simulation of systems in which components communicate via both push and pull. • Each connection (IORelation) in the model has the semantics of an event channel. • Computation in models can be data/event-driven, or demand-driven, or both.

  10. queue active source data/event-driven computation active sink active actor demand-driven computation Partition of Models in the Component-Interaction Domain

  11. Simulation of Models in the Component-Interaction Domain • Active actors (including active sources and sinks) run in their own threads. • The director maintains a FIFO queue of actors to fire. The director fires the actors in its own thread until the queue is empty, then waits for the active actors to produce pushed data or pull requests. • For data/event-driven computation, an actor with push input is added to the queue when data arrive at the input. • For demand-driven computation, the director propagates pull requests toward the producers. A pulled producer is scheduled to fire when it becomes ready.

  12. Demonstration – A Switch Model • The model uses the Click modular architecture. output interface 4 packets/second input interface load balancing RED dropping control output interface 1 packet/second

  13. d 1 maxMark 0 minMark total queue length Demonstration – A Switch Model • Random early detection dropping for congestion avoidance RED drop input packet if random() < d • Load balancing send input packet to the shorter output queue

  14. Benefits Provided by the Component-Interaction Domain • It supports the modeling of distributed systems that consist of autonomous components. Both producers and consumers can initiate an interaction — push and pull, respectively. • It supports the modeling of demand-driven computation naturally. • It allows a clean design of actors that handle external I/O (e.g. DatagramReader). • The actors perform blocking read/write to access external resources. • By configuring the ports of such actors to be push or pull, the actors can be made blocking/non-blocking w.r.t. the director.

  15. Discussions • The firing condition of a pulled actor is encapsulated in its prefire() method. For the director to truly implement demand-driven computation, it has to analyze the prefire() method to decode the firing condition*. A high-level actor description like CAL can make this task easier. • Priorities may be assigned to pushed data/events and pull requests. The director can schedule their processing by priority. *: Currently the director assumes that the actor require one token at each input.

More Related