PDF de programación - Principios de Protocolos

Principios de Protocolos

Prof. Wílmer Pereira

Modelo de Capas Imperante

Protocolo transporte

  Interfaz
Transporte
    Red

Aplicación
Transporte
Red
Enlace
Física

Medio Físico

Protocolo

Servicio

  Comunicación horizontal

  Comunicación vertical

Ejemplo de un Modelo por Capas

Filósofo 

Venezolano

Me gustan
los conejos

J’aime les
lapins

Traductor 
Holandés

Ik hou van
Konijnen

Ik hou van
Konijnen

Filósofo 
Francés

Amigo 
Holandés

Teléfono

Protocolo
telefónico

Protocolo
telefónico

Teléfono

Arquitectura de la Red

Emisor

Receptor

Ensamblado
      de 
  paquetes

Segmento

Paquete

Trama

   Secuencias de bits

Desensamblado
          de 
      paquetes

Flujo en la Red

Emisor

Conmutadores

Receptor

Subred

Capa Física

Transmisión de bits sobre el canal de comunicación

Diseño estrechamente ligado al medio de comunicación.

Par Trenzado
Cable Coaxial
Fibra Óptica
Inalámbrico
Microondas
Satélite
Infrarojo ...

Transmisión Analógica o Digital

Red de Integración de Servicios

Capa Enlace

Presentar información libre de errores a
la capa Red
Duplicados
Dañados
Perdidas

Control de Flujo (Receptor más lento que
emisor)

Capa Red

Enrutar paquetes entre emisor y
receptor

Control de Tráfico y congestiones

Pasarelas entre redes

Estadísticas

Capa Transporte

Multiplexado

Manejo de varias conexiones Red

Control de Flujo

Control de Errores

Independiente de la subred (conmutadores)

Capa Sesión (en desuso)

Control de Dialogo (Manejo de un token)

Sincronización

Capa Presentación (en desuso)

Semántica más que sintaxis de la información

Conversión de código de caracteres

Compactación

Criptografía

Capa Aplicación

Servicios al usuario mediante arquitecturas
cliente/servidor

Aplicaciones que hacen transparente al
usuario las particularidades del medio de
transmisión

OSI vs TCP/IP

OSI sirvió de modelo para desarrollar 

otras arquitecturas por capas

Standarización

Standards 
       De facto: sin plan formal
          De jure: bajo autoridad de standarización

ITU (Unión Internacional de Telecomunicaciones)
Sectores:
   ITU­R (Radiocomunicaciones)           Gobiernos Nacionales
   ITU­T (Telecomunicaciones)              De sector (fabricantes)
   ITU­D (Desarrollo)

           Miembros:

             Asociados (organismos especializados)
             Agencias reguladoras (FCC, CONATEL)

ISO (Organización de Standares Internacionales)
   ANSI (USA), AFNOR (Francia), NORVEN (Venezuela)
IEEE (Instituto de Ingenieros eléctricos y electrónicos)
   Exitoso en standards LAN
IAB (Consejo de Actividades de Internet)
   IRTF (Investigación a largo plazo) e IETF (Ingeniería a corto plazo)
   Se basan en los RFC 

Principios de standarización

Problemas de OSI

Capas enlace y red muy cargadas.

Capas sesión y presentación muy poco usadas y con 
pocas funcionalidades.

Control de flujo y de errores en varias capas 
(ineficiente). 

Gerencia de la red inexistente en el modelo.

Mecanismos de interrupciones inadecuado para los 
lenguajes de alto nivel.

Características del diseño de

las capas

Mecanismos de Conexión, Desconexión y envío de Datos.

Reglas de transferencia

Simplex Half Duplex Full Duplex

Control de Errores

Perdidas Duplicados

Dañados

Control de Flujo

Ensamblaje y corte de la información

Multiplexaje

Selección de la ruta

Tipos de Servicios

Orientado Conexión (por ejm. Sistema Telefónico)

Conexión
Transferencia de datos
Desconexión

No Orientado Conexión (por ejm. Sistema postal)

Transferencia de datos

Secuencia de mensajes 
          confiable
Secuencia de bytes 
       confiable

Conexión no confiable

Datagramas no confiable

Datagramas con acuse 
      de recepción

Request­ Reply 

Secuencia de páginas
     Login  remoto
   Voz digitalizada
Correo electrónico clásico
Correo electrónico registrado

Bases de datos

Principios de Protocolos

Protocolos de 
      una vía

 Protocolo de 
     dos vías

 Protocolo de 
     tres vías

Desconexión

Transferencia
   de datos

Conexión

Limitaciones de los protocolos

Dos batallones
 de la Armada
      Azul

Dos batallones
 de la Armada
      Azul

Tres batallones de la
   Armada Amarilla

Condiciones:
 Las colinas no son visibles entre ellas 
 El valle no es visible de ninguna de las colinas
 Los mensajeros no mienten
 No existe otro medio de comunicación que los mensajeros

Modelo del canal

  Un canal es el medio de comunicación a
través del cual se comunican dos entidades

Sentido de la información

Simplex
Half Duplex
Full Duplex

Errores de transmisión
Perdida de paquetes
Duplicación de paquetes
Alteración del orden de llegada de los paquetes

Algoritmos de Protocolos

• Programas bajo arquitectura cliente/servidor

• Ocurren eventos en paralelo (recepción y

emisión simultanea)

• Mecanismo de programación por

interrupciones

• Independencia de las capas.

Protocolo UTOPIA

Suposiciones

u Canal Simplex.
u Red siempre disponible.
u Siempre listos receptor y emisor.
u Tiempo de procesamiento y transmisión 

ignorado.

u Dedicación exclusiva del receptor.
u Canal libre de errores, sin pérdidas.

Código de UTOPIA

Libre de errores, tráfico en una dirección (de emisor a receptor)
y receptor puede procesar tan rápido como le envíe el emisor

void emisor() {

frame s;
packet buffer;
while true {

from_network(&buffer):
s.info=buffer;
to_physical(&s);

}

}

void receptor () {
frame r;
event_type event;
while true {
wait_event(&event);
from_physical(&r);
to_network(&r.info);
}
}

Protocolo Simplex Stop and

Wait

Suposiciones

u Canal half duplex.
u Red siempre disponible.
u Siempre listos receptor y emisor.
u Tiempo de procesamiento no despreciable en el 

receptor (debe controlarse la emisión).

u Dedicación exclusiva del receptor.
u Canal libre de errores, sin pérdidas.

Código de Stop and Wait

Libre de errores, tráfico en una dirección (aunque hay acuse de
recepción) y hay control de flujo (prevenir inundación del
receptor)

void emisor() {

frame s; packet buffer;
event_type event;
while true {

from_network(&buffer):
s.info=buffer;
to_physical(&s);
wait_event(&event);

}

}

void receptor () {
frame r, s;
event_type event;
while true {
wait_event(&event);
from_physical(&r);
to_network(&r.info);
to_physical(&s);
}
}

Protocolo simplex a canal con

errores

Suposiciones

u Canal half duplex.
u Red siempre disponible.
u Siempre listos receptor y emisor.
u Tiempo de procesamiento no despreciable en el 

receptor (debe controlarse la emisión).

u Canal con errores, pérdidas.
u Utilización de timer (o sea posibilidad de 

duplicados).

u Enumeración de los paquetes.

Código emisor (protocolo 3)

Flujo de datos unidireccional con canal no confiable

void emisor() {
seq_nr next_frame_send; frame s;
event_type event; packet buffer;

next_frame_send=0; from_network(&buffer);
while true {

s.info=buffer; s.seq=next_frame_send;
to_physical(&s); start_timer(s.seq);
wait_event(&event);
if (event == frame_arrival) {
from_network(&buffer);
next_frame_send++;
}

}

}

Código receptor (protocolo 3)

Flujo de datos unidireccional con canal no confiable

void receptor () {
seq_nr frame_expected;
event_type event; frame r, s;

frame_expected=0;
while true {

wait_event(&event);;
if (event == frame_arrival) {
from_physical(&r);
if (r.seq == frame_expected) {

to_network(&r.info);
frame_expected++;

}
to_physical(&s);

} } }

Protocolos de ventanas

deslizantes

Transmitir en dos direcciones (canal Full Duplex)

Piggyback

Número de secuencia para los paquetes

Control de flujo: ventana de emisión y ventana de recepción

Si ventana de emisión llena, no enviar mas paquetes
Si ventana de recepción llena, rechazar paquetes

Timers para reemisión y acuses de recepción

Control de Flujo

Velocidad del emisor mayor que
    la velocidad del receptor

Reprimir al emisor

        Política de las Ventanas Deslizantes:
Eficiencia en el canal
Ventana en el emisor:
Ventana en el receptor:
Control de flujo

      Envía n paquetes y no continúes 
         transmisión hasta que te avise

Control de Congestión  =  Control de Flujo

/

Algoritmos de Congestión

Políticas:

(1) Preasignar recursos

Número fijo de buffers por canal de salida

(2) Descartar paquetes

Rechazo de paquetes si no hay recursos

(3) Restringir el número de paquetes

Paquetes debe solicitar permiso para circular

(4) Control de flujo

Ayuda a evitar congestiones

(5) Paquete de contención

Detectar congestión y reducir el tráfico

(6) Bloqueos

Evitar deadlocks por asignación de recursos

Algoritmos de Congestión:

Preasignación

Reservar para cada conmutador una cuota fija de buffers.

Si todos están reservados: Buscar otra ruta

Señal de ocupado

Ventajas: Congestión imposible

Desventajas: Ineficiente uso de los recursos

Solución:   Asignar un timer a cada 
      buffer y disponer de él para 
      paquetes de otra conexión

 

Algoritmos de Congestión:

Restricción

Crear un número de permisos que circulan por la red

Cada nodo emisor debe capturar un permiso y destruirlo

Cuando el receptor obtiene el paquete regenera el permiso

            #paquetes < #permisos

Desventajas:

Puede haber conmutadores repleto de pqts
Distribución no equitativa de permisos

Solución:   Nodo central que administre 

    permisos con un número 
    máximo por conmutador
Si un permiso se destruye (caída de un 
conmutador) puede ser irrecuperable

 

Control de Errores

• Causas de Errores

– Errores termales
– Errores puntuales (pulsos)

• Arcos entre relays
• Personal técnico laborando
• Subidas de tensión

Ejm: 10 mseg a 9600 bps => 96 bits afectados

– Errores al codificar (Análisis de Fourier)
– Interferencia por adyacencia
– Supresores de eco apagados
– Problemas de Amplificación (Compactación en

Microondas)