SISTEMAS DISTRIBUIDOS

TEMA 2: DISEÑO DE PROTOCOLOS CAPA DE APLICACIÓN

1. Conceptos de protocolo
Un protocolo de red es un conjunto de normas, convenciones y procedimientos que gobiernan
las comunicaciones de datos y la forma de compartir los procesos entre diferentes equipos.

Un protocolo bien definido debe contener los siguientes elementos:

 Sintaxis. ¿Cuál es la estructura del mensaje? Define el formato de la información a

enviar. Esta información va a definir la estructura del mensaje, su longitud, campos que
va a tener, etc. El resultado de esta fase debe ser una serie de estructuras a transmitir y
recibir.

 Semántica. ¿Qué significa la información transmitida y cómo interpretarla una vez

recibida? La semántica define el significado de la información recibida y/o enviada. Es
decir, establece que significa cada uno de los campos y los posibles valores que pueden
tomar.

 Temporización. El modelo de temporización expresa la secuencia de mensajes que se

deben recibir y transmitir en función de los mensajes recibidos y enviados con
anterioridad y de la información que queramos transmitir. Por ejemplo, qué mensaje
responde a qué mensaje, etapas de la comunicación, etc.

 Pasos en el diseño de un protocolo

1. Hacer una descripción genérica explicando su funcionalidad.

2. Semántica.
a. Especificación de entidades y su relación.
b. Especificación de protocolos entre entidades.
c. Servicios que requerirá/proveerá cada protocolo.

3. Temporización: describiendo la secuencia de intercambio de mensajes para cada

servicio.

4. Sintaxis: Lista de tipos y formatos de los mensajes intercambiados entre entidades.

1
Ejemplo puesto en clase: Controlar un coche teledirigido a través de un ordenador portátil.

-Entidades. El ordenador portátil (actúa como cliente porque “pide” cosas) y el coche
que actúa como servidor (“hace lo que le pido”).

Aunque principalmente el coche actúe como servidor, habrá momentos en los que el coche haga
peticiones al portátil y se intercambien los roles.

-Servicios (Funcionalidades). Un servicio nos proporciona un estado y nos permite

modificarlo. Por ejemplo, el servicio de arranque nos permitirá ver si el motor del coche está
encendido y encenderlo. Así pues, el coche podría disponer de los siguientes servicios:

-Servicio de arranque (encender el motor)

-Servicio de aparcamiento (si tienes echado el freno de mano o no)
-Luces.
-Parabrisas.
-Cambio de marchas
-Freno
-Acelerador.
-Embrague.
-Volante
-Cámaras
-Gasolina.
-Velocidad.
-Revoluciones.
-Intermitentes.

1.1Sintaxis
En la sintaxis de un protocolo hay que especificar:

-Tipos de mensajes

-Campos de cada tipo de mensajes

-Rango de cada campo

-Tamaño de cada campo

-Tipo de cada campo.

-Campos habituales en un protocolo:

-Tipo de protocolo (versión) Normalmente el primer byte (o los dos primeros) bytes de
un mensaje es un campo que nos dice el tipo de protocolo. Si estamos en una red interna
en la que solo vamos a utilizar nuestro protocolo es mejor dedicar 1 byte a este campo,
si no, es preferible dedicarle 2 bytes.

2
 -Timestamp (de fuente sincronizada). El tiempo de cada computador en el sistema de
cada máquina es relativo, y por eso se hace necesario un campo que permita sincronizar
a los hosts que se comunican.

-Id por mensaje. Es un identificador único en cada sesión que permite identificar
unívocamente un mensaje. Permite, por ejemplo, que si recibimos dos mensajes con el
mismo id podamos descartar uno de ellos.

1. Identifica unívocamente el mensaje porque es único entre entidades y único

en el sistema distribuido.

2. Sirve para identificar el ack

3. Permite evitar duplicados.

-Longitud del payload. Campo de longitud variable que define la longitud de los datos
que continúan este encabezado.

-ID de siguiente cabecera. Se utiliza para indicar al parser (programa que se encargar de
leer el buffer recibido) cómo interpretar los datos que vienen a continuación. Se utiliza
en protocolos dinámicos que están formados por una cabecera fija seguida de
cabeceras/campos opcionales.

-ID del origen del mensaje. Para identificar al origen del mensaje se utiliza un
identificador único universal (UUID), una cadena alfanumérica que está estandarizada
por la RFC 4122 En esta cadena se incluye la IP/puerto del origen del mensaje.

-CRC. La verificación por redundancia cíclica (CRC) es un código de detección de errores

usado frecuentemente para verificar la integridad del mensaje.

Un ejemplo puede ser hacer una suma con todos los bits y poner el resultado en este
campo. En el destino se vuelve a sumar y vemos si el resultado coincide. Si no coincide
se descarta el mensaje. No obstante, la técnica más sencilla es la de paridad, que
consiste en determinar cuántos 1’s hay en el mensaje: si el resultado es par se pone un
1 en el campo CRC, en caso contrario se pone un 0.

-Flags. Son un conjunto de condiciones especiales (verdadero/falso) para el tratamiento

del mensaje. Puede ser a nivel de bit.

-Código. Es un campo que permite saber que tipo de mensaje es para ayudarte a
interpretarlo.

1.2Semántica y Temporización
-La semántica explica la función de cada tipo de mensaje. Para ello, explica la misión de cada
campo, el valor de cada campo, y el significado de cada valor.

-La temporización determina el intercambio de mensajes, y normalmente se representa con un

diagrama de secuencia.

3
  Ejemplo: RFCs TFTP

1.3 Máquinas de estado

Las máquinas de estados son la implementación por excelencia para el reconocimiento de
protocolos. Se definen los estados de cada entidad software y se definen los cambios de estados
debido a:

1. Mensajes enviados.
2. Mensajes recibidos.
3. Cambios internos de la entidad (ej: timeout)

2. Comunicación entre dos entidades software

 Si las entidades software ya existen, necesitan comunicarse debido a una extensión y/o
ampliación de funcionalidad. En este caso, las estructuras de datos ya existen, y lo que se
usa es la serialización de los lenguajes de programación (java, c++, c, etc.)
La serialización (marshalling) es un proceso mediante el cual podemos convertir objetos de
un programa en ejecución en flujos de bytes o en un formato humano más legible (XML o
JSON) capaces de ser almacenados en bases de datos o de ser enviados a través de la red, y
posteriormente ser capaces de reconstruirlos en los equipos donde sea necesario.

Al hablar de “objetos” no nos referimos únicamente al significado que estos tienen en la

POO, sino que en este contexto un objeto es cualquier estructura de datos, función o
método que esté en memoria.

4
 Todos los lenguajes de programación tienen librerías para serializar en diversos formatos:

-Binario. Es el más eficiente, aunque si se hace a mano es propenso a errores. Además,

hay que tener cuidado con el Little indian/ Bing indian.

-Textual. Como HTTP o POP3

-XLM. Se define como “Human Readable” pero es verboso y poco eficiente.

-JSON. También se define como “Human Readable”, es verboso y poco eficiente (pero
más eficiente que XLM).

Importante. Si el objeto que estamos intentando serializar contiene apuntadores a otros

objetos o datos en memoria, el proceso de serialización se complica porque, a pesar de que
enviemos el objeto, es probable que las direcciones a las que hacen referencia los
apuntadores no sean las mismas en los equipos donde se reconstruya, ni siquiera hay
garantía de que hayamos enviado los objetos a los que referenciaban.

 Si las entidades no existen o se desarrollan de forma paralela al protocolo, hay dos

alternativas.
1. Definimos/ Implementamos un nuevo protocolo mediante sockets.

2. Especificamos la sintaxis mediante un lenguaje neutro de especificación y el

3. compilador se encarga de generar la parte de serialización de forma automática.

5
 3. Ejemplo: Alquiler de Bicis
Queremos diseñar un protocolo para un sistema de alquiler de bicis. El sistema cuenta con una
serie de postes que tienen un ordenador dentro, a los que llegan las bicis y se enganchan. En
cada bici tenemos una etiqueta RFID y en cada poster un lector RFID.

 Paso 1. Descripción genérica.

Sistema de alquiler automático de bicis.

1. Interacción del usuario con el móvil (Bluetooh)

2. Asumimos por simplicidad seguridad en las interacciones.
3. Estación que bloquea/desbloquea candados para bloquear/liberar bicicletas (hasta
20 bicis)
4. Bicis con RFID, lector en la infraestructura.
5. Sistema central para autenticación y recopilación de datos de cara a gestionar la
flota.

 Paso 2. Descripción Semántica.

Identificación de Entidades.

1. Teléfono Móvil.
2. Estación de bicis
3. Servicio Central
4. Bici
5. Candado

Relación entre las entidades y protocolos.

1. Teléfono Móvil <-> Estación de bicis (UserP)

2. Estación de bicis <-> Servicio Central (AlquilerP)
3. Estación de bicis <-> Candado (BlockP)
4. Candado <-> Bici (BiciP)

Servicios ofrecidos

 Estación de Bicis: UserP

1. Solicitud de Bici
2. Entrega de Bici

 Móvil de usarios: UserP

1. Medio de pago

6
  Servicio central: AlquilerP
1. Autorización alquiler
2. Notificación alquiler.

 Estación de Bicis: AlquilerP

1. Bicis disponibles.

 Candado: BlockP
1. Bloquear
2. Desbloquear

 Bici: BiciP
1. Identificar Bici

 Paso 3. Temporización

 Paso 4. Posible sintaxis (Incompleta)

7
 4. Protocol buffers de Google
Protocol Buffers es un mecanismo de Google para serializar estructuras de datos
independientes a la plataforma y al lenguaje, que luego podremos compilar al lenguaje que
utilicemos en nuestra aplicación, obteniendo a la vez métodos de lectura y escritura de los
mismos.

 Características

-Diseñado por Google

-Soporte a múltiples lenguajes.

-Compacto, formato binario.

-Fuertemente tipado.

-Esquema evolutivo.

1. Puedes cambiar el esquema.

2. Productores/Consumidores con diferentes versiones continúan funcionando.

-Existen diferentes versiones de protobuf: proto2 y proto3.

 Cómo utilizar Protocol Buffers

Los pasos concretos para usar Protocol Buffers son los siguientes:

1. Especificar la estructura de datos del mensaje del nuevo protocolo en un archivo.proto.

Estos archivos se escriben utilizando un lenguaje de descripción de interfaz que es
propio de Protocol Buffers.

8
 Como se puede observar el lenguaje usado en los archivos .proto es muy sencillo. Solamente
hay que indicar el nombre, el tipo de cada campo (bool, int32, float, double, string) y un
modificador:

-En proto2 cada campo puede llevar un modificador required (obligatorio que
tenga un valor, si no, excepción), optional (si no tiene valor se asigna uno por defecto) o
repeated (puede repetirse cualquier número de veces incluida cero).

-En proto3 solo hay dos modificadores: singular (0 o máximo 1) y repeated.

Además, en Protocol Buffers los campos se etiquetan de manera única con un entero que
después es utilizado en la codificación binaria para identificarlos.

2. Una vez que tenemos preparado el fichero .proto, procedemos a compilarlo para
generar las clases de acceso a los datos. Como resultado, se genera una clase por cada
mensaje que hayamos definido, con una plantilla en cada una de ellas.
protoc -I --python_out=. archivo.proto

En este caso, el compilador protoc generará un modulo de Python llamado

archivo_pb2.py que podremos importar en nuestra aplicación para serializar datos.

3. Importar las clases generadas en el proyecto para empezar a manipular los mensajes.

Algunos de los métodos más comunes son:

- IsInitialized(): comprueba que todos los campos obligatorios estén con un
valor válido.
- __str__ : para obtener una cadena.
- CopyFrom para copiar mensajes.
- Clear() limpia un mensaje
- SerializeToString()
- ParseFromString()

 Versiones
-No se pueden cambiar los números de los campos existentes.

-No se puede añadir o borrar campos requeridos. Hay que tener cuidado con incluir estos
campos con estos modificadores.

-Puedes borrar campos opcionales o repetidos.

-Puedes añadir campos opcionales o repetidos, usando números no usados previamente.