roUPnPController
6 min
este objeto establece y mantiene un upnp control point debe existir durante toda la duración de las operaciones de descubrimiento de upnp consulte el documento arquitectura de dispositivos upnp http //www upnp org/specs/arch/upnp arch devicearchitecture v1 0 pdf para obtener más información sobre los protocolos de descubrimiento de upnp creación del objeto el objeto roupnpcontroller se crea sin ningún parámetro createobject("roupnpcontroller") ifupnpcontroller setdebug(debugo como booleano) como vacío habilita la depuración detallada en el motor upnp search(searchtarget as string, mx as integer) as boolean emite una solicitud search para un dispositivo upnp los parámetros corresponden a los valores de encabezado st (search target) y mx (maximum wait time) que se envían con un comando upnp m search las respuestas a la solicitud search generarán mensajes en forma de objetos roupnpsearchevent el valor más común para el parámetro searchtarget es "upnp\ rootdevice" esto le permite buscar todos los dispositivos raíz, identificar con qué dispositivos desea interactuar y luego obtener las instancias de roupnpdevice y upnpservice para estos dispositivos y servicios integrados removedevice(udn as string) as boolean fuerza la eliminación del dispositivo especificado de la lista de dispositivos del control point la cadena proporcionada debe incluir " uuid " antepuesto al valor udn ifmessageport especifica el puerto que recibirá los eventos generados por la instancia roupnpcontroller ifuserdata setuserdata(user data as object) establece los datos de usuario que se devolverán cuando se generen eventos getuserdata() as object devuelve los datos de usuario que se establecieron previamente mediante setuserdata() devolverá inválido si no se han establecido datos operación del upnp controller el objeto roupnpcontroller mantiene una lista de todos los dispositivos upnp detectados actualmente a los que se puede acceder mediante la red local para mantener esta lista, el objeto roupnpcontroller sigue estas prácticas de control point generalmente aceptadas si se recibe una notificación multicast ssdp\ alive de un dispositivo que no forma parte de la lista, se consulta su información de dispositivo y se agrega a la lista sin embargo, el mensaje ssdp\ alive no está pensado como el medio principal para el descubrimiento de dispositivos; más bien, este comportamiento está destinado a mantener la lista actualizada y eliminar dispositivos que desaparecen sin una notificación ssdp\ byebye si se recibe una notificación multicast ssdp\ byebye de un dispositivo que forma parte de la lista, se eliminará de la lista el upnp controller permite que un cliente emita una solicitud search para dispositivos upnp se espera que todos los dispositivos de la red respondan directamente al dispositivo solicitante si se recibe una respuesta de un dispositivo que no forma parte de la lista, se consulta su información de dispositivo y se agrega a la lista los dispositivos upnp informan un "time to live" para las notificaciones para los mensajes upnp notify y search response, esto está contenido en el encabezado "cache control max age" normalmente, este "time to live" es de 20 o 30 minutos, aunque algunos dispositivos tienen valores de tiempo mucho más cortos cada dispositivo está configurado para expirar después de que se alcance su "time to live", momento en el cual se elimina de la lista de dispositivos el contador se restablece (es decir, el dispositivo se renueva) después de cada recepción de un mensaje ssdp\ alive brightscript no permite acceso directo a su devicelist interna en su lugar, genera eventos en forma de objetos roupnpsearchevent cuando se agregan o eliminan dispositivos de la lista estos objetos pueden, a su vez, utilizarse para recuperar objetos roupnpdevice que contienen toda la información del dispositivo el controlador también genera eventos cada vez que recibe un mensaje multicast notify o una respuesta a un mensaje m search (es decir, una respuesta a una solicitud de búsqueda del controlador) estos eventos devuelven matrices asociativas que contienen encabezados del mensaje multicast notify o de la respuesta http al mensaje m search las matrices asociativas también pueden contener elementos adicionales que no son encabezados para una notificación de mensaje multicast ssdp (tipo 0), la matriz asociativa contendrá una clave "ssdptype", cuyo valor designa si se trata de un mensaje notify o m search en la mayoría de los casos, es mejor ignorar los mensajes m search, a menos que esté implementando un dispositivo upnp (el objeto controlador upnp permite esto) durante una solicitud m search, una notificación de "nuevo dispositivo" (tipo 2) solo se enviará cuando se agregue un dispositivo a la lista interna del controlador una vez que un dispositivo forma parte de la lista de dispositivos, las solicitudes m search posteriores solo devolverán valores de tipo 1 (respuesta de búsqueda) para ese dispositivo esta respuesta de tipo 1 devuelve una matriz asociativa con encabezados de mensaje, pero no un objeto roupnpdevice (que se utiliza para contener un conjunto completo de información del dispositivo) consulte la página roupnpsearchevent para obtener más información sobre los mensajes enviados por el upnp controller