Please enable JavaScript.

Coggle requires JavaScript to display documents.

PROTOCOLOS ELEMENTALES DE ENLACE DE DATOS, PROTOCOLOS DE VENTANA…

- - - - El protocolo consiste en dos procedimientos diferentes, un emisor y un receptor. El emisor se ejecuta en la capa de enlace de datos de la máquina de origen y el receptor se ejecuta en la capa de enlace de datos de la máquina de destino.
        
        El emisor está en un ciclo while infinito que sólo envía datos a la línea tan rápido como puede. El cuerpo del ciclo consiste en tres acciones: obtener un paquete de la (siempre dispuesta) capa de red, construir una trama de salida usando la variable s y enviar la trama a su destino. Este protocolo sólo utiliza el campo info de la trama, pues los demás campos tienen que ver con el control de errores y de flujo, y aquí no hay restricciones de este tipo.
        
        El receptor también es sencillo. Al principio espera que algo ocurra, siendo la única posibilidad la llegada de una trama sin daños. En algún momento llega la trama, el procedimiento wait_for_event regresa y event contiene el valor frame_arrival (que de todos modos se ignora). La llamada a from_physical_layer elimina la trama recién llegada del búfer de hardware y la coloca en la variable r, en donde el código receptor pueda obtenerla. Por último, la parte de los datos se pasa a la capa de red y la capa de enlace de datos se retira para esperar la siguiente trama, para lo cual se suspende efectivamente hasta que ésta llega.
        
        El protocolo utópico es irreal, ya que no maneja el control de flujo ni la corrección de errores. Su procesamiento se asemeja al de un servicio sin conexión ni confirmación de recepción que depende de las capas más altas para resolver estos problemas, aun cuando un servicio sin conexión ni confirmación de recepción realizaría cierta detección de errores.
  - - - Una solución es construir un receptor lo suficientemente poderoso como para procesar un flujo continuo de tramas, una tras otra sin interrupción.Sin embargo, ésta es una solución para el peor de los casos. Requiere hardware dedicado y se pueden desperdiciar recursos si el enlace se usa poco.
        
        Una solución más general para este dilema es hacer que el receptor proporcione retroalimentación al emisor. Tras haber pasado un paquete a su capa de red, el receptor regresa al emisor una pequeña trama ficticia que, de hecho, autoriza al emisor para que transmita la siguiente trama.
        
        Los protocolos en los que el emisor envía una trama y luego espera una confirmación de recepción antes de continuar se denominan de parada y espera.
        
        Aunque el tráfico de datos en este ejemplo es simplex, y va sólo desde el emisor al receptor, las tramas viajan en ambas direcciones. En consecuencia, el canal de comunicación entre las dos capas de enlace de datos necesita tener capacidad de transferencia de información bidireccional. Sin embargo, este protocolo implica una alternancia estricta de flujo: primero el emisor envía una trama, después el receptor envía una trama, después el emisor envía otra trama, luego el receptor envía otra, y así sucesivamente. Aquí sería suficiente un canal físico semi-dúplex.
        
        Puesto que sólo es importante la llegada de la trama al emisor y no su contenido, el receptor no necesita poner ninguna información específica en la trama.
  - - - Para ver lo que puede resultar mal, recuerde que el objetivo de la capa de enlace de datos es proporcionar una comunicación transparente y libre de errores entre los procesos de las capas de red. La capa de red de la máquina A pasa una serie de paquetes a su capa de enlace de datos, la cual debe asegurar que se entregue una serie de paquetes idénticos a la capa de red de la máquina B a través de su capa de enlace de datos. En particular, la capa de red en B no tiene manera de saber si el paquete se perdió o duplicó, por lo que la capa de enlace de datos debe garantizar que ninguna combinación de errores de transmisión, por improbables que sean, pudiera causar la entrega de un paquete duplicado a la capa de red.
        
        Sin duda, lo que se necesita es alguna manera de que el receptor sea capaz de distinguir entre una trama que está viendo por primera vez y una retransmisión. La forma evidente de lograr esto es hacer que el emisor ponga un número de secuencia en el encabezado de cada trama que envía. A continuación, el receptor puede verificar el número de secuencia de cada trama que llega para ver si es una trama nueva o un duplicado que debe descartarse.
        
        Como el protocolo debe ser correcto y es probable que el campo de número de secuencia en el encabezado sea pequeño como para poder usar el enlace en forma eficiente, ¿Cuál es la cantidad mínima de bits necesarios para el número de secuencia?
        
        El punto importante es que debe transportar números de secuencia que sean lo bastante grandes como para que el protocolo funcione de manera correcta, o de lo contrario no se podrá considerar un verdadero protocolo.
        
        Basta con un número de secuencia de 1 bit (0 o 1). En cada instante, el receptor espera un número de secuencia en particular. Cuando llega una trama que contiene el número de secuencia correcto, se acepta y se pasa a la capa de red, para después confirmar su recepción.
- - - - Como los demás, comienza por definir algunas variables. Next_frame_to_send indica qué trama está tratando de enviar el emisor. Asimismo, frame_expected indica qué trama espera el receptor. En ambos casos, 0 y 1 son las únicas posibilidades.
        
        En circunstancias normales, una de las dos capas de enlace de datos es la que comienza a transmitir la primera trama. En otras palabras, sólo uno de los programas de capa de enlace de datos debe contener las llamadas de procedimiento to_physical_layer y start_timer fuera del ciclo principal. La máquina que inicia obtiene el primer paquete de su capa de red, construye una trama a partir de él y la envía. Al llegar esta (o cualquier) trama, la capa de enlace de datos del receptor la verifica para saber si es un duplicado. Si la trama es la esperada, se pasa a la capa de red y la ventana del receptor se recorre hacia arriba.
        
        El campo de confirmación de recepción contiene el número de la última trama recibida sin error. Si este número concuerda con el de secuencia de la trama que está tratando de enviar el emisor, éste sabe que ha terminado con la trama almacenada en el búfer (buffer) y que puede obtener el siguiente paquete de su capa de red. Si el número de secuencia no concuerda, debe seguir tratando de enviar la misma trama. Cada vez que se recibe una trama, también se regresa una.
  - - - Hay dos métodos básicos disponibles para tratar con los errores en presencia de la canalización.
        
        Una de las opciones, llamada retroceso n, es que el receptor simplemente descarte todas las tramas subsecuentes, sin enviar confirmaciones de recepción para las tramas descartadas. Esta estrategia corresponde a una ventana de recepción de tamaño 1. En otras palabras, la capa de enlace de datos se niega a aceptar cualquier trama excepto la siguiente que debe entregar a la capa de red. Si la ventana del emisor se llena antes de que expire el temporizador, el canal comenzará a vaciarse. En algún momento, el emisor terminará de esperar y retransmitirá en orden todas las tramas cuya recepción aún no se haya confirmado, comenzando por la trama dañada o perdida. Esta estrategia puede desperdiciar bastante ancho de banda si la tasa de error es alta.
        
        La otra estrategia general para el manejo de errores cuando las tramas se colocan en canalizaciones se conoce como repetición selectiva. Cuando se utiliza, si se recibe una trama dañada se descarta, pero las tramas en buen estado que se reciban después de ésa se aceptan y almacenan en el búfer. Cuando expira el temporizador del emisor, sólo se retransmite la última trama sin confirmación de recepción. Si la trama llega correctamente, el receptor puede entregar a la capa de red, en secuencia, todas las tramas que ha almacenado en el búfer. La repetición selectiva corresponde a una ventana del receptor mayor a 1. Este método puede requerir grandes cantidades de memoria en la capa de enlace de datos, si la ventana es grande.
        
        Estos dos métodos alternativos son concesiones entre el uso eficiente del ancho de banda y el espacio de búfer en la capa de enlace de datos. Dependiendo de qué recurso sea más valioso, se puede utilizar uno u otro.
  - - - En este protocolo, tanto el emisor como el receptor mantienen una ventana de números de secuencia pendientes y aceptables, respectivamente. El tamaño de la ventana del emisor comienza en 0 y crece hasta un máximo predefinido. Por el contrario, la ventana del receptor siempre es de tamaño fijo e igual al máximo predeterminado. El receptor tiene un búfer reservado para cada número de secuencia dentro de su ventana fija. Cada búfer tiene un bit asociado (arrived ), el cual indica si el búfer está lleno o vacío. Cada vez que llega una trama, la función between verifica su número de secuencia para ver si cae dentro de la ventana. De ser así, y si todavía no se recibe, se acepta y almacena. Esta acción se lleva a cabo sin importar si la trama contiene o no el siguiente paquete que espera la capa de red. Claro que se debe mantener dentro de la capa de enlace de datos sin pasarla a la capa de red hasta que se hayan entregado todas las tramas de menor número a la capa de red en el orden correcto.
        
        La recepción no secuencial introduce limitaciones adicionales en los números de secuencia de tramas, que no se presentan en los protocolos en los que las tramas sólo se aceptan en orden.
        
        En algún momento expira el temporizador del emisor y éste retransmite la trama 0. Cuando llega esta trama al receptor, se efectúa una verificación para saber si está dentro de la ventana del mismo.