Uma Dúvida: Alguém Ajuda?

Eu sei que mais pra frente, durante a leitura do livro, eu vou descobrir isso, mas a curiosidade veio com vontade e coloco aqui uma dúvida que tive. Quem sabe uma das minhas leitoras não me responde: a parte que vou começar a estudar a partir de agora, e sobre a qual vou escrever aqui, é a subcamada de controle de acesso ao meio, usada nas redes de difusão.

Controle de acesso ao meio, em inglês, vira medium access control, que é abreviado para MAC.

Aí vem a dúvida: esta sigla tem alguma coisa a ver com o número MAC das placas de rede ou são apenas homônimos?

Índice de artigos sobre a camada de Enlace de Dados

Com o término dos artigos sobre a camada de enlace de dados voltados para redes ponto-a-ponto, segue aqui um índice para os artigos que publiquei sobre o assunto. Daqui em diante teremos artigos sobre a subcamada de controle de acesso ao meio, existente nas redes de difusão.

  • Conexão entre equipamentos na camada de enlace de dados
  • Estrutura dos quadros da camada de enlace de dados
  • Checagem de erros
  • Distância de Hamming
  • Como a camada de enlace de dados tenta corrigir erros de transmissão
  • Confirmando o recebimento de pacotes
  • Taxa de envio de pacotes
  • O Protocolo PPP

    E se você não lembra o que são redes ponto-a-ponto e redes de difusão, já publiquei um artigo sobre o assunto.

    Por fim, uma lembrança a todas as minhas leitoras: se você acha que o blog Vovó Viu a Rede te ajuda a aprender alguma coisa de útil e gosta de voltar sempre aqui, peço que compre alguma coisa no Submarino clicando no banner que está ali na coluna da direita ou em qualquer outro link para lá que eu postar por aqui. Fazendo assim eu ganho uma comissão e você ajuda a garantir um extra pro meu Natal.

  • O Protocolo PPP

    O protocolo Ponto-a-Ponto talvez seja o mais usado atualmente no nível da camada de enlace de dados, tendo em vista que toda a internet é baseada nele para poder fazer os equipamentos se comunicarem. E aqui não falo apenas da comunicação entre dois roteadores no meio do caminho entre seu computador e o da sua prima que está no Japão. Ele trabalha também na conexão que há entre sua casa e o seu provedor de acesso à internet.

    Basicamente, ele tem recursos que permitem a detecção de erros de transmissão; um subprotocolo chamado LCP (Link Control Protocol - Protocolo de Controle de Enlace) que é usado para ativar e desativar linhas de transmissão, testá-las e negociar opções de funcionamento; e um subprotocolo chamado NCP (Network Control Protocol - Protocolo de Controle de Rede) que é usado para fazer com que a camada de enlace de dados "converse" com a camada de rede.

    Quanto ao NCP, existem vários tipos dele, cada um sendo usado para trabalhar em conjunto com um determinado protocolo correspondente na camada de rede.

    ***


    Links interessantes:
  • Veja aqui o que já foi publicado no Vovó Viu a Rede sobre a camada de enlace de dados.

  • Taxa de envio de pacotes

    Quando se fala que a camada de enlace de dados do transmissor aguarda uma confirmação de que o pacote enviado foi realmente recebido, talvez tenha-se a impressão de que ela interrompe o seu trabalho e fica aguardando uma reposta. Eu também pensava assim, até começar a estudar o assunto mais a fundo.

    Se a coisa funcionasse deste jeito, com certeza as transferências demorariam muito mais para terminar. Tome os números fictícios abaixo (eles são fictícios porque na verdade as durações reais são bem menores):

    Tempo para o transmissor despachar um pacote: 1 segundo
    Tempo para o pacote chegar no destino: 1 segundo
    Tempo para o receptor ver se o pacote chegou ok: 1 segundo
    Tempo para o receptor despachar a confirmação: 1 segundo
    Tempo para a confirmação chegar no transmissor: 1 segundo
    Tempo para o transmissor processar a confirmação: 1 segundo

    Note que o tempo total do processo de transmitir um único pacote é de 6 segundos. Se a camada de enlace de dados do transmissor interrompesse seu trabalho para aguardar a confirmação, seria necessário um minuto para enviar 10 pacotes. Além disso, repare que, se assim acontecesse, enquanto uma etapa estivesse acontecendo, as outras estariam ociosas. Puro desperdício. Veja na tabela abaixo, por exemplo, que dez segundos seriam suficientes apenas para despachar dois pacotes e receber a confirmação de um.



    E ainda há um agravante: se por um acaso o primeiro pacote não chegasse, o transmissor ficaria parado até alcançar o tempo limite de espera. Se este tempo fosse de 10 segundos, estes seriam 10 segundos desperdiçados. Uma conta desta em larga escala é, sem dúvida, um desastre.

    ***


    O que acontece na verdade é que, assim que o transmissor despacha o primeiro pacote, começa a trabalhar no segundo. Quando o segundo está pronto, ele já o despacha, antes mesmo de receber a resposta do primeiro. Como os tempos de trabalho em cada etapa são os mesmos, enquanto despacha o segundo pacote, o primeiro está sendo transportado para o receptor. Veja na tabela abaixo que, desta forma, os mesmos dez segundos seriam suficientes para despachar todos os pacotes e receber a confirmação de cinco.



    ***


    A cada pacote despachado, o transmissor inicia um "cronômetro" para controlar o tempo de espera para que uma confirmação chegue. Se a confirmação não chega dentro deste limite, o pacote perdido é reenviado, e após ele, o próximo da seqüência ainda não enviado. Veja a tabela abaixo para ver como funciona isso, imaginando que o tempo de espera seja de sete segundos.



    Repare: no primeiro segundo o transmissor despachou o pacote 1, que se perdeu ao ser transportado. Só que o transmissor não sabe que o pacote 1 se perdeu, pois o tempo de espera ainda não acabou. Ainda assim, ele continua despachando os outros pacotes, que seguem seu curso normal. Depois dos sete segundos de espera, ele vê que não recebeu a confirmação do pacote 1 e então o despacha novamente. Em seguida, continua com o pacote 9, pois já tinha despachado até o 8.

    ***


    Há ainda alguns protocolos ainda mais espertos, que "raciocinam" da seguinte forma: o transmissor manda o primeiro pacote, o segundo, o terceiro, e por aí vai. Se a confirmação chegar fora de ordem, ele automaticamente reenvia o pacote cuja confirmação não chegou (e supostamente deveria ter chegado primeiro), mesmo que o tempo de espera para ele não tenha terminado. Veja a tabela abaixo para entender melhor (note que logo após receber a confirmação do pacote 2 ele reenvia o pacote 1):



    ***


    Por fim, deixo um exercício para minhas leitoras: vimos no início do artigo que se a camada de enlace de dados esperasse a confirmação de um pacote para mandar o próximo, todo o processo de envio de 10 pacotes levaria um minuto. Pergunto: quanto tempo levaria para mandar os mesmos 10 pacotes no "modo rápido", ilustrado na segunda tabela?

    ***


    Links interessantes:
  • Veja aqui o que já foi publicado no Vovó Viu a Rede sobre a camada de enlace de dados.

  • Confirmando o Recebimento de Pacotes

    Quando há algumas semanas eu publiquei um artigo que trata da conexão entre equipamentos na camada de enlace de dados, falei nele sobre a confirmação do recebimento dos pacotes: sempre que um pacote é enviado, a camada de enlace de dados do transmissor aguarda o recebimento de uma confirmação. Se depois de um tempo esta confirmação não chegar ele manda o pacote novamente.

    Pois bem, andei descobrindo umas coisas interessantes sobre este trabalho de confirmar o recebimento dos pacotes e acho que vale a pena compartilhar.

    Apesar de terem tamanhos variados, os pacotes da camada de enlace de dados seguem uma organização padrão: eles têm espaços para a colocação de flags de marcação de início e fim, espaços para os dados a serem transportados, e todo o cabeçalho com informação de numeração do pacote e afins.

    Quando a camada de enlace de dados receptora envia uma confirmação de recebimento de um pacote, esta combinação vai na forma de um novo pacote. Não é questão de apenas uns bits indo e voltando, é um pacote inteiro, cheio de espaços vazios. Isso não está com cara de desperdício? Com certeza.

    Como a camada de enlace de dados geralmente trabalha nos dois sentidos, enviando e recebendo dados quase o tempo todo, os cabeçalhos dos pacotes incluem não apenas espaços para informar os dados relativos à entrega do pacote, mas também possuem campos para confirmar o recebimento de um outro pacote qualquer, matando, assim, dois coelhos com uma cajadada só.

    Assim, quando recebe um pacote, a camada de enlace de dados não envia uma resposta automaticamente. Ela aguarda um tempo para ver se não vai ter que enviar algo. Se tiver que enviar um pacote com dados, a confirmação do outro vai junto.

    E é claro que ela não vai ficar esperando pra sempre: se assim fosse, o cara que está esperando a confirmação vai achar que o pacote se perdeu no caminho e vai mandar outro. Logo, se mesmo aguardando um tempo não surgirem dados para serem enviados, a camada de enlace de dados manda um pacote vazio, só com a confirmação.

    É como se numa empresa, quando um departamento enviasse um ofício para o outro, ele aproveitasse e escrevesse também que "a propósito, acuso o recebimento do vosso ofício 123". O que está sendo enviado não precisa ter algo a ver com o que está sendo confirmado. O que está em jogo aqui é apenas a economia de tráfego (ou de envelopes, no caso da empresa).

    ***


    Naquele outro artigo, que citei aí em cima, eu comparei o aviso de recebimento da camada de enlace de dados com o AR dos Correios, mas depois de estudar um pouco mais e descobrir estas coisas que acabei de falar, eu vi que a camada de enlace de dados vai um pouco mais além.

    Se o AR funcionasse como a camada de enlace de dados, ele seria assim: ao receber uma correspondência com AR, a folhinha que volta para o remetente não ficaria com o carteiro para ser devolvida. Ao contrário, ela ficaria com o destinatário.

    O destinatário só mandaria o comprovante de volta quando uma destas duas situações ocorressem:
    - Ele tem alguma coisa para mandar, e então manda o comprovante junto;
    - Ele já reteve o comprovante tempo demais, e então manda de volta assim mesmo, para que o remetente não pense que sua correspondência se perdeu.

    ***


    Há ainda um outro detalhe interessante quanto à velocidade e à taxa de envio de pacotes, mas isso já é assunto para um outro artigo, que pintará por aqui durante a semana que vem.

    ***


    Links interessantes:
  • Veja aqui o que já foi publicado no Vovó Viu a Rede sobre a camada de enlace de dados.

  • Como a camada de enlace de dados tenta corrigir erros de transmissão

    Existem alguns protocolos da camada de enlace de dados que têm a capacidade de identificar quando um quadro recebido não chegou corretamente e, além disso, tentam corrigir o erro (e às vezes até conseguem). Para ver como isso funciona, vamos partir para uma metáfora simples.

    Pense que um aluno esteja escrevendo palavras em pedaços de cartolina, entregando para uma professora, que então cola as palavras na parede, para formar uma frase no mural. A professora, ao ler a palavra escrita no pedaço de cartolina, é capaz de identificar se ela foi escrita errada.

    Como ela identifica que uma palavra foi escrita da forma errada? Simples: ela consegue identificar o erro pois existe um número limitado de palavras válidas. Qualquer coisa que não faça parte deste vocabulário denuncia a falha.

    Fácil, não? Pois bem, na camada de enlace de dados a coisa funciona do mesmo jeito: primeiramente, assim como nós, a camada de enlace de dados usa um conjunto limitado de palavras. E partindo deste princípio, para que ela detecte um erro de transmissão basta que receba uma palavra que não faça parte do seu vocabulário.

    ***


    Voltando à metáfora, ao detectar um erro, como a professora faria para descobrir a palavra certa? Também é simples: ele descobriria a palavra certa com base no seu vocabulário, bastando saber qual palavra correta se pode obter mudando o mínimo de letras possível do que está errado, ou seja, descobrindo uma palavra que esteja o mais "perto" possível do que foi recebido. Por exemplo, se ao ler a cartolina a professora se depare com inteligende, ela vai saber que a palavra certa é inteligente, pois ela está apenas a uma letra de distância.

    O mesmo acontece na camada de enlace de dados: para corrigir o erro, ela procura uma palavra correta que esteja o mais próximo possível da palavra errada recebida. (E é aqui que entra o conceito da Distância de Hamming)

    ***


    Mas há casos que isso não é tão fácil. Imagine agora que na cartolina esteja escrito hente ao invés de gente. Como é que a professora vai saber a palavra original? Seria pente? Gente? Rente? Lente? Difícil saber. Para nós, humanos, só o contexto é capaz de responder.

    Entretanto, quando este tipo de coisa acontece na camada de enlace de dados, ainda assim ela faz uma tentativa de corrigir o erro, trocando a palavra errada pela primeira palavra correta que ela conseguir gerar. Claro que ela pode acertar (ufa) ou não (corrigindo o erro gerando outro). Quando esta segunda alternativa acontece, o erro gerado só será detectado nas camadas superiores, o que é equivalente ao nosso "descobrir o erro pelo contexto".

    ***

    De volta à metáfora, pior ainda seria se, onde devesse estar escrito mala, o aluno escrevesse cala. Se nos dois primeiros exemplos o erro gerava uma palavra inválida, este aqui gerou uma palavra que também é correta. Neste caso, a professora não veria que houve um erro. (Sim, eu sei que o contexto faria com que ela identificasse o erro, mas isso não vem ao caso, lembre-se que ela está lendo palavra por palavra, isoladamente).

    Assim acontece na camada de enlace de dados: se uma palavra foi transmitida e no meio do caminho um erro a transformou em outra, também válida, a camada de enlace de dados vai deixá-la passar sem reclamar. Novamente, o erro só será detectado nas camadas superiores.

    ***


    Enfim, o tratamento de erros na camada de enlace de dados pode não ser perfeito, mas ajuda a reduzir um pouco o tempo das transmissões, pois descobre erros a cada parada no caminho entre o transmissor e o receptor.

    Novamente usando a metáfora, se não houvesse este controle de erros de transmissão, é como se a professora não reparasse se as palavras escritas nos pedaços de cartolina estão erradas ou certas, o que faria com que o mural fosse feito errado. Só depois de o mural estar pronto é que os erros seriam detectados, e ele teria que ser refeito do zero.

    Do mesmo modo, se a camada de enlace de dados não fizesse este trabalho e houvesse um erro de transmissão, ele só seria detectado quando todos os pacotes fossem recebidos e repassados para uma das camadas superiores. E aí, ao detectar um erro, as camadas superiores pediriam toda a informação de novo, gerando mais tráfego.

    ***


    Links interessantes:
  • Veja aqui o que já foi publicado no Vovó Viu a Rede sobre a camada de enlace de dados.

  • Distância de Hamming

    Esta explicação aqui fazia parte de um outro post que estou escrevendo. Mas resolvi separar as duas coisas diminuir um pouco o tamanho do outro. Então lá vai.

    ***


    Imagine duas palavras computacionais (feitas de bits): 00111111 e 11111111

    Pergunta fácil para a leitora: qual é a quantidade de bits que é diferente entre estas duas palavras?

    Dois bits, certo? Pois isto é a Distância de Hamming: a quantidade de bits que faz com que duas palavras sejam diferentes uma da outra. Ou melhor: dadas duas palavras, Distância de Hamming é a quantidade de bits que devem ser mudados para que a primeira se transforme na segunda.

    Simples assim.

    ***


    Links interessantes:
  • Veja aqui o que já foi publicado no Vovó Viu a Rede sobre a camada de enlace de dados.

  • Checagem de Erros

    Uma das coisas mais difíceis que encontrei até agora no meu estudo de redes foi o capítulo sobre a checagem de erros nos pacotes da camada de enlace de dados. Tanto que pulei a seção sobre o assunto. Ainda assim, vou explicar aqui pra vocês um método de checagem de erros dos mais comuns: o dígito verificador.

    Com certeza você já ouviu falar dele. Ele está no número da conta no banco, no CPF que você carrega na sua carteira e também nos pacotes da camada de enlace de dados. Seu funcionamento é muito simples: o dígito verificador é o resultado de uma conta que se faz sobre os outros números.

    Um exemplo moleza: imagine um clube, destes que a gente paga uma mensalidade para poder usar a piscina, a academia, passar o dia, coisa e tal. Cada pessoa tem uma carteirinha com um número de sócio, e daí a diretoria do clube decide colocar um dígito verificador neste número.

    Resolvem então que o dígito verificador é a soma dos algarismos do número de sócio, sendo que se a soma passar de dez, os algarismos do resultado são somados de novo, até se conseguir um número com apenas um algarismo. Daí, um sócio de número 431 teria uma carteira de número 4318. E um sócio número 987 teria uma carteira número 9876.

    Pra que serve isso? Serve para que, se alguém aparecer com uma carteira número 1119, o porteiro vai saber que ela é falsa, pois ele vai saber que o dígito verificador certo deveria ser 3.

    Basicamente, é isso. Claro que os métodos para calcular os dígitos verificadores dos documentos que vemos por aí não são tão simples assim. Os de CPF e CNPJ, por exemplo, são intrincadíssimos: você vai multiplicando cada algarismo por certos valores decrescentes, depois soma o resultado, vê quanto falta para chegar em um outro valor, e então diminui este "quanto falta" de mais um outro valor para então achar o dígito verificador. Ou algo parecido e mais difícil que isto.

    Estes dois casos, por acaso, são de conhecimento público, pois são necessários para os desenvolvedores de programas, para que eles criem programas que façam essa verificação, mas outros são secretos, como os dígitos verificadores de contas de banco. Para acertar um destes só por tentativa e erro.

    ***


    Este é, então, um dos vários métodos de checagem de erro que são usados pelos protocolos da camada de enlace de dados. É importante lembrar que com este tipo de checagem a camada de enlace de dados do receptor não tem condições de corrigir o erro, ela apenas vai saber que houve um erro, para então solicitar o reenvio daquele pacote.

    Existem outros métodos de checagem de erro que, com o uso de técnicas de redundância, permitem que o receptor tente - e muitas vezes consiga - não apenas descobrir que houve um erro, mas também corrigi-lo.

    Se alguma leitora souber de algum site que tem alguma explicação decente destes métodos, e quiser compartilhar, agradecerei efusivamente.

    ***


    Links interessantes:
  • Algoritmo para cálculo do dígito verificador do CPF
  • Algoritmo para cálculo do dígito verificador do CNPJ
  • Veja aqui o que já foi publicado no Vovó Viu a Rede sobre a camada de enlace de dados.