Protocolo de Transferencia de Datos Indexados PTDI

Creador: Malison F. Picado

El Protocolo de Transferencia de Datos Indexados (PTDI), es un protocolo que se basa en la lectura y escritura de un conjunto de variables de un sistema, en la cual cada variable está identificada por un índice único.

La definición está dada por: “Un sistema con un conjunto de variables V, tal que: $V=\{V_0, V_1, V_2, …, V_n\}$”. $V$ es un conjunto de variables ordenadas en forma de matriz de N columnas y 1 fila, con N iniciando en valor 0. Cada variable tiene un tipo de dato asignado, que puede variar según el modo de acceso configurado en el servidor.

Cada variable en el conjunto V está asociada a un índice N, lo que permite un acceso directo y eficiente a los datos. Además, cada variable puede estar vinculada a uno o más dispositivos que dependen de estas, lo que facilita la gestión y el control de los elementos del sistema. Esta estructura indexada y modular del PTDI lo convierte en una solución robusta y escalable para la transferencia de datos en aplicaciones IoT.

Cada vez que el valor de una variable es actualizado, el nuevo valor se envía a cada uno de los dispositivos que dependen de esta variable; los clientes reciben las actualizaciones de todas las variables del sistema. Todas las actualizaciones son en tiempo real.

Entidades

Una entidad es cualquier dispositivo que establezca una conexión con el sistema (broker), mantenga o no la conexión, y que realice operaciones de lectura, escritura o modificaciones del conjunto de las variables o en una variable individual. Una entidad puede ser un micro-controlador, un sensor, un servidor web o una aplicación; si está conectado con el broker, entonces es denominado como entidad.

Este protocolo hace distinción entre dos tipos de entidades, las cuales son tratadas por el broker de distinta forma según su tipo. El primer tipo de entidad es denominada como “cliente”, los clientes son todas aquellas conexiones realizadas para obtener o realizar cualquier actualización del conjunto de variables; estos clientes pueden ser aplicaciones web o nativas para el monitoreo de las variables. El segundo tipo de entidad es denominada como “dispositivo”, los dispositivos son todas alquellas conexiones realizadas para realizar únicamente operaciones de lectura y escritura de una determinada cantidad de variables (subconjunto $S$ que pertenece al conjunto de las variables $V$, $S=\{V_a, …, V_x\},S \in V$)

Entonces, un cliente es una conexión que recibirá actualizaciones de cualquier variable y podrá realizar actualizaciones a cualquier variable; un dispositivo es una conexión que recibirá actualizaciones de ciertas variables y enviará actualizaciones a ciertas variables (declaradas en la petición de conexión).

$C=\{C_a, C_b, …, C_x\}$ : $C$ es el conjunto de clientes; $D=\{D_a, D_b, …, D_x\}$ : $D$ es el conjunto de dispositivos;

$$D_n(S_u, S_d)$$ $$S_u=\{V_n, …, V_m\}$$ $$S_d=\{V_i,…,V_j\}$$ $$S_u, S_d \in V$$

$D_n$ es un dispositivo que realiza actualizaciones al subconjunto de variables $S_u$ , y depende (recibe actualizaciones) del subconjunto de variables $S_d$, ; donde $S_u, S_d$ pertenecen al conjunto de variables $V$.

Al subconjunto $S_u$ y $S_d$ se le denominan como parámetro. Estos parámetros son declarados por un dispositivo al realizar una petición de conexión persistente. Según el modo de operación, estos parámetros podrán ser omitidos o procesados de distinta manera.

Usos

PTDI, o Protocolo de Transferencia de Datos Indexados, ofrece un enfoque innovador al manejo de datos en el Internet de las Cosas (IoT), diferenciándose de otros protocolos que se centran únicamente en la transmisión. Su base teórica reside en conjuntos de variables, asignando índices únicos a cada variable que contiene un sistema. Esto permite una lectura y escritura precisa, optimizando la eficiencia en la transferencia de información al solo enviar los datos relevantes según el índice. La clave del protocolo radica en su persistencia: PTDI mantiene un registro de las últimas actualizaciones de una variable, garantizando que incluso con interrupciones en la conexión, la información no se pierda y esté disponible para su uso inmediato, una característica crucial para entornos IoT donde la fiabilidad es primordial.

El potencial de PTDI se extiende a diversas industrias y aplicaciones cotidianas. En el ámbito del hogar inteligente, podría controlar sistemas de iluminación y climatización con precisión, ajustándose a las necesidades en tiempo real. En la industria manufacturera, permite un monitoreo detallado del rendimiento de maquinaria, detectando anomalías y previniendo fallos. Además, su capacidad para mantener datos persistentes lo hace ideal para aplicaciones de monitoreo ambiental, como el seguimiento de la calidad del aire o la gestión de recursos hídricos, donde la integridad de los datos es fundamental.

En esencia, PTDI representa un avance en la forma en que se procesan y utilizan los datos generados por dispositivos IoT. Al combinar la eficiencia en la transmisión con la persistencia de los datos, ofrece una solución robusta y adaptable a una amplia gama de aplicaciones. Su enfoque indexado facilita el control preciso y la toma de decisiones informadas, lo que lo convierte en un protocolo prometedor para el futuro del IoT, especialmente en entornos donde la fiabilidad y la eficiencia son factores críticos.

Modo de Operación

El modo de operación es la forma en que el broker permite a una entidad realizar ciertas operaciones y procesarlas de una determinada manera.Existen tres modos: el modo estricto, el modo normal o por defecto y el modo libre.

Modo Libre

El modo libre permite cualquier conexión sin necesidad de autenticación, permite conexiones de un solo tiempo y conexiones persistentes tanto para dispositivos como para clientes. Además, habilita a cualquier entidad realizar todo tipo de operaciones sin restricción alguna, esto es: lectura y escritura en cualquier variable, declarar solo dependencias y sobreescribir el tipo de dato de una variable.

Modo Normal

El modo normal permite conexiones de un solo tiempo y requiere que las conexiones persistentes se autentiquen para poder realizar operaciones. Las conexiones de dispositivos no tienen permitido cambiar el tipo de dato de una variable (solamente los clientes mediante comando set type).

Modo Estricto

El modo estricto no permite conexiones de un solo tiempo, toda conexión debe de autenticarse y declarar las variables de las que depende y variables a las que actualiza. Si el dispositivo no declara parámetros, se rechaza la conexión; debe de haber al menos un parámetro, ya sea de actualización o de dependencia. Los dispositivos no pueden cambiar el tipo de dato al usar el método UPDATE (solo clientes pueden hacerlo con SET TYPE).

Nota A: El modo normal y el modo libre permiten realizar actualizaciones a cualquier variable, tanto a clientes como a dispositivos, sin ser declaradas como parámetro. El modo estricto, en cuanto a dispositivos, solo permite realizar actualizaciones a aquellas variables que fueron declaradas en los parámetros: $D_n(S_u, S_d)$; si el dispositivo trata de actualizar el valor de una variable que no fué previamente declarada, la actualización será rechazada; solo los clientes podrán actualizar el valor de cualquier variable.

Códigos de Respuesta

Los códigos de respuestas son una representación numérica del estado de una operación. Estos códigos tendrán una longitud de 1 byte e irán por delante del resultado de la petición, indicando su estado.

Codigo para cualquier estado de operación exitosa: 0x00

Tipos de Datos

El Protocolo de Transferencia de Datos (IDTP) establece 11 tipos de datos y establece el tipo de dato por defecto el entero con signo: INT32 (0x07):

Si debido al diseño un sistema, las variables solamente requieren de un tipo de dato distinto de los establecidos por el protocolo, el nuevo tipo de dato se puede anexar a los tipos de datos existentes o sobreescribir los tipos de datos existentes. El código del tipo de dato debe de ser de solamente 4 bits (0x00 - 0x0F, 0 a 15).

Por ejemplo, si el sistema hace uso de algún sistema de posicionamiento global, es posible que se pueda anexar el tipo de dato “Location” (u otro nombre reconocible para el sistema) como 2 flotantes de 64 bits (latitud, longitud); cada variable tendrá 16 bytes de datos, y establece el código del tipo de dato como 0x0B (decimal: 11, binario: 1011). Si todo el sistema se basa en ubicaciones y solo requiere del tipo de dato “Location”, se puede establecer el código del tipo de dato en 0x00 y omitir los demás códigos.

Entonces, el protocolo no fuerza al usuario a utilizar los tipos de datos establecidos, solamente fuerza el tamaño del código de los tipos de datos (los códigos solo pueden tener 4 bits de longitud); el usuario puede anexar tipos de datos o sobreescribir los existentes.

Tipos de Conexiones

Conexión de un Solo Tiempo

La conexión de un solo tiempo indica transferencia de datos de modo petición-respuesta. Esta conexión solo se realiza cuando se requiere de realizar operaciones de lectura/escritura durante intérvalos de tiempos largos y/o cuando un dispositivo no requiere de actualizaciones en tiempo real.

Cuando se establece la conexión con el servidor, el dispositivo conectado debe enviar datos en un intérvalo de 60 segundos, si no se envía datos entre ese lapso de tiempo, el servidor procederá con el cierre de conexión.

Para indicar esta conexión, el primer byte que se envía (el byte más significativo), deberá de ser establecido en 0xFF (en binario: 1111_1111), y posteriormente enviar los bloques de peticiones. Una vez que el broker envía la respuesta, procederá a cerrar la conexión con el dispositivo. Las peticiones solo pueden ser de dos tipos: GET y UPDATE; y el broker debe de estar en configurado en modo de operación normal o modo de operación libre.

Bloques de Petición y de Respuesta

Un bloque de petición está compuesto por una cabecera, un índice y una carga (según el tipo de petición). El dispositivo puede enviar una serie continua de bloques de peticiones y las respuestas se recibirán en el mismo orden de los bloque de petición. Los bloques de respuesta está compuesto por el código de estado de la operación y la carga (según el tipo de petición). Al ser los bloques de un tamaño predecible, es posible determinar la respuesta del bloque, por lo cual, es factible enviar los bloques de respuesta en el mismo orden en el que fueron pedidos. Tal que:

Datos enviados al servidor: $\{Code, Block_0, Block_1, …, Block_N\}$ Respuesta recibida del servidor: $\{RespBlock_0, RespBlock_1, …, RespBlock_N\}$

Los bloques de respuesta siempre mantienen el orden en el que las peticiones fueron enviadas.

Conexión Persistente

La conexión persistente con el servidor es util cuando un dispositivo o cliente requiere de actualizaciones en tiempo real, ya que la conexión con el servidor no se pierde. Para establecer una conexión persistente, el primer byte (el byte más significativo) debe ser establecido en 0x00, posteriormente se declaran la versión del protocolo, el tipo de entidad (cliente o dispositivo), el valor del Keep-Alive, longitud de autenticación, la llave de autenticación y los parámetros del dispositivo (actualizaciones y dependencias); siguiendo el siguiente formato:

Formato: Tipo de entidad

Símbolo “-” representa: reservado.

Código de Tipo de Entidad

Keep Alive

El “keep alive” es un valor que debe ser establecido entre 60 y 3600. Este representa un intérvalo en el tiempo en segundos en el que una conexión deberá enviar datos, si no envía algún tipo de dato dentro del tiempo declarado, el servidor cerrará la conexión. Si el dispositivo/cliente según el diseño no envía datos (operaciones de escritura/lectura u otros), entonces tiene la opción de enviar un solo byte llamado PING, la cual será respondido por el servidor con el mismo código (PING de respuesta).

Auth Length

Auth length representa la longitud de la llave de acceso. Esta llave de acceso es definida por el usuario, el protocolo solo declara que la llave tiene una longitud máxima de 255 bytes. Si este campo es declarado como 0 (longitud 0), se interpretará que no envía una llave de acceso y procederá a procesar los parámetros. Las características de la llave de acceso son definidas por el usuario o broker (según su desarrollador), esta puede ser un código, el nombre de usuario y contraseña, etc.

Auth Key

La llave de autenticación o llave de acceso es una cadena de caracteres utilizada para autenticar la conexión con el servidor. La longitud de esta llave está declarada en Auth Length (previamente definida) y puede estar presente o no en el cuerpo de la solicitud de conexión. La llave de autenticación no tiene un formato definido, esto es definido según el usuario o el servidor.

Parameters

Los parámetros de un dispositivo son aquellos que indican a qué variables el dispositivo actualiza y de qué variables depende. Cada parámetro es un bloque que indica el tipo de parámetro (GET para declarar dependencia, UPDATE para declarar actualización), la longitud del índice, y el índice de la variable. Siguiendo el formato de las cabecera de petición común:

Si el tipo de dispositivo declarado es de tipo cliente, los parámetros son omitidos, ya que los clientes puede hacer escritura a cualquier variable y obtener en tiempo real cualquier actualización de cualquier variable.

Códigos de Gestión

Las gestiones son códigos de un solo byte enviados únicamente por los dispositivos/clientes conectados.

PING

Usado para enviar un byte de dato y demostrar que la conexión sigue activa, útil cuando el dispositivo no ha recibido actualizaciones o no ha enviado en un determinado tiempo no y debe ser desconectado del servidor.

Código: 0x01 Respuesta: 0x00

DISCONNECT

Byte usado para pedir al servidor una deconexión

Código: 0x02 Respuesta: NULL, el servidor desconecta al dispositivo

Métodos

Longitud del Índice de una Variable

El tamaño del índice son 2 bits en la cabecera que indican el tamaño en bytes de la carga del índice (que sigue luego de la cabecera), al valor real en binario se le suma 1 para obtener así el tamaño en bytes (0 bytes no es permitido), tal que:

Este dato que indica la longitud del índice es usado para ahorrar bytes correspondiente a la representación en binario del índice, de tal forma que no se pierda el valor real del índice mientras se compacta su representación en binario. Los índices tiene como valor máximo el valor de $2^{32}-1$ (entero sin signo de 32 bits, 4 bytes), entonces, si el índice es menor a 256 ($N<256$), solo es necesario 1 byte para representar todos los índices menores a 256. Así que, se debe de utilizar $log_2(i)/8$ donde i es el índice y el resultado (que representa la cantidad de bytes para representar ese valor) se establece en el siguiente entero.

El usuario no está obligado a comprimir el tamaño del índice, puede indicar que el índice tiene 4 bytes de longitud y representar el índice 0, tal que: (byte 3) 0x00, (byte 2) 0x00, (byte 1) 0x00, (byte 0) 0x00. Pero, sí el índice que se quiere indicar es mayor a los bytes declarados (ej. índice 456 (2 bytes para representarlo) y 1 byte de longitud declarado), entonces habrá problema de interpretación, ya que el byte menos significativos será tomado como parte del valor de la variable (payload) o como una nueva petición, según el método declarado.

Formato UPDATE STREAM

El UPDATE STREAM es un formato que se utiliza para indicar el estado de una variable. Este bloque se compone por el índice, el tipo de dato y el valor de la variable. Estructurado de la siguiente forma:

El Byte 0 es denominado como la cabecera, esta debe contener el tipo de dato de la variable y el tamaño del índice. El tipo de dato va desde booleano hasta decimal de 64 bits y debe indicarse en base al código asignado, luego de indicar el tipo de dato se declara la longitud del índice de una variable.

Luego del byte 0 (cabecera) le sigue el índice de la variable cuya la longitud en bytes es según lo declarado en la cabecera. Luego de declarar el índice de la variable, se establece el valor de dicha variable. La longitud de este valor coincide con el tipo de dato indicado en la cabecera, según se muestra en la tabla de tipos de datos.

La longitud mínima del bloque de una variable $V_n$ es de 3 bytes, en la siguiente condición: La variable es de tipo booleano (tamaño de dato de 1 byte), el índice es menor a 256 (entre 0 a 255, 1 byte), más el byte correspondiente a la cabecera; 1 byte (cabecera) + 1 byte índice + 1 byte dato. La longitud máxima del bloque de una variable $V_n$ es de 13 bytes: 1 byte de cabecera, 4 bytes de índice y 8 bytes de carga.

El UPDATE STREAM está presente cuando se transmite la actualización del valor de una variable $V_n$, esta transmisión del valor se envía a todos los clientes y a los dispositivos que dependen de la variable $V_n$. Al igual que los métodos GET y UPDATE, el UPDATE STREAM puede ser transmitido en cadena (cuando existen varias actualizaciones a una variable simultaneamente).

Cada envío de bloques de UPDATE STREAM debe de iniciar con el código 0xFF (byte más significativo), similar al usado en operaciones de lectura/escritura para conexiones de un solo tiempo: [0xFF] [UptStr V1] [UptStr V2] ... [UptStr Vn]

Código de Métodos

• Método GET: Método utilizado para obtener el valor de una variable en un índice N

• Método UPDATE: Método utilizado para actualizar el valor de una variable en un índice N

• Método EXPAND: Método utilizado para expandir el conjunto de variables (Expansión de la capacidad de la base de datos en memoria)

• Método SET TYPE: Método utilizado para establecer el tipo de dato de una variable en un índice N. Útil cuando el servidor está en modo estricto; en otros modos, el método update puede sobreescribir este valor, en modo estricto solo está disponible para el método set type.

  NOTA Sobre modo expandido: el modo expandido indica que ahora la cabecera tiene un tamaño de 2 bytes, ya que el modo expandido no solo declara el método GET y UPDATE como lo hace el modo normal, sino que ahora necesita de declarar el método EXPAND y SET TYPE. Este modo expandido solo está disponible para entidades de tipo cliente.

Método GET

Para consultar el valor de una variable en un índice X, en la cabecera se debe de especificar el método GET y la longitud del índice de una variable, luego de la cabecera se indica el índice. El servidor luego deberá responder con un código de estatus más el cuerpo del Update Stream.

Estructura de la petición:

El bit 7 de la cabecera se establece en 0, indicando el método GET.

Estructura de la respuesta:

Modo Expandido

Método UPDATE

Para actualizar el valor de una variable en un índice X, en la cabecera se debe de especificar el método UPDATE, el tipo de dato y la longitud del índice; posteriormente se declara el índice y luego del índice el nuevo valor de la variable. El método update tiene el formato similar a Update Stream, con la diferencia que el bit 7 de la cabecera se establece en 1, que indica el método update.

Estructura de la petición:

El tipo de dato sirve para calcular la longitud de la carga. Según el modos de operación, si el modo es estricto y el tipo de dato declarado en la cabecera no coincide con el tipo de dato de la variable, entonces no se actualizará el valor y responderá con un error. Si el modo de servidor es normal o libre, entonces se actualizará el tipo de dato y el valor de la variable, respondiendo con un código de estado 0x00 (éxito).

La respuesta a esta petición tiene una longitud de 1 byte, e indica el estado de la operación, según los códigos de respuestas.

Método Update, Modo Expandido

Método EXPAND

El método EXPAND indica la adición de nuevas variables al conjunto de variables $V$. Este método debe de llevar un conjunto de tipo de datos, que corresponderá al tipo de dato de la nueva variable. El tamaño de este conjunto debe de corresponder con el tamaño de expansión deseado. Si el tipo de dato declarado no es válido, entonces se establecerá en el tipo de dato por defecto: INT32. Si el servidor no pudo expandir la base de datos, responderá con un código 0x1E por cada variable pedida.

NOTA: El conjunto son un arreglo de N bytes donde cada byte tiene el código correspondiente al tipo de dato de la variable. Este arreglo va luego de la cabecera (que solamente indica el método) y se responderá con un conjunto de bloques de respuesta correspondiente al estatus de cada uno de los tipos de datos enviados. Si el arreglo fue de N tipos de datos, entonces la expansión será de N variables y la respuesta de N bloques.

Bloque de Respuesta:

La respuesta es el estado de la operación más el índice asignado a la variable. Si se produjo un error, entonces el bloque de respuesta solo contendrá el byte correspondiente al status.

Método SET TYPE

El método SET TYPE indica el cambio del tipo de dato de una varible. Este método, al igual que el método expand, solo está disponible para clientes. Al realizar el cambio de tipo de dato, el valor de la variable se establece en 0 (el valor en su representación binaria, todos los bits serán establecidos en cero) y el tamaño del valor se ajusta al nuevo tipo de dato.

Respuesta: 1 byte de respuesta por bloque correspondiente al estado de la operación, 0x00 para operación exitosa, 0x0D para tipo de dato inválido (No se actualiza el tipo de dato), 0x01 para índice inválido; según los códigos de respuesta.

Versión actual del protocolo: Beta 1, código de versión 0xFF