A.2. Intercambio de mensajes
A continuación, se describe el intercambio básico de mensajes entre cliente y servidor. Se nombrarán tipos de mensaje que en el siguiente apartado se describirán y de los que ahora solamente necesitamos la idea general.
El cliente comienza mandando el mensaje de 'Login', al que la matriz le responde con otro mensaje 'rLogin' que nos indicará si nos ha concedido el acceso o no. También nos indicará los eventos activos enviándonos la confirmación del evento activado marcado por un 'OutputChannelOn'. En el caso de querer indicarnos un determinado parámetro como el volumen o la velocidad de algún elemento de la matriz, lo hará con el tipo de mensaje 'LevelValueSet'.
Veamos el siguiente ejemplo:
En este ejemplo, la matriz nos podría estar informando que está elegida la entrada uno y la cámara del laboratorio de redes mediante los dos 'InputChannelOn' . Los 'LevelValueSet' podrían indicarnos la velocidad actual de la cámara elegida y un volumen de una de las entradas de audio. Los 'CommandSend' siguen siendo una incógnita y no se ha descubierto su utilidad.
Al enviar la petición de comienzo de un evento 'InputChannelOn', la matriz nos debe confirmar que el evento ha sido activado con un 'OutputChannelOn'.
Pero al enviar la petición de fin de un evento, nos podemos encontrar con dos casos dependiendo del tipo de evento. Estos dos casos son:
El caso análogo al anterior, es aquel en el que al enviar la petición de fin, la matriz nos responde con el 'OutputChannelOff' confirmando la desactivación del evento.
Este caso, lo encontramos por ejemplo en los desplazamientos de las cámaras o en los cambios del volumen de las entradas de audio.
El caso peculiar, es aquel en el que la matriz al recibir la petición de fin no responde nada. Aunque parezca extraño, no lo es; si quisiéramos desactivar ese evento deberíamos enviar otra petición de comienzo del evento, sería éste el momento en el que la matriz nos respondería con la desactivación del evento 'OutputChannelOff'. Como siempre, al finalizar debemos mandar la petición de fin de evento y nuevamente no obtendríamos respuesta.
Para el ejemplo usaremos el evento que activa la selección de vídeo en el redireccionamiento de las entradas y salidas.
Además de éste, otros ejemplos de este caso son las entradas, salidas y el audio. Para el caso de la selección de cámaras, la única diferencia es que la única manera de desactivar una, es activar otra.
Encontramos otro caso especial en los eventos que se encargan del control de la velocidad de la matriz y de los volúmenes de las entradas de audio.
Al enviar la petición de comienzo del evento, la matriz nos confirma su activación y a continuación nos envía un mensaje del tipo 'LevelValueSet' indicando el nivel al que pertenece y el valor que tiene.
La gran diferencia estriba en que si no enviamos la orden que finalice ese evento, la matriz seguirá modificando el valor de ese nivel y nos seguirá enviando mensajes del tipo 'LevelValueSet' indicando el nuevo valor.
Veamos un ejemplo:
Imaginemos que el evento lanzado es el de subir volumen de una determinada entrada de audio. La matriz después de confirmarnos la activación del evento, nos irá informando en cada 'LevelValueSet' del valor del volumen, que en este caso se irá incremementando.
En el momento que nosotros enviemos el evento que marque el fin de subir volumen, la matriz dejará de subir el volumen y como consecuencia también dejará de enviarnos los mensajes 'LevelValueSet', acabando con el envío de la confirmación del fin de evento 'OutputChannelOff'.
Debemos tener en cuenta que la matriz guarda cierta información que no nos es visible en todo momento, pero lo será cuando la necesitemos. Se debe observar la similitud entre este caso y el del 'Login', puesto que en ambos hay un momento en el que la matriz nos indicará los eventos que están activados. Ejemplos claros de ésto son los cambios de cámara y de las entradas de la matriz.
Para seleccionar una cámara lanzaremos la activación y desactivación de su evento correspondiente (como en el caso del vídeo fig. A-3). La matriz nos enviará la confirmación de la desactivación de la anterior cámara elegida y la confirmación de activación del evento que representa la cámara actual (no necesariamente en este orden). Si la cámara elegida tuviera eventos activados, éstos nos serán revelados por medio de los 'OutputChannelOn' que vendrán inmediatamente después. Pero aún puede llegarnos mas información, ésta será de la velocidad mediante los mensajes 'LevelValueSet'.
Muy parecido es el caso en el que cambiamos la entrada de la matriz, puesto que al cambiar a otra , ésta puede tener o no activadas una o varias salidas. Ésto nos sería notificado mediante confirmaciones de eventos activados 'OutputChannelOn' por parte de la matriz.
Si una vez conectados a la matriz, ésta no recibe ninguna petición, comenzará a enviarnos mensajes que confirmen nuestra presencia ("are u alive?"). Estos mensajes son del tipo 'GetMessages' y deben ser respondidos con un 'rGetMessages' por parte del cliente.
De igual manera, el cliente puede pedir confirmación a la matriz de su presencia al otro extremo de la conexión. Se producirá el mismo intercambio de mensajes con la única diferencia de que la matriz responde a nuestro 'GetMessages' con un 'rGetMessages' con igual número identificador del mensaje (ver etiqueta <msgID> en cualquier mensaje).
Para la aplicación desarrollada en este proyecto, se ha optado por una petición de confirmación del cliente por cada tres de la matriz.
Es muy importante, destacar que una vez recibido un 'GetMessages' ningún mensaje debe interponerse entre él y su respuesta 'rGetMessages'; si ésto pasara, la matriz en el momento de no recibir ningún evento, dará por cerrada la conexión.
Para la las cuatro posiciones de las que disponemos para cada cámara, el protocolo nos ofrece la posibilidad de grabarlas en la posición y enfoque que nosotros deseemos.
Hay que destacar, que el evento que se usará para grabar una posición, será el mismo que se usará para acceder a él. La mejor manera de explicarlo es ver la diferencias entre ambos:
Para acceder a una posición guardada enviaremos el comienzo del evento de esa posición y el fin del evento de esa posición; recibiendo en cada momento la confirmación de la matriz como ya vimos en el caso de los desplazamientos de la cámara.
Para la grabación de una posición, mandaremos las activación del evento, pero a diferencia del anterior caso, no enviaremos el evento de desactivación de ese evento hasta que la matriz nos haya enviado curiosamente la confirmación de que ese evento ha sido desactivado.
Aunque se pudiera pensar que es inútil enviar el último mensaje con la petición de desactivación; si no lo hacemos, la próxima vez que pidamos la activación de ese evento, no obtendremos respuesta alguna.
Existe un tipo de mensaje del que se desconoce su utilidad, este tipo es CommandSend. Después de que la matriz haya aceptado el login lanzado por nuestra aplicación, dos mensajes de este tipo nos llegan. Lo realmente curioso es que ambos contienen un campo <Data> que siempre nos trae el mismo contenido: 4C45564F4E en el primero y 52584F4E en el segundo.
