Administración de recursos escasos en una aplicación MHP Amaia Goñi Silvia Larrayoz.

Administración de recursos escasos en una aplicación MHP

Amaia Goñi

Silvia Larrayoz

10/04/2005 .2E.T.S de Ingenieros de Telecomunicación

Administración de recursos

La administración efectiva de los recursos escasos es muy importante:

De lo contrario no sería posible que:El máximo de aplicaciones se estuviesen

ejecutando al mismo tiempo.Las aplicaciones pudiesen utilizar todas sus

funcionalidades.


Administración de recursos

No es un nuevo problema.La solución que utiliza MHP está definida

en el proceso de estandarización DAVIC.Muchas de las APIs están basadas en la

API de Notificación de Recursos.Contenida en org.davic.resources

package.Informa a la aplicación de cuando otra

aplicación necesita el recurso o cuando el receptor ha revocado el acceso al recurso.


API de Notificación de recursos

Consiste en tres clases principales y no es en sí una completa API sino que otras APIs hacen uso de ella.MHP sigue el modelo exactamente en

muchos casos.OCAP realiza varios cambios.


Introduciendo la API de notificación de recursos

Basado en el modelo de cliente-servidor.DAVIC introduce varios cambios para

asegurar:Seguridad.Elasticidad para tratar las aplicaciones

maliciosas.La API en sí ,consiste en tres elementos

principales:


Introduciendo la API de notificación de recursos

Resource server: Parte de la API que procesa la petición de los recursos.

Resource client: Parte de la aplicación que actualmente utiliza el recurso.

Resource Proxy: Objeto intermedio que provee servicio del recurso y hace cumplir la política de seguridad.


ResourceStatusListenerstatusChanged(ResourceStatusEvent)

ResourceStatusEvent

recibe

ResourceServeraddResourceStatusEventListener()

removeResourceStatusEventListener()

ResourceClientrequestRelease(ResourceProxy)

release(ResourceProxy)

notifyRelease(ResourceProxy)

ResourceProxygetClient()

escuchaEl application manager, llamando a estos métodos, notifica a la aplicación que el recurso al que hace referencia el ResourceProxy necesita ser liberado

Cada API luego añade métodos específicos para el control del recurso

Diagrama de clases


ResourceServer

La clase que implementa el resource server está basada en la interface ResourceServer.

Public interface ResourceServer{

public abstract void addResourceStatusEventListener(ResourceStatusListener listener);

public abstract void removeResourceStatusEventListener(ResourceStatusListener listener);

}

Los métodos que define esta interface permiten a la aplicación registrarse como un listener para los eventos, indicando el cambio del estado del recurso.

La API que hace uso de esta interface proporciona eventos para observar como recursos específicos cambian su estado.


ResourceClient

La clase que implementa el ResourceClient está basada en la interface ResourceClient.

Public interface ResourceClient{

public abstract boolean requestRelease(ResorceProxy proxy,Object requestData);

public abstract void release(ResourceProxy proxy);

public abstract void notifyReleased( ResourceProxy proxy);

}

El receptor middleware hace uso de esta interface para notificar a la aplicación que alguien más necesita el recurso en el receptor.

La interface Resource Client contiene tres métodos:


RequestRelease

requestRelease() es el más educado de los tres métodos.

- Pide a la aplicación que renuncie al recurso de forma que pueda ser usado por alguien más en el receptor.

-Si este método devuelve el valor:

-false: el cliente todavía quiere el recurso

-true: no necesita más el recurso


Release

Release(): es el siguiente nivel en descortesía y ordena a la aplicación que debe dejar el recurso escaso.

El cliente no tiene elección.Cuando el método retorna, el receptor asume

que el recurso está disponible.Se asume que el cliente cooperará.Si no es así y tras un tiempo (periodo

timeout) no obtiene respuesta, el middleware asume que la aplicación ha caído o es maliciosa.


NotifyReleased

Si la aplicación ha caído o es maliciosa:El receptor llama al método

notifyReleased(), el cual informa al cliente de que debe “limpiar” todo, ya que el recurso ya no está a su alcance.

Se trata de una brutal operación por parte del cliente por lo que únicamente es utilizada cuando éste no coopera.

Si no se obtiene respuesta se elimina la aplicación.


ResourceProxy

La clase que implementa esta interface se sitúa entre el cliente y el recurso actual.

Función principal : seguridad Impidiendo que aplicaciones no fiables accedan al

recurso.

Resto de funcionalidades:Proveer a la aplicación un camino sencillo hasta el

recurso.• En caso de que el recurso sea complejo se establecerán

los parámetros en el proxy en vez de cargarlos en cada acceso, ganando tiempo y reduciendo errores.


ResourceProxy

Resto de funcionalidades:Como las instancias las crea el cliente es posible que

la fuente cree diferentes ResourceProxy-s con diferentes parámetros y elegir en cada caso el que más convenga.

El enlace entre el cliente y el recurso es un camino indirecto utilizando como intermediario el ResourceProxy.

• Ampliando la seguridad.• Facilitando el manejo adecuado de las aplicaciones

“maliciosas”.


Acceso a un recurso

Resource client Resource proxy

Resource server

Crea instancia

Petición de acceso al recurso

Acceso al recursoValidación del Proxy


Acceso a un recurso

1) La aplicación crea una instancia al ResourceProxy adecuado y le pasa los parámetros adecuados.

2) ResourceClient llama al método adecuado del ResourceServer y pide el acceso al recurso pasándole como parámetro el objeto ResourceProxy.

3) El ResourceServer llama a un método privado del ResourceProxy para validar al Proxy.

4) Se establece el enlace entre el recurso y el Proxy. 5) La aplicación para hacer uso del recurso llama a

métodos del ResourceProxy. 6) La aplicación nunca tendrá acceso directo al recurso.


Liberación de un recurso


Resource server

Recurso en uso

Invalidación del Proxy

Petición finalizacióndel uso del recurso

Pérdida acceso recurso


Liberación de un recurso

1) ResourceClient llama al método adecuado del ResourceServer para abandonar el recurso, pasando el ResourceProxy como parámetro.

2) ResourceServer invalida el recurso llamando a un método privado del ResourceProxy que puede o no ser el anteriormente usado para validarlo.

3) El ResourceProxy destruye cualquier referencia al recurso, ya que el ResourceServer le ha avisado que no será válido en poco tiempo.

4) El ResourceServer actualiza su tabla interna de estados de los recursos y marca el recurso como libre.


Pérdida de un recurso


Resource server

Recurso en uso

Invalidación del Proxy

Liberar recursoPérdida acceso recurso

La aplicación se niega a liberarel recurso


Pérdida de un recurso

1) El ResourceServer llama al método release() del ResourceClient.

2) El ResourceClient no responde a esta llamada. 3) Tras un periodo de timeout el middleware notifica

al ResourceServer que la llamada no ha sido contestada.

4) El ResourceServer llama a un método del ResourceProxy y le notifica que el enlace dejará de ser válido.

5) El ResourceProxy rompe el enlace. 6) El receptor llama al método NotifyReleased(), para

informar a la aplicación de que en breve no va a tener acceso al recurso.

7) La aplicación pierde el acceso al recurso.


Disputa por la manipulación de recursos

Cuando varias aplicaciones quieren acceder al mismo recurso se siguen unas normas para resolver la situación:1. Permiso: Si una aplicación no tiene permiso para

acceder al recurso, aunque éste esté libre, no puede acceder a él (mayor seguridad).

2. Petición de otras aplicaciones: Se invita a las aplicaciones a abandonar el recurso por orden de prioridad (de menor a mayor prioridad) mediante el método RequestRelease().


Disputa por la manipulación de recursos

El único problema sería si dos aplicaciones de la misma prioridad requieren el acceso al recurso.

En este caso, MHP define que debe hacer el administrador de recursos y que la petición sea denegada o aceptada depende de la elección que haga el “implementador del middleware”.


Recursos Escasos

Los recursos escasos son:Control de gráficosCambiar de transport streamAcceso canal retornoInteraccionar con el usuarioAcceso a módulos CAAcceso a secciones MPEG2


Acceso Bajo Nivel MPEG-2

Media Control

Application Lifecycle

Gráficos

Comunicación

Cambiar de Transport stream

Control de V/A

Intercambiar datos entre Xlets

Interaccionar con usuario

Control de Gráficos

Acceso AIT comunicar APP

Sincronizar Aplicaciones y

Media

Cambio de

servicio

Dentro de un

servicio

Acceso a ficheros

Almacenado Permanentemente

Ficheros de Broadcast

Acceso canal Retorno

Acceso a Tablas de SI

Acceso a Secciones MPEG2

Recursos escasos en receptor

Acceso a módulos CA

Ejemplo

Canal de retorno


Ejemplo: Canal de retorno

La API del manejo del canal de retorno se define en el paquete org.dvb.net.rc.

Contiene tres clases principales:RCInterface: Representa una interface del canal de

retorno.ConnectionRCInterface: Subclase de RCInterface y

representa una interface del canal de retorno que no tiene conexión permanente.

ConnectionParameters: Define los parámetros más importantes que se necesitan para establecer una conexión (número de teléfono, nombre de usuario y password).


RCInterface

Public class RCInterface{public int getType();

public int getDataRate();

}


Acceso a la interface del canal de retorno

Como el receptor puede soportar más de una interface de canal de retorno, se necesita alguna forma de tener un acceso correcto para nuestra aplicación.

La clase RCInterfaceManager


RCInterfaceManager

Sirve para:

Obtener acceso a la correcta interface del canal de retorno que la aplicación desea.

Administrar el recurso (canal de retorno).


RCInterfaceManager

Las aplicaciones pueden obtener una referencia a él mediante el método getInstance().

Una vez que la aplicación tiene referencia a RCInterfaceManager, puede obtener una interface al canal de retorno apropiado mediante getInterfaces() (nos devuelve las referencias de todas las interfaces de canales de retorno de las cuales la aplicación puede hacer uso).

Implementa el ResourceServer.


RCInterfaceManager

Public class RCInterfaceManagerimplements org.davic.resources.ResourceServer{public static RCInterfaceManager getInstance();public RCInterface [] getInterfaces();public RCInterface getInterface(

Java.net.InetAddress addr);public RCInterface getInterface(

java.net.Socket s);public RCInterface getInterface(

java.net.URLConnection u);public void addResourceStatusEventListener(

org.davic.resources.ResourceStatusListener listener);public void removeResourceStatusEventListener(

org.davic.resources.ResourceStatusListener listener);


Conexión con el canal de retorno

La clase ConnectionRCInterface:Extiende de RCInterface.Sirve para las interfaces de canal de retorno

que deben conectarse antes de su uso (no hay conexión permanente).

Incluye varios métodos para conectarse o desconectarse a un proveedor de servicio y para reservar acceso con el módem.


ConnectionRCInterface

Implementa el ResourceProxy.Reserve(): reserva de interface que otras

aplicaciones no podrán hacer uso de ella.SetTarget(): Muchos módems que no tienen

conexión permanente necesitan conectarse con un proveedor de servicio antes de que las aplicaciones puedan utilizarlo.

Cada tarjeta es definida con ciertos parámetros. Éstos son encapsulados en la clase: ConnectionParameters.



Una vez definida la tarjeta para la interface, podemos conectarnos con el proveedor de servicio.

Connect(): Hace una conexión con la tarjeta específica para esa interface.

Disconnect(): Desconecta la interface, cuando hemos acabado la comunicación.

Release(): Permite a otras aplicaciones hacer uso de la interface.



public class ConnectionRCInterfaceextends RCInterfaceimplements org.davic.resources.ResourceProxy{public boolean isConnected();public float getSetupTimeEstimate();public void reserve(

org.davis.resources.ResourceClient c,java.lang.Object requestData)

throws PermissionDeniedException;public void release();public void connect()

throws java.io.IOException,PermissionDeniedException;public void disconnect()

throws PermissionDeniedException;public void ConnectionParameters getCurrentTarget()

throws IncompleteTargetException;



public void setTarget(ConnectionParameters target)

throws IncompleteTargetException,

PermisionDeniedException;

public void setTargetToDefault()

throws PermissionDeniedException;

public int getConnectedTime();

public org.davic.resources.ResourceClient getClient();

public void addConnectionListener(

ConnectionListener 1);

public void removeConnectionListener(

ConnectionListener 1);

}


ConnectionParameters

public class ConnectionParameters {

public ConnectionParameters(

java.lang.String number,

java.lang.String username,

java.lang.String password);

public ConnectionParameters(

java.lang.String number,

java.lang.String username,

java.lang.String password,

java.net.InetAddress[] dns);

public java.lang.String getTarget();

public java.lang.String getUsername();

Public java.lang.String getPassword();

Public java.net.InetAddress[] getDNSServer();

}


Diferencias con la API de notificación de recursos

RCInterfaceManager actúa como Resource Server. Se deben utilizar objetos ConnectionRCinterface para

reservar o liberar una interface. Las aplicaciones no pueden crear nuevas resource proxy-s.

Las resources proxy-s están implementadas por la clase ConnectionRCInterface.

Las instancias sólo pueden ser creadas por el middleware. Esto permite al middleware devolvernos la interface

apropiada del canal de retorno para una aplicación dada.


Ejemplo código:Conexión servidor remoto

//First,we get a refernce to the RCInterfaceManagerRCInterfaceManager rcm=RCInterfaceManager.getInstance();Boolean connectionMade = false;// Now,we get the list of return channel interfaces that are available to our

applications .This returns all the available interfacesRCInterface[] interfaces=rcm.getInterfaces();//Now choose which interface we use.Since we get all the interfaces,we

need to check that we get the right type.So we check if it was not,wecould do the same thing using another interface,but in this example we won´t fot the sake of simplicity.

If(interfaces[0] instanceof ConectionRCInterface){//If it is a ConnectionRCInterface,it´s not permanently connected,so we need to connect it first

ConnectionRCInterface myInterface;myInterface=(ConectionRCInterface) interfaces[0];



//Now that we´ve got a reference to the interface ,we can star to use titry{//first , we reserve the connection myInterface.reserve(this,null);}catch (PermisionDeniredException e){

//we can´t reserve the interface so returnreturn;

}//Set up the connection parameters;ConnectionParameters myConnectionParameters;myConnectionParameters=new ConnectionParameters(“+ 0191”,”username”,”password”);



//Them we set the targer to point to our phone numberTry{

myInterface.setTarget(myConnectionParameters);}Catch (IncompleteDeneitedException ite){

return;}Catch (PermissionDeneitedException e){

return;}//Now that we´ve done that,we can actually connectTry{

myInterface.connect();}Catch (IOExcepcion ioe){

return;}



Catch(PermissionDeniedExcepcion e) {// we can´t reserve the interface,so return

Return;}

//set the flag that telles us we to disconnect after we are doneconnectionMade= true;

}//do whatever we want to now thar we´ve got a connectionIf (connectionMade){//Once we´re done,we disconnect the interface and relase the resource

try{myInterface.disconnect();

}catch(PermisionDeniedException e) {

return;}

myInterface.release();}


Bibliografía

Interactive TV Standards (A Guide to MHP,OCAP and Java TV). Steven Morris, Anthony Smith-Chaigneau

www.interactivetvweb.org

Administración de recursos escasos en una aplicación MHP Amaia Goñi Silvia Larrayoz.

Documents

Transcript of Administración de recursos escasos en una aplicación MHP Amaia Goñi Silvia Larrayoz.