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

Presentación del tema: "Administración de recursos escasos en una aplicación MHP Amaia Goñi Silvia Larrayoz."— Transcripción de la presentación:

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

2 10/04/2005.2 E.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.

3 10/04/2005.3 E.T.S de Ingenieros de Telecomunicación 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.

4 10/04/2005.4 E.T.S de Ingenieros de Telecomunicación 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.

5 10/04/2005.5 E.T.S de Ingenieros de Telecomunicación 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:

6 10/04/2005.6 E.T.S de Ingenieros de Telecomunicación 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.

7 10/04/2005.7 E.T.S de Ingenieros de Telecomunicación ResourceStatusListener statusChanged(ResourceStatusEvent) ResourceStatusEvent recibe ResourceServer addResourceStatusEventListener() removeResourceStatusEventListener() ResourceClient requestRelease(ResourceProxy) release(ResourceProxy) notifyRelease(ResourceProxy) ResourceProxy getClient() escucha El 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

8 10/04/2005.8 E.T.S de Ingenieros de Telecomunicación 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.

9 10/04/2005.9 E.T.S de Ingenieros de Telecomunicación 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:

10 10/04/2005.10 E.T.S de Ingenieros de Telecomunicación 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

11 10/04/2005.11 E.T.S de Ingenieros de Telecomunicación 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.

12 10/04/2005.12 E.T.S de Ingenieros de Telecomunicación 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.

13 10/04/2005.13 E.T.S de Ingenieros de Telecomunicació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.

14 10/04/2005.14 E.T.S de Ingenieros de Telecomunicación 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.

15 10/04/2005.15 E.T.S de Ingenieros de Telecomunicación Acceso a un recurso Resource client Resource proxy Resource server Crea instancia Petición de acceso al recurso Acceso al recurso Validación del Proxy

16 10/04/2005.16 E.T.S de Ingenieros de Telecomunicación 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.

17 10/04/2005.17 E.T.S de Ingenieros de Telecomunicación Liberación de un recurso Resource client Resource proxy Resource server Recurso en uso Invalidación del Proxy Petición finalización del uso del recurso Pérdida acceso recurso

18 10/04/2005.18 E.T.S de Ingenieros de Telecomunicación 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.

19 10/04/2005.19 E.T.S de Ingenieros de Telecomunicación Pérdida de un recurso Resource client Resource proxy Resource server Recurso en uso Invalidación del Proxy Liberar recurso Pérdida acceso recurso La aplicación se niega a liberar el recurso

20 10/04/2005.20 E.T.S de Ingenieros de Telecomunicación 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.

21 10/04/2005.21 E.T.S de Ingenieros de Telecomunicación 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().

22 10/04/2005.22 E.T.S de Ingenieros de Telecomunicación 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.

23 10/04/2005.23 E.T.S de Ingenieros de Telecomunicación Recursos Escasos Los recursos escasos son: Control de gráficos Cambiar de transport stream Acceso canal retorno Interaccionar con el usuario Acceso a módulos CA Acceso a secciones MPEG2

24 10/04/2005.24 E.T.S de Ingenieros de Telecomunicación

25 Ejemplo Canal de retorno

26 10/04/2005.26 E.T.S de Ingenieros de Telecomunicación 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).

27 10/04/2005.27 E.T.S de Ingenieros de Telecomunicación RCInterface Public class RCInterface{ public int getType(); public int getDataRate(); }

28 10/04/2005.28 E.T.S de Ingenieros de Telecomunicación 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

29 10/04/2005.29 E.T.S de Ingenieros de Telecomunicación RCInterfaceManager Sirve para: Obtener acceso a la correcta interface del canal de retorno que la aplicación desea. Administrar el recurso (canal de retorno).

30 10/04/2005.30 E.T.S de Ingenieros de Telecomunicación 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.

31 10/04/2005.31 E.T.S de Ingenieros de Telecomunicación RCInterfaceManager Public class RCInterfaceManager implements 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);

32 10/04/2005.32 E.T.S de Ingenieros de Telecomunicación 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.

33 10/04/2005.33 E.T.S de Ingenieros de Telecomunicación 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.

34 10/04/2005.34 E.T.S de Ingenieros de Telecomunicación ConnectionRCInterface 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.

35 10/04/2005.35 E.T.S de Ingenieros de Telecomunicación ConnectionRCInterface public class ConnectionRCInterface extends RCInterface implements 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;

36 10/04/2005.36 E.T.S de Ingenieros de Telecomunicación ConnectionRCInterface 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); }

37 10/04/2005.37 E.T.S de Ingenieros de Telecomunicación 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(); }

38 10/04/2005.38 E.T.S de Ingenieros de Telecomunicación 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.

39 10/04/2005.39 E.T.S de Ingenieros de Telecomunicación Ejemplo código:Conexión servidor remoto //First,we get a refernce to the RCInterfaceManager RCInterfaceManager 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 interfaces RCInterface[] 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];

40 10/04/2005.40 E.T.S de Ingenieros de Telecomunicación Ejemplo código:Conexión servidor remoto //Now that we´ve got a reference to the interface,we can star to use ti try{ //first, we reserve the connection myInterface.reserve(this,null); }catch (PermisionDeniredException e){ //we can´t reserve the interface so return return; } //Set up the connection parameters; ConnectionParameters myConnectionParameters; myConnectionParameters=new ConnectionParameters (+ 0191,username,password);

41 10/04/2005.41 E.T.S de Ingenieros de Telecomunicación Ejemplo código:Conexión servidor remoto //Them we set the targer to point to our phone number Try{ myInterface.setTarget(myConnectionParameters); } Catch (IncompleteDeneitedException ite){ return; } Catch (PermissionDeneitedException e){ return; } //Now that we´ve done that,we can actually connect Try{ myInterface.connect(); } Catch (IOExcepcion ioe){ return; }

42 10/04/2005.42 E.T.S de Ingenieros de Telecomunicación Ejemplo código:Conexión servidor remoto Catch(PermissionDeniedExcepcion e) { // we can´t reserve the interface,so return Return; } //set the flag that telles us we to disconnect after we are done connectionMade= true; } //do whatever we want to now thar we´ve got a connection If (connectionMade){ //Once we´re done,we disconnect the interface and relase the resource try{ myInterface.disconnect(); } catch(PermisionDeniedException e) { return; } myInterface.release(); }

43 10/04/2005.43 E.T.S de Ingenieros de Telecomunicación Bibliografía Interactive TV Standards (A Guide to MHP,OCAP and Java TV). Steven Morris, Anthony Smith-Chaigneau www.interactivetvweb.org