Protocolos y Servicios InformáticosNOMBRE: JUAN ANTONIO MARTÍNEZ.

INGENIERÍA EN TELEMÁTICA

Concepto de protocolo

En informática y telecomunicación, un protocolo de comunicaciones es un

conjunto de reglas y normas que permiten que dos o más entidades de un

sistema de comunicación se comuniquen entre ellos para transmitir

información por medio de cualquier tipo de variación de una magnitud física.

Se trata de las reglas o el estándar que define la sintaxis, semántica y

sincronización de la comunicación, así como posibles métodos de

recuperación de errores. Los protocolos pueden ser implementados por

hardware, software, o una combinación de ambos.

UN EJEMPLO:

La trasferencia de archivos entre dos entre dos computadoras. En este caso de haber un camino entre estas dos, directo o a través de una red de comunicación, pero además, se requiere realizar las siguientes tareas adicionales.

1- El sistema fuente de información debe activar un camino directo de datos o bien debe de proporcionar a la red la identificación del sistema destino deseado.

2- El sistema fuente debe de asegurase de que el destino sea preparado para recibir datos.

3- La aplicación de trasferencia de archivos en el origen debe asegurase de que el programa gestor en el destino esta preparado para para aceptar y almacenar el archivo para un uso determinado.

4- Si los formatos de los dos archivos son incompatibles uno de los dos hacer el proceso de traducción.

Es evidente que para que haya comunicación se necesitan dos entidades por lo que debe existir el mismo conjunto de funciones en capas en los dos sistemas. La comunicación se consigue haciendo que las capas correspondiente intercambien información. Las capas se comunican intercambiando bloques de datos que verifican una serie de reglas o convenciones llamadas protocolos. Los aspectos que defines a un protocolo son las siguientes:

1- La sintaxis. Establece cuestiones relacionadas con el formato de los bloques de datos.

2- La semántica. Incluye información de control para coordinación y gestión de errores.

3-Temporización . Considera aspectos relativos a la sincronización de velocidades y secuenciación.

Función de los protocolos

• Es necesario dividir los bloques de datos en unidades pequeñas e iguales en tamaño, y este proceso se le llama segmentación.

• El bloque básico de segmento en una cierta capa de un protocolo se le llama PDU (Unidad de datos de protocolo). La necesidad de la utilización de bloque es por:

• 1- La red sólo admite la transmisión de bloques de un cierto tamaño.• 2- El control de errores es más eficiente para bloques pequeños.

Segmentación y ensamblado

• se trata del proceso de adherir información de control al segmento de datos. Esta información de control es el direccionamiento del emisor/receptor, código de detección de errores y control de protocolo

Encapsulado

• Hay bloques de datos sólo de control y otros de datos y control. Cuando se utilizan datagramas, todos los bloques incluyen control y datos ya que cada PDU se trata como independiente. En circuitos virtuales hay bloques de control que son los encargados de establecer la conexión del circuito virtual.

Control de conexión

• El envío de PDU puede acarrear el problema de que si hay varios caminos posibles, lleguen al receptor PDU desordenados o repetidos, por lo que el receptor debe de tener un mecanismo para reordenar los PDU.

Entrega ordenada

• Hay controles de flujo de parada y espera o de ventana deslizante. El control de flujo es necesario en varios protocolos o capas, ya que el problema de saturación del receptor se puede producir en cualquier capa del protocolo.

Control de flujo

• Generalmente se utiliza un temporizador para retransmitir una trama una vez que no se ha recibido confirmación después de expirar el tiempo del temporizador. Cada capa de protocolo debe de tener su propio control de errores.

Control de errores

• cada estación o dispositivo intermedio de almacenamiento debe tener una dirección única, cada una de ellas asociada a un puerto. Además de estas direcciones globales, cada estación o terminal de una subred debe de tener una dirección de subred (generalmente en el nivel MAC).

Direccionamiento

• es posible multiplexar las conexiones de una capa hacia otra, es decir que de una única conexión de una capa superior, se pueden establecer varias conexiones en una capa inferior (y al revés).

Multiplexación

•Prioridad: Hay mensajes (los de control) que deben tener prioridad respecto a otros.

•Grado de servicio: hay datos que deben de retardarse y otros acelerarse (vídeo).•Seguridad .Servicios de transmisión

Elementos de un Protocolo 1- ESPECIFICACIÓN DEL SERVICIO

El protocolo se define para transferencias full-duplex, es decir, debería permitir transferir en ambas direcciones simultáneamente. Los acuses de recibo positivos y negativos para el tráfico desde A hasta B se envían por el canal desde B hasta A y viceversa

2- SUPOSICIONES DEL ENTORNO

- Dos usuarios como mínimo + un canal de transmisión.

- Los usuarios envían una solicitud de transferencia de fichero y esperan a que finalice.

- Canal con distorsiones aleatorias, pero no se pierden, duplican, insertan o desordenan mensajes.

- Se pueden producir errores aleatorios.

3- VOCABULARIO DEL PROTOCOLO

- ack= mensaje + acuse de recibo positivo.

- nack= mensaje + acuse de recibo negativo.

- err= mensaje con distorsión.

Formato del mensaje:

- Mensaje={etiqueta de control, dato}

enumcontrol {ack,nack,err};

struct message{

enumcontrol etiqueta;

unsigned chardato; };

4- REGLAS DE PROCEDIMIENTO

5- DEFECTOS DE DISEÑO

-No se puede transmitir en ambas direcciones simultáneamente

-No se ha definido procedimientos de inicio y finalización ¿err?

-Se aceptan todos los mensajes recibidos correctamente, incluyendo los duplicados

-Si se aceptan los que llegan OK y no se aceptan los mensajes de err duplicación de mensajes cuando se producen dos errores consecutivos

Reglas en el diseño de un protocolo

1. Asegurarse de definir bien todos los aspectos del protocolo

2. Definir el servicio a realizar por cada nivel antes de elegir estructuras

3. Diseñar antes funcionalidad externa que la interna

4. Mantener el diseño simple

5. No conectar lo que es independiente

6. Obviar aquello que es innecesario

7. Validar el diseño antes de implementarlo

8. Implementar diseño, medir su rendimiento y optimizarlo

9. Comprobar que la versión final cumple los criterios de diseño

10. Nunca saltarse las 7 primeras reglas

Control de secuencia y control de errores

1- REDUNDANCIA

- Añadir información redundante a los mensajes

- Dos formas de gestionar los errores:

1- Control de errores hacia delante -> códigos correctores

2- Control de errores por realimentación -> códigos detectores

- Si p↓ -> no código corrector (ralentiza las comunicaciones) Si p↑ -> no código detector (las reTx también podrían ser erróneas).

- También depende del coste: si p↓ y coste de reTx↑ -> código corrector.

- Sistema mixto: el receptor corrige los errores más frecuentes y solicita reTx de los mensajes alterados por errores menos frecuentes.

2- TIPOS DE CÓDIGOS

- Códigos de bloque: palabras de código de misma longitud y codificación estática.

- Códigos de convolución: palabras de código dependen del mensaje actual y de anteriores, el codificador cambia su estado con cada mensaje procesado, longitud de palabras suele ser constante.

Se pueden clasificar en:

Códigos lineales: combinación lineal de palabras válidas.

Códigos cíclicos: rotación cíclica de código válido.

Códigos sistemáticos: mensaje original + bits de comprobación.

3- CORRECCIÓN DE ERRORES

- Los códigos se eligen de forma que haya varios bits de diferencia entre dos palabras válidas.

- Rxor reconstruye mensaje, asociándole la palabra de código más cercana.

- Razón de código de sistema corrector < razón de código de sistema detector

- Se usa sistema corrector si hay:

1- un retraso de transmisión alto

2- ausencia de canal de retorno

3- una tasa de errores alta

Código corrector basado en paridad:

LRC= Longitudinal Redundancy Check

VRC= Vertical Redundancy Check

d=28 bits

e=12 bits

Razón de código=28/(28+12)=0.7

Control de flujo

Objetivos: 1. Asegurarse que no se transmiten los datos más

rápido de lo que se puede procesar.

2. Optimizar el uso del canal.

3. Evitar saturar el canal.

4. Proteger la transmisión contra borrado, inserción, duplicación y reordenamiento de mensajes.

PROTOCOLO SIMPLE SIN CONTROL DE FLUJO

– OK si Rxor más rápido que Txor - > se viola el principio “no hacer suposiciones de la velocidad relativa de procesos concurrentes” .

– Rx es más costoso que Tx.

PROTOCOLO Xon-Xoff

– No requiere negociación previa

– Dúplex

– Si se pierde Xon - > bloqueo de los cuatro procesos

– No se protege contra la saturación de forma efectiva

– No se protege contra la pérdida de mensajes

PROTOCOLO DE PARADA Y ESPERA

– Desaparece problema de saturación en Rxor

– Si se pierde un mensaje, se bloquea

– Se desaprovecha el canal

– Retraso de (2· t +a-p) por cada mensaje enviado

t: tiempo de propagación

a: tiempo que tarda el receptor en aceptar el mensaje

p: tiempo que tarda el emisor en prepararlo

PROTOCOLO DE PARADA Y ESPERA CON TIMEOUT

– Protege contra la pérdida de tramas

– Si tanto Txor como Rxor pueden iniciar reTx, pueden perderse ambas y asociar equivocadamente cada mensaje con otro ack

– Una solución: numerar mensajes y ack’s

PROTOCOLO DE BIT ALTERNANTE

– Timeout + nº de secuencia de 1bit

– Puede fallar si se produce un retraso demasiado grande en el envío del ack desde el Rxor

End