Case Study

To evaluate whether CANS provides enough flexibility to support large-scale applications, we conducted a case study involving a shrink-wrapped application: Microsoft MediaPlayer. Our objective was to see whether CANS could be used to improve user experience with the application in a dynamically changing network environment without requiring explicit user participation (see Figure 7). The case study highlights CANS capabilities for (1) automatically selecting and deploying components suited to different network characteristics, driven solely by high-level type specifications at the source and sink, (2) dynamic and distributed event-driven adaptation upon detecting a change in system conditions, and (3) integrating with legacy applications and services. The experimental environment (see Figure 7) consists of the client application run on a laptop with both wireless and wired network interfaces, a desktop capable of hosting services, an intermediate computer capable of hosting an execution environment, and an internet-based server providing media content (in our case, this was the bbc.com server). The case study consists of three stages: the laptop starts off being connected to the network using its wired interface, then is disconnected from the wired LAN, and finally physically moved away from the wireless access point. The transition from wired to wireless LAN is accompanied by a loss in security properties as well as a drop in bandwidth, which becomes worse in the third stage. CANS seamlessly insulates the client application from all network changes, continuing to seamlessly provide the user with the best experience afforded by underlying network characteristics. CANS achieves this behavior by dynamically deploying appropriate components from a predefined set according to the planning algorithm described in Section 4.3. Note that route selection in this case is trivial, the one route involving all of the machines shown in Figure 7. The planning algorithm takes as input four pieces of information: the type definitions, the set of components, links modeled in terms of their link properties, and rules governing how types are affected by links:

• Figure 8 shows the data type definitions. BaseStream is the basic stream type with three boolean link properties, reliable, secure and realtime. RStream, Media, and Encrypted extend the BaseStream type, representing reliable, media, and encrypted streams respectively. Video and Audio are two subtypes of the Media type.

  Figure 8: Hierarchical type definition of case study.

  

• Figure 9 lists the input/output types of six components, whose input/output types are listed in , along with the types produced by the source, bbc.com, and that required by the sink, MediaPlayer. Of the six, the splitter and the padder are Windows Media SDK based services; the first splits a video+audio ASF stream into an audio-only ASF stream available via HTTP, while the second ``fills in'' legal media frames whenever its input stream stops. The other four components are drivers, which cooperate to handle encryption (encryption and decryption) and reliable transmission (reconnecter(src) and reconnecter(dest)) respectively.

  Figure 9: Input and output of case study components.

  

• Table 1 shows the properties of the wired and wireless links and Table 2 shows how these effect different types. In Table 2, ``effect isolation'' refers to a type isolating the effect of a link property for data type instances below it in the type stack.
  

  Table 2: The effects of link properties on data types.

  	properties
  	secure	reliable	realtime
  wired	T	F	F
  wireless	F	T	F

  
  
  
  

  Table 1: The properties of links used in case study.

  	secure		reliable		realtime
  	T	F	T	F	T	F
  Media	--	F	--	F	--	F
  RStream	--	F	T*	T*	--	F
  Encrypted	T*	T*	--	F	--	F
  --: no change *: effect isolation

  
  
  

Figure 7 also shows the deployed components for each of the stages. For Stage 1, whose deployment is triggered when the application issues a connect call to an external streaming service, the plan consists of the padder and reconnecter(dest) running on the laptop, and reconnecter(src) running on the intermediate EE. These components are selected so as to guarantee the real-time and reliability requirements of the type expected at the sink. Not shown are communication adapters required for hooking up the application with the EE, and the EE with the server, bbc.com. Needless to say, MediaPlayer receives a continuous data stream via the CANS components and is able to render it without any problems. Stage 2 starts when we disconnect the laptop from the wired LAN. The padder ensures that MediaPlayer continues to receive legal frames even when no data is coming from the network. The communication adapters running on the laptop and the intermediate host detect the disconnection and reconnect to each other using the wireless interface, with data continuity at the semantic segment level ensured because of the reconnecter(src) and reconnecter(dest) drivers. At this time, because the wireless link has the secure property set to false, encryption and decryption drivers are installed into the data path automatically. Note that this adaptation involves the data path reconfiguration algorithm described in Section 4.2 to flush any in-transit segments. Stage 3 starts when as the laptop is moved away from its access point, bandwidth drops below a threshold. The event detecting this triggers deployment of a new plan, resulting in the instantiation of the splitter component, capable of reducing stream bandwidth requirements. However, splitter supplies data of type Audio, which while compatible with the type specifications, Media, of the client application and other deployed components, requires the application to be placed in a different mode. Achieving the latter requires us to go outside the CANS infrastructure. Currently, we set up an ASX file that forces MediaPlayer to reconnect when the first connection is shutdown. This reconnect request is trapped and used to initiate the new plan. While this works, it also points out the need for a better abstraction of the protocol between applications and the infrastructure. Recent work by Lara et al. [4] of application adaptation relying on component automation interfaces points to what might be a promising direction. Overall, the case study successfully demonstrated all of the important features supported by the CANS infrastructure: dynamic type-based composition and planning, event-driven adaptation that spans multiple drivers, and integration of legacy applications and services.