We discuss the security implications of different techniques used in adaptive audio and video distribution. Several sources of variability in the network make it necessary for applications to adapt. Ideally, each receiver should receive media quality commensurate with the capacity of the path leading to it from each sender. Several different techniques have been proposed to provide such adaptation. We discuss the implications of each technique for confidentiality, authentication, integrity, and anonymity. By coincidence, the techniques with better performance also have better security properties.

Real-time signal processing applications can be described naturally with dataflow graphs. The systems we consider have a mix of real-time and non-real-time processing, where independent dataflow graphs represent tasks and individual dataflow actors are subtasks. Rate-monotonic scheduling is optimal for fixed-priority, preemptive scheduling of periodic tasks. Priority inheritance protocols extend rate-monotonic scheduling theory to include tasks that contend for exclusive access to shared resources. We show that non-preemptive rate-monotonic scheduling can be viewed as preemptive scheduling where the processor is explicitly considered a shared resource. We propose a dynamic, real-time execution model inspired by multithreaded dataflow architectures.

We review a model of computation used in industrial practice in signal processing software environments and experimentally and other contexts. We give this model the name "dataflow process networks," and study its formal properties as well as its utility as a basis for programming language design. Variants of this model are used in commercial visual programming systems such as SPW from the Alta Group of Cadence (formerly Comdisco Systems), COSSAP from Synopsys (formerly Cadis), the DSP Station from Mentor Graphics, and Hypersignal from Hyperception. They are also used in research software such as Khoros from the University of New Mexico and Ptolemy from the University of California at Berkeley, among many others. Dataflow process networks are shown to be a special case of Kahn process networks, a model of computation where a number of concurrent processes communicate through unidirectional FIFO channels, where writes to the channel are nonblocking, and reads are blocking. In dataflow process networks, each process consists of repeated "firings" of a dataflow "actor." An actor defines a (often functional) quantum of computation. By dividing processes into actor firings, the considerable overhead of context switching incurred in most implementations of Kahn process networks is avoided. We relate dataflow process networks to other dataflow models, including those used in dataflow machines, such as static dataflow and the tagged-token model. We also relate dataflow process networks to functional languages such as Haskell, and show that modern language concepts such as higher-order functions and polymorphism can be used effectively in dataflow process networks. A number of programming examples using a visual syntax are given.>

This paper describes the use of Ptolemy to automatically generate code for heterogeneous multiprocessor systems. The framework presented lets the designer migrate from simulation to code generation while developing an application that is specified by constructing a dataflow graph. From primitive send and receive actors, the framework can automatically construct three classes of interprocessor communication (IPC) interfaces. The first type of interface uses a synchronous dataflow (SDF) parallel scheduler to partition and schedule the graph across the available processors. The second type of interface allows hierarchical use of cooperating schedulers within an application. Finally, the third interface uses the send and receive actors as an interface between code generation and simulation systems in Ptolemy. To illustrate the framework, we present an example of a heterogeneous architecture consisting of a workstation with multiple Motorola 56001 processors. We present the relative strengths and weaknesses of each type of interface.>