Make your own free website on Tripod.com
Protocolo simplex

Un protocolo simplex no restringido
Inicialmente vamos a suponer que la comunicación es perfecta, sin errores, por lo que no
tenemos que preocuparnos de comprobar el CRC ni de retransmisiones. El receptor está
siempre disponible y preparado para recibir tramas con un espacio de buffer infinito,
por lo que no hemos de efectuar control de flujo. El emisor está siempre preparado para
transmitir cualquier cosa que reciba de la capa de red. En este caso el único evento
posible es frame_arrival.

Un protocolo simplex de parada y espera
En una primera aproximación a la vida real supongamos ahora que el receptor no siempre
está disponible para recibir, por tener ocupado su buffer de entrada; esto puede ocurrir
bien porque la capa de enlace no sea capaz de 'digerir' las tramas con la suficiente
rapidez, o porque la capa de red del receptor no sea lo bastante rápida (podría ser que
el mismo proceso tenga que atender varias líneas, por ejemplo).

En este caso lo más sencillo es que el emisor espere confirmación después de enviar cada
trama, de forma que sólo después de recibir la confirmación envíe la siguiente. De esta
manera se garantiza la no saturación del receptor. Esto es lo que se conoce como un
protocolo de parada y espera.

Un protocolo simplex para un canal con ruido
Siguiendo en nuestro proceso de aproximar el protocolo a la realidad contemplemos ahora
la posibilidad de que el canal de comunicación no sea perfecto; las tramas pueden
alterarse debido al ruido de la comunicación, o incluso perderse por completo. Gracias a
la presencia del campo CRC el receptor podrá detectar la llegada de una trama defectuosa,
en cuyo caso pedirá retransmisión. La posibilidad de que una trama se pierda por completo
introduce una complicación adicional, ya que si esto le ocurre por ejemplo a un acuse de
recibo el emisor pasado un tiempo razonable enviará la trama de nuevo pensando que no ha
llegado la primera vez, lo cual produciría una trama duplicada que el receptor pasaría a
la capa de red; esto es inaceptable para cualquier protocolo.

Para poder reconocer cuando una trama llega duplicada lo más sencillo es numerarlas; en
nuestro caso el emisor no enviará una trama hasta recibir el acuse de recibo de la anterior,
por lo que nos bastaría con numerar las tramas con un campo de un solo bit como 0,1,0,1, etc.
(módulo 2). Los protocolos donde el emisor espera una confirmación o acuse de recibo para cada
dato enviado se denominan protocolos PAR (Positive Acknowledgement with Retransmission) o
también ARQ (Automatic Repeat reQuest).

En este protocolo el receptor no realiza la comprobación del campo CRC; para él toda trama
que reciba de la capa física es correcta; se supone que las tramas pueden llegar o perderse,
pero no llegar de forma parcial o alteradas. La realidad no es así, como ya sabemos. Podemos
considerar que en nuestro caso hay un nivel inferior que se ocupa de comprobar el CRC, y que
descarta la trama en caso de detectar cualquier error. De esta forma el efecto sería equivalente
a la suposición simplista de que las tramas o no llegan o llegan perfectamente. Generalmente
todo lo relativo al control de errores y cálculo de CRCs se realiza en rutinas implementadas
en el hardware de comunicaciones de los equipos, y es por tanto relativamente independiente
del protocolo utilizado. En cierto modo podemos considerar el cálculo de CRCs como la parte
'baja' de la capa de enlace.