Seizure-prediction algorithm

A continuación voy a extender el modelo dOTM para soportar estos tres requisitos de diseño. Analizando las características de este modelo en relación a los requisitos podemos observar lo siguiente:

Selección de Agent

Cuando se necesita un nuevo OTM en una sesión, el módulo Controller selecciona un Agent en modo round-robin pidiendo la petición de creación de OTM a uno de los Agents disponibles cada vez. Según los requisitos enunciados es necesario soportar la creación de OTMs en Agents concretos basándonos en los algoritmos de decisión. Para habilitar esta funcionalidad hay que introducir una manera de permitir al Controller comunicarse de manera directa con cada Agent.

Registro de Agent

En el modelo actual de dOTMs, el módulo Controller no tiene tiene conocimiento de los Agents existentes en el sistema. Para comunicarse con ellos simplemente envía un mensaje al bus y es éste el que redirecciona el mensaje a uno de los Agents suscritos. Ahora es necesario añadir un mecanismo que provea al Controller de una lista de los Agents disponibles en cada momento. En otras palabras, es necesario que cada Agent se registre en el Controller cuando se añada al conjunto de Agents disponibles.

Reporte de Agent

Para tomar la decisión de qué Agent seleccionar para crear un nuevo OTM, el módulo Controller necesita información sobre los Agents disponibles. Es especialmente interesante tener información acerca del estado de cada Agent en tiempo real. En la configuración actual, una vez que un OTM es creado el controlador le envía los mensajes relacionados con la sesión directamente a él por lo que nunca más se comunica con el Agent. Para soportar el reporte en tiempo real por parte

de los Agents es necesario habilitar un canal de comunicación persistente entre cada agente y el controlador. Server 1 Message Bus Controller Agent 1

agent_1 agent agent_2

Server 2 Agent 2 Agent Controller

Room Controller 1 Room Controller 2 Room Controller 3

Figura 4.4 : Configuración de extensiones de registro y reporte

La Figura 4.4 ilustra las extensiones que propongo añadir al modelo dOTM. En primer lugar y en el bus de mensajes, introduzco una nueva cola para cada uno de los Agents disponibles (Agent id). Estas colas están configuradas en modo unicast directo y las utiliza el controlador para comunicarse directamente con un agente. Cuando un nuevo Agent se añade al sistema crea una nueva cola en el bus para poder recibir mensajes. Por otra parte introduzco el módulo Agent Controller, encargado de mantener el registro de agentes y comunicarse con ellos para obtener los reportes. Además, cuando un RoomController necesite un nuevo OTM, ahora se lo pedirá a Agent Controller y será éste, siguiendo la política de decisión establecida, el que se encargue de su creación en el agente elegido.

Todos los agentes siguen estando suscritos a la cola común (Agent) pero ahora esa cola está configurada para soportar mensajes de tipobroadcast. Agent Controller la utilizará para enviar un mensaje periódico a todos los agentes pidiéndoles su estado. En la respuesta a estos mensajes cada agente incluye información de tres tipos:

4.3. MECANISMO PARA HABILITAR LA PROGRAMACIÓN DE RECURSOS

• Información de contacto: se trata de la información necesaria para contactar con el agente. Básicamente incluye el identificador de la cola de mensajes creada por el agente en el bus.

• Información fija: se trata de información constante configurada por el agente en tiempo de creación (durante el registro).

• Información de tiempo real: es la información sobre el estado del agente en tiempo real. Recibiendo esta información de manera periódica, Agent Controller dispone en todo momento de una lista actualizada con los agentes disponibles en el sistema. Además, cuando se requiere un nuevo OTM para conectar un participante, puede basarse en la información de cada agente (la fija y la de tiempo real) para decidir cuál de ellos utilizar para su creación. Una vez tomada la decisión, envía el mensaje de creación utilizando la cola correspondiente.

La cola común puede seguir utilizándose como antiguamente para crear OTMs en modoround- robinentre los Agents disponibles. Puede ser de utilidad cuando no se quiere especificar ningún tipo de criterio de asignación. En este caso los OTMs se distribuirán de manera homogénea entre los servidores disponibles.

Por último, el mensaje periódico enviado por el controlador a los agentes sirve también como mensaje de heartbeat para asegurar que un agente determinado sigue estando disponible. El controlador dispondrá de una cuenta de mensajes de heartbeat no contestados para determinar cuando un agente no puede seguir considerándose para la asignación de nuevas conexiones.

En la Tabla 4.1, puede observarse la especificación detallada de los mensajes necesarios para habilitar el mecanismo propuesto. Se trata de una extensión de los mensajes originales del modelo que pueden consultarse en [Rodríguez 2016b]. Los mensajescreateOTManddeleteOTM

son los mismos que en dicha especificación original pero en esta extensión añado un nuevo mensajecreateOTM para crear un OTM en un Agent concreto (enviado mediante la colaunicast

correspondiente) y el mensajegetAgents, de tipobroadcast, para obtener el estado de los agentes disponibles. Además, como ya he dicho antes, ahora los mensajes se envían desde el módulo Agent Controller.