Projeto e Desempenho de Redes - Controle do enlace de dados

Prévia do material em texto

Quarta edição
F727c Forouzan, Behrouz A. 
 Comunicação de dados e redes de computadores [recurso 
 eletrônico] / Behrouz A. Forouzan com a colaboração de 
 Sophia Chung Fegan ; tradução: Ariovaldo Griesi ; revisão 
 técnica: Jonas Santiago de Oliveira. – 4. ed. – Dados 
 eletrônicos. – Porto Alegre : AMGH, 2010.
 
 Editado também como livro impresso em 2008.
 ISBN 978-85-63308-47-4
 1. Comunicação entre computadores. 2. Redes de 
 computadores. I. Fegan, Sophia Chung. II. Título. 
CDU 004.7
Catalogação na publicação: Ana Paula M. Magnus – CRB-10/Prov-009/10
307
CAPÍTULO 11
Controle do Enlace de Dados
As duas principais funções da camada de enlace de dados são o controle do enlace de da-
dos e o controle de acesso ao meio de transmissão. A primeira delas, o controle do enlace 
de dados, trata do projeto e procedimentos para comunicação entre dois nós adjacentes: 
comunicação confiável de um nó a outro. Discutiremos essa funcionalidade neste capítulo. 
A segunda função da camada de enlace é o controle de acesso ao meio de transmissão, ou 
seja, como compartilhar um enlace físico (link) de dados. Trataremos dessa funcionalidade 
no Capítulo 12.
Entre as funções do controle do enlace de dados, temos a montagem e a delimitação de 
frames (framing) e a implementação de mecanismos de controle de fluxo e de erros por meio 
de protocolos de comunicação de dados implementados via software, os quais possibilitam uma 
transmissão confiável dos frames entre os nós. Neste capítulo, iremos discutir os conceitos de 
framing (montagem e delimitação de frames), ou como organizar os bits que são transmitidos 
pela camada física. Em seguida, discutiremos o controle de fluxo e de erros. Um subconjunto 
deste tópico, técnicas para detecção e correção de erros, já foi abordado no Capítulo 10.
Para implementar uma comunicação confiável entre nós adjacentes, necessitamos dos proto-
colos da camada de enlace. Cada protocolo é um conjunto de regras que pode ser implementado 
por software e deve ser executado pelos dois nós envolvidos na comunicação de dados no nível 
da camada de enlace. Abordaremos cinco protocolos: dois para canais sem ruído (ideais) e três 
para canais com ruído (reais). Os da primeira categoria não são realmente implementados em 
redes de computadores, mas fornecem uma base teórica para compreender os protocolos da 
segunda categoria.
Após discutirmos o projeto dos cinco protocolos, mostraremos como um protocolo orientado 
a bit é implementado na prática, usando como exemplo o HDLC (High Level Data Link Con-
trol). Também falaremos a respeito de um protocolo popular orientado a byte, denominado PPP 
(Point to Point Protocol), protocolo ponto a ponto.
11.1 FRAMING
Transmitir dados na camada física significa transmitir bits na forma de sinal de uma origem a 
um destino. A camada física gera a sincronização de bits para garantir que o emissor e o receptor 
utilizem uma mesma base de tempo para a temporização dos bits.
Por outro lado, a camada de enlace precisa empacotar bits em frames de modo que cada fra-
me seja distinguível um do outro. Nosso sistema de correio pratica uma espécie de framing. O 
simples ato de colocar uma carta em um envelope separa uma informação da outra; o envelope 
serve como um delimitador. Além disso, cada envelope define os endereços do remetente e 
308 CAPÍTULO 11 CONTROLE DO ENLACE DE DADOS
do destinatário, já que o sistema postal é um serviço de transporte do tipo vários-para-vários 
(many-to-many).
O framing, na camada de receptor de dados, separa uma mensagem, de uma origem a um 
destino, de outras mensagens a outros destinos, acrescentando o endereço do emissor e do des-
tino. O endereço do receptor define para onde o pacote deve ser encaminhado; o endereço do 
emissor ajuda o receptor a confirmar o recebimento do pacote.
Embora uma mensagem inteira possa ser empacotada em um único frame, normalmente 
isso não é feito. Uma razão para tal é que um frame muito grande torna os controles de fluxo 
e de erros ineficientes. Quando uma mensagem é transportada em um frame muito grande, até 
mesmo um erro em um único bit pode exigir a retransmissão de toda a mensagem. Quando 
uma mensagem é dividida em frames menores, um erro de bit afeta apenas esse frame pequeno.
Framing de Tamanho Fixo
Os frames podem ser de tamanho fixo ou variável. Na montagem de frames de tamanho fixo 
não existe a necessidade de definir os limites dos frames; o tamanho do frame em si já é usado 
como delimitador. Um exemplo desse tipo é uma rede WAN ATM, que usa frames de tamanho 
fixo denominados células. Trataremos do ATM no Capítulo 18.
Framing de Tamanho Variável
O tema principal deste capítulo se refere à montagem de frames de tamanho variável, predo-
minante em redes locais. Em um framing de tamanho variável, precisamos de métodos eficientes 
para definir o final de um frame e o início do seguinte. Historicamente, foram usadas duas abor-
dagens para este fim: método orientado a caractere e método orientado a bit.
Protocolos Orientados a Caractere
Em um protocolo orientado a caractere, os dados a serem transmitidos são caracteres de 8 bits 
de um sistema de codificação como o ASCII (ver Apêndice A). O cabeçalho, que normalmente 
carrega os endereços de origem e de destino, bem como outras informações de controle e o 
trailer que transporta bits redundantes para detecção e correção de erros, também é formado por 
múltiplos de 8 bits. Para separar um frame do seguinte, é acrescentado um flag de 8 bits (1 byte) 
no início e no final de um frame. O flag, composto por caracteres especiais específicos por pro-
tocolo, sinaliza o início ou o final de um frame. A Figura 11.1 mostra o formato de um frame em 
um protocolo orientado a caractere.
Figura 11.1 Um frame em um protocolo orientado a caractere
Flag Flag
Dados da camada superior
Número variável de caracteres
Cabeçalho Trailer• • •
Protocolos orientados a caractere eram muito populares na época em que havia apenas troca 
de texto entre camadas de enlace de dados. Podia-se escolher como flag qualquer caractere não 
utilizado na comunicação de texto. Hoje em dia, porém, enviamos outros tipos de informação, 
como imagens, áudio e vídeo. Qualquer padrão usado como flag também poderia ser parte da in-
formação. Se isso acontecesse, o receptor, ao encontrar esse padrão no meio dos dados, poderia 
pensar que o final do frame havia sido atingido. Para resolver esse problema, foi acrescentada 
uma estratégia conhecida como byte-stuffing (inserção de byte) durante a montagem de frames 
em protocolos orientados a caractere. Na inserção de byte (ou de caractere), um byte especial 
é acrescentado à seção de dados do frame quando existe um caractere com o mesmo padrão 
do flag. Na seção de dados é inserido um byte extra. Esse byte é normalmente denominado 
caractere escape (ESC), que tem um padrão de bits predefinido. Toda vez que o receptor en-
contrar o caractere ESC, ele o elimina da seção de dados e trata o caractere seguinte como um 
dado e não como um flag delimitador.
Embora a inserção de byte com o caracter escape permita a presença do flag na seção de 
dados do frame, ela acarreta outro problema. O que acontece se o texto contiver um ou mais 
caracteres escape seguidos de um flag? O receptor elimina o caractere escape, mas preserva o 
flag, o que é interpretado incorretamente como fim de frame. Para solucionar essa questão, os 
caracteres escape que fazem parte do texto também devem ser marcados por outro caractere es-
cape. Em outras palavras, se o caractere escape fizer parte do texto, é acrescentado outro escape 
extra para mostrar que o segundo faz parte do texto. A Figura 11.2 ilustra a situação.
Figura 11.2 Inserção e eliminação de bytes
Dados provenientes da camada superior
Frame enviado Enxertado
Eliminado
2 bytes
extras
Flag ESC
Dados para a camada superior
Flag ESC
Flag FlagCabeçalho TrailerFlag ESCESC ESC
Flag FlagCabeçalho TrailerFlag ESCESCESC
Frame recebido
Byte-stuffing é o processo de acrescentar 1 byte extra toda vez 
que existir um flag ou caractere escape no texto.
Os protocolos orientados a caractere apresentam outro problema nas comunicações de da-
dos. Os sistemas atuais de codificação universal, como o Unicode, possuem caracteres de 16 e 
32 bits, que são conflitantes com os caracteres de 8 bits. Podemos dizer que, em geral, a tendên-
cia é ir no sentido dos protocolos orientados a bit, que discutiremos em seguida.
Protocolos Orientados a Bit
Em um protocolo orientado a bit, a seção de dados de um frame é uma seqüência de bits a 
ser interpretada, pela camada superior, como texto, imagem, áudio, vídeo e assim por diante. 
Entretanto, além dos cabeçalhos (e possíveis trailers), ainda precisamos de um delimitador para 
separar um frame do outro. A maioria dos protocolos usa um flag especial com um padrão de 
8 bits 01111110 como delimitador para definir o início e o final de um frame, conforme mostra-
do na Figura 11.3.
SEÇÃO 11.1 FRAMING 309
310 CAPÍTULO 11 CONTROLE DO ENLACE DE DADOS
Figura 11.3 Um frame em um protocolo orientado a bit
01111110
Flag Flag
01111110
Número variável de bits
Cabeçalho Trailer01111010110 • • • 11011110
Dados provenientes da camada superior
O flag pode criar o mesmo tipo de problema visto nos protocolos orientados a byte. Isto é, se 
o padrão de flag aparecer no meio dos dados, precisamos informar de alguma maneira ao recep-
tor que não se trata do fim do frame. Fazemos isso enxertando 1 único bit (em vez de 1 byte) para 
impedir que o padrão se pareça com um flag. A estratégia se chama bit-stuffing, inserção de bit. 
Na inserção de bit, se forem encontrados 1 bit 0 e cinco bits 1s consecutivos, será acrescentado 
um bit 0 extra. Esse bit extra enxertado é eliminado dos dados no final pelo receptor. Note que o 
bit extra é acrescentado após 0 seguido por cinco 1s, independentemente do valor do bit seguin-
te. Isso garante que a seqüência do campo de flag não apareça inadvertidamente no frame.
Bit-stuffing é o processo de acrescentar um bit 0 toda vez que, nos dados, 
aparecerem cinco 1s consecutivos após 0 de modo que o receptor 
não confunda o padrão 0111110 com um flag.
A Figura 11.4 ilustra a inserção de bits no emissor e sua eliminação no receptor. Observe 
que, sempre que tivermos 0 seguido de cinco bits 1s, inseriremos logo após um bit 0. O bit 0 será 
eliminado pelo receptor.
Figura 11.4 Inserção e eliminação de bits
Dados provenientes da camada superior
Frame enviado
Dados para a camada superior
Inserido
Eliminado
0001111111001111101000
0001111111001111101000
Flag FlagCabeçalho 000111110110011111001000 Trailer
Flag FlagHeader 000111110110011111001000 Trailer
Frame recebido
2 bits
extras
Isso significa que, se o padrão de bits parecido com o do flag, 01111110, aparecer no 
meio dos dados, ele mudará para 011111010 (bit inserido) e não será confundido com um 
flag pelo receptor. O flag real 01111110 não é inserido pelo emissor e será reconhecido 
como tal pelo receptor.
11.2 CONTROLES DE FLUXO E ERROS
A comunicação de dados requer pelo menos dois dispositivos operando em conjunto, um para 
enviar e outro para receber informação. Mesmo um arranjo básico desses dispositivos requer 
uma grande dose de coordenação para que ocorra uma troca de dados inteligível. As responsa-
bilidades mais importantes da camada de enlace são o controle de fluxo e o controle de erros. 
Juntas, essas funções são conhecidas como controle do enlace de dados.
Controle de Fluxo
O controle de fluxo coordena a quantidade de dados que pode ser enviada antes de receber uma 
confirmação, e é uma das tarefas mais importantes da camada de enlace. Na maioria dos protoco-
los, o controle de fluxo é um conjunto de procedimentos que informa ao emissor qual a quantidade 
máxima de dados que ele pode transmitir antes de receber uma confirmação por parte do receptor. 
Não se deve permitir um fluxo de dados que sobrecarregue o receptor. Qualquer dispositivo 
receptor tem uma capacidade limitada de processar dados que chegam e uma quantidade limitada de 
memória para armazená-los. O dispositivo receptor deve ser capaz de informar ao emissor antes 
de esses limites serem atingidos e solicitar que o emissor envie um número menor de frames ou 
pare a transmissão temporariamente. Os dados que chegam devem ser verificados e processa-
dos antes de serem utilizados. A velocidade de tal processamento normalmente é menor que a 
velocidade de transmissão. Por essa razão, cada dispositivo receptor tem uma área de memória, 
denominada buffer, reservada para armazenar dados que chegam, até que eles sejam processados. 
Se o buffer começar a ficar cheio, o receptor tem de ser capaz de informar ao emissor para parar a 
transmissão, até que ele seja capaz novamente de receber mais dados.
Controle de fluxo é um conjunto de procedimentos usado para controlar a quantidade de 
dados que o emissor pode enviar antes de receber confirmação dos dados transmitidos.
Controle de Erros
O controle de erros refere-se tanto à detecção quanto à correção de erros. Ele possibilita que o 
receptor informe ao emissor sobre quaisquer frames perdidos ou corrompidos durante a trans-
missão e coordena a retransmissão desses frames pelo emissor. Na camada de enlace, a expressão 
controle de erros corresponde, basicamente, aos métodos de detecção de erros e de retransmis- 
são. Geralmente o controle de erros na camada de enlace é implementado de forma simples: toda 
vez que um erro for detectado, os frames especificados são retransmitidos. Esse processo é chama-
do ARQ (Automatic Repeat Request — solicitação de repetição automática).
O controle de erros na camada de enlace se baseia na solicitação 
de repetição automática que é a retransmissão dos dados.
11.3 PROTOCOLOS
Vejamos agora como a camada de enlace pode combinar framing, controle de fluxo e controle 
de erros para garantir a entrega de dados de um nó a outro. Os protocolos são comumente imple-
SEÇÃO 11.3 PROTOCOLOS 311
312 CAPÍTULO 11 CONTROLE DO ENLACE DE DADOS
mentados via software usando uma das linguagens de programação comum. Para tornar nossa 
discussão independente de uma linguagem de programação, escrevemos cada protocolo em uma 
versão de pseudocódigo, que se concentra em sua maior parte no procedimento em vez de se 
aprofundar nos detalhes das regras da linguagem.
Dividimos a discussão dos protocolos naqueles que podem ser usados para canais sem ruído 
(isentos de erros) e naqueles que podem ser usados em canais com ruído (que geram erros). Os pro-
tocolos da primeira categoria não podem ser usados na vida prática, mas servem como base para a 
compreensão dos protocolos para canais com ruído. A Figura 11.5 mostra essa classificação.
Figura 11.5 Taxonomia dos protocolos discutidos neste capítulo
Protocolos
Para canal
sem ruído
O mais simples possível
Stop-and-Wait
Para canal
com ruído
Stop-and-Wait ARQ
Go-Back-N ARQ
Selective Repeat ARQ
Existe uma diferença entre os protocolos aqui discutidos e aqueles usados em redes de com-
putadores reais. Todos os protocolos que discutiremos são unidirecionais, no sentido de que os 
frames de dados trafegam de um nó, chamado emissor, para outro nó, denominado receptor. 
Embora frames especiais, conhecidos como ACK (Acknowledgment, confirmação) e NAK 
(Negative Acknowledgment — confirmação negativa), possam fluir na direção oposta para fins 
de controles de fluxo e de erro, o fluxo de dados é apenas em uma direção.
Em uma rede real, os protocolos de enlace são implementados como bidirecionais; os dados 
fluem em ambas as direções. Nesses protocolos, informações de controle de fluxo e de erros 
como ACKs e NAKs são incluídas nos frames de dados em uma técnica denominada piggyba-
cking. Como os protocolos bidirecionais são mais complexos que os unidirecionais, optamos 
por iniciar nossa discussão pelos protocolos unidirecionais. Se você for capaz de entender os 
protocolos unidirecionais,a explicação poderá ser estendida aos protocolos bidirecionais. Dei-
xamos essa extensão como exercício.
11.4 CANAIS SEM RUÍDO
Suponhamos, em primeiro lugar, que temos um canal ideal no qual nenhum frame é perdido, 
duplicado ou corrompido. Introduziremos dois protocolos para esse tipo de canal. O primeiro é 
um protocolo que não usa controle de fluxo; o segundo é um que o utiliza. Obviamente, nenhum 
deles possui controle de erros, já que partimos do pressuposto de que se trata de um canal per-
feito, sem ruído.
O Protocolo mais Simples Possível
Nosso primeiro protocolo, designado o Protocolo mais Simples Possível, por falta de outro 
nome qualquer, não implementa controles de erros e fluxo. Como outros protocolos que dis-
cutiremos neste capítulo, trata-se de um protocolo unidirecional no qual os frames de dados 
trafegam apenas em uma direção — do emissor para o receptor. Estamos supondo que o receptor 
possa tratar imediatamente qualquer frame recebido com um tempo de processamento suficien-
temente pequeno para ser considerado desprezível. A camada de enlace do receptor processa 
imediatamente o cabeçalho do frame e repassa o pacote de dados para sua camada de rede, que 
também é capaz de aceitar o pacote imediatamente. Em outras palavras, o receptor jamais ficará 
sobrecarregado com frames que chegam.
Projeto
Não há necessidade de controle de fluxo nesse esquema. A camada de enlace no emissor re-
cebe dados de sua camada de rede, monta e delimita um frame a partir dos dados e o envia. A 
camada de enlace no receptor recebe um frame de sua camada física, extrai os dados do frame 
e os entrega à camada de rede. As camadas de enlace do emissor e do receptor implementam 
serviços de transmissão de dados para suas camadas de rede. As camadas de enlace usam os 
serviços fornecidos por suas camadas físicas (como sinalização, multiplexação e assim por 
diante) para a transmissão física dos bits. A Figura 11.6 ilustra o projeto do Protocolo Mais 
Simples Possível.
Figura 11.6 O projeto do protocolo mais simples possível sem nenhum controle de fluxo e de erros
Emissor Receptor
Frames de dados
Enlace
Rede
Envia o frame
Obtém os
dados
Enlace
FísicaFísica
Rede
Recebe frame
Entrega os
dados
Evento:
Repetir indefinidamente
Solicitação da
camada de rede
Algoritmo no lado do emissor
Repetir indefinidamente
Algoritmo no lado do receptor
Evento: Notificação da
camada física
Precisamos explicar com mais detalhes o pseudocódigo usado por ambas as camadas de enlace. 
O emissor não pode enviar um pacote de dados até que sua camada de rede tenha um pacote de 
dados a enviar. O receptor não pode entregar um pacote de dados à sua camada de rede até que um 
frame tenha sido recebido. Caso o protocolo seja implementado como um processo de software, 
precisamos introduzir o conceito de eventos nesse protocolo. O processo no emissor está cons-
tantemente em execução; não acontece nada até que haja uma solicitação da camada de rede. O 
processo no receptor também está constantemente em execução, mas nada acontece até a chegada 
de uma notificação da camada física. Ambos os processos estão constantemente em execução, pois 
eles não sabem quando os eventos correspondentes ocorrerão.
SEÇÃO 11.4 CANAIS SEM RUÍDO 313
314 CAPÍTULO 11 CONTROLE DO ENLACE DE DADOS
Algoritmo 
O Algoritmo 11.1 ilustra o pseudocódigo no lado do emissor.
Algoritmo 11.1 Algoritmo no emissor para o Protocolo mais Simples Possível
1 while(true) // Repetir indefinidamente
2 {
3 WaitForEvent(); // Fica inativo até a ocorrência de um evento
4 if(Event(RequestToSend)) // Existe um pacote a ser enviado
5 {
6 GetData();
7 MakeFrame();
8 SendFrame(); // Envia o frame
9 }
10 }
Análise O algoritmo implementa um loop infinito, o que significa que as linhas 3 a 9 são re-
petidas indefinidamente. O algoritmo é dirigido por eventos, ou seja, ele fica adormecido (linha 
3) até que um evento o desperte (linha 4). Isso significa que pode haver um tempo indefinido 
entre a execução das linhas 3 e 6. Quando ocorre um evento, uma solicitação da camada de rede, 
as linhas 6 a 8 são executadas. O programa repete então o loop e adormece novamente na linha 
3 até a ocorrência de um evento. Escrevemos um pseudocódigo para o processo principal. Não 
mostramos nenhum detalhe para os módulos GetData, MakeFrame e SendFrame. GetData() 
pega um pacote da camada de rede, MakeFrame() acrescenta cabeçalho e flags delimitadores ao 
pacote de dados para criar um frame e SendFrame() transmite o frame pela camada física para 
transmissão.
O Algoritmo 11.2 exibe o pseudocódigo no lado do receptor.
Algoritmo 11.2 Algoritmo no receptor para o Protocolo mais Simples Possível
1 while(true) // Repete indefinidamente
2 {
3 WaitForEvent(); // Fica inativo até a ocorrência de um 
evento
4 if(Event(ArrivalNotification)) // Chegou um Frame de dados
5 {
6 ReceiveFrame();
7 ExtractData();
8 DeliverData(); // Entrega dados à camada de rede
9 }
10 }
Análise Esse algoritmo apresenta o mesmo formato do Algoritmo 11.1 exceto pelo sen-
tido dos frames e dados ser voltado para cima. O evento aqui é a chegada de um frame de 
dados. Após a ocorrência do evento, a camada de enlace recebe o frame da camada física 
usando o processo ReceiveFrame(), extrai os dados do frame pelo processo ExtractData() e 
entrega os mesmos para a camada de rede usando o processo DeliverData(). Aqui, também 
temos um algoritmo dirigido por eventos, pois ele não sabe quando um novo frame de dados 
chegará.
Exemplo 11.1
A Figura 11.7 mostra um exemplo de comunicação usando esse protocolo. Ele é muito simples. O emis-
sor envia uma seqüência de frames sem mesmo pensar no receptor. Para enviar três frames, ocorrem 
três eventos no lado do emissor e três eventos no lado do receptor. Note que os frames de dados são 
indicados por retângulos inclinados; a altura do retângulo define a diferença no tempo de transmis- 
são entre o primeiro e o último bit do frame.
Figura 11.7 Diagrama de fluxo de dados para o Exemplo 11.1
Tempo Tempo
Frame 
Frame 
Frame 
Emissor Receptor
Solicitação
Solicitação
Solicitação
Chegada
Chegada
Chegada
A B
Protocolo Stop-and-Wait
Se os frames de dados chegarem ao receptor de forma mais rápida que possam ser processados, 
os frames têm de ser armazenados em memória até serem usados. Normalmente, o receptor não 
tem espaço de armazenamento suficiente, especialmente se estiver recebendo dados de várias 
fontes simultaneamente. Isso pode resultar no descarte de frames ou em negação de serviço. 
Para evitar que o receptor fique sobrecarregado com frames em excesso, precisamos, de alguma 
forma, informar o emissor para diminuir o ritmo da transmissão. Deve existir interação entre o 
receptor e o emissor (feedback).
O protocolo que discutiremos agora é denominado Protocolo Stop-and-Wait, pois o emis-
sor envia um frame, aguarda até receber confirmação do receptor (OK para prosseguir) e então 
envia o próximo frame. Ainda temos comunicação unidirecional para os frames de dados, mas 
frames ACK auxiliares (tokens simples de confirmação) trafegam na outra direção. Acrescenta-
mos o controle de fluxo ao nosso protocolo anterior.
Projeto
A Figura 11.8 ilustra o mecanismo. Comparando-se essa figura com a Figura 11.6, podemos 
notar o tráfego no canal direto (do emissor para o receptor) e do canal inverso. A qualquer mo-
mento, há um frame de dados no canal direto ou um frame ACK no canal inverso. Precisamos, 
então, de um link half-duplex.
Algoritmos
O Algoritmo 11.3 é implementado no lado do emissor.
SEÇÃO 11.4 CANAIS SEM RUÍDO 315
316 CAPÍTULO 11 CONTROLE DO ENLACE DE DADOS
Figura 11.8 Projeto do Protocolo Stop-and-Wait
Emissor
Frames de dados 
Enlace
Física
Rede
Recebe
frame
Obtém os dados
Envia
frame
Enlace
Física
Rede
frame ACK
Evento:
Solicitação da 
camada de rede
Repetir indefinidamente
Algoritmo para o lado do emissor
Evento:
Notificação da
camada física
Evento: Notificação da
camada física
Repetir indefinidamenteAlgoritmo para o lado do receptor
Receptor
Recebe 
frame
Envia
frame
Entrega
os dados
Algoritmo 11.3 Algoritmo para o Protocolo Stop-and-Wait no emissor
1 while(true) // Repete indefinidamente
2 canSend = true // Permite que o primeiro frame parta
3 {
4 WaitForEvent(); // Fica inativo até a ocorrência de um 
evento
5 if(Event(RequestToSend) AND canSend)
6 {
7 GetData();
8 MakeFrame();
9 SendFrame(); // Envia o frame de dados
10 canSend = false; // Não pode enviar até a chegada de um ACK
11 }
12 WaitForEvent(); // Fica inativo até a ocorrência de um 
evento
13 if(Event(Arrival 
Notification)
// Chegou uma confirmação (ACK)
14 {
15 ReceiveFrame(); // Recebe o frame ACK
16 canSend = true;
17 }
18 }
Análise Aqui ocorrem dois eventos: uma solicitação da camada de rede ou uma notificação de chegada da 
camada física. As respostas a esses eventos devem se alternar. Ou seja, após um frame ser enviado, o algorit-
mo tem de ignorar qualquer outra solicitação da camada de rede até que o frame anterior seja confirmado. Sa-
bemos que dois eventos de chegada não podem acontecer um após o outro, pois o canal é isento de erros e 
não duplica os frames. As solicitações da camada de rede, entretanto, podem acontecer uma após a outra 
sem um evento de chegada entre elas. Precisamos, de alguma forma, impedir o envio imediato do frame 
de dados. Embora existam vários métodos, usamos uma variável simples denominada canSend, que pode 
assumir os valores falso ou verdadeiro. Quando um frame é enviado, a variável fica em falso para indicar 
que uma nova solicitação da rede não pode ser enviada até que canSend seja verdadeira. Quando for re-
cebido um ACK, canSend fica no estado verdadeiro para permitir o envio do próximo frame.
O Algoritmo 11.4 mostra o pseudocódigo para o lado do receptor.
Algoritmo 11.4 Algoritmo para o Protocolo Stop-and-Wait no receptor
1 while(true) // Repete indefinidamente
2 }
3 WaitForEvent(); // Fica inativo até a ocorrência de um 
evento
4 if(Event(ArrivalNotification)) // Chegou um frame de dados
5 {
6 ReceiveFrame();
7 ExtractData();
8 Deliver(data); // Entrega os dados para a camada de 
rede
9 SendFrame(); // Enviar um frame ACK
10 }
11 }
Análise Esse algoritmo é muito parecido com o Algoritmo 11.2, com uma diferença. Após chegar um 
frame de dados, o receptor envia um frame ACK (linha 9) para confirmar o recebimento e permitir ao 
emissor o envio do frame seguinte.
Exemplo 11.2
A Figura 11.9 mostra um exemplo de comunicação usando esse protocolo. Ele é muito simples. 
O emissor envia um frame e aguarda confirmação do receptor. Quando um ACK chega, o emissor envia 
o próximo frame. Observe que o envio de dois frames no protocolo envolve o emissor em quatro eventos 
e o receptor em dois.
Figura 11.9 Diagrama de fluxo de dados para o Exemplo 11.2
Emissor
A
Solicitação
Solicitação
Chegada
Chegada
Chegada
Chegada
Tempo Tempo
Frame 
ACK
Receptor
B
Frame 
ACK
• 
• 
•
SEÇÃO 11.4 CANAIS SEM RUÍDO 317
	Controle do enlace de dados
	Framing
	Controles de fluxo e erros
	Protocolos
	Canais sem ruído