Exercícios Resolvidos capítulo 3 do kurose

Exercícios Resolvidos capítulo 3 do kurose

UNIVERSIDADE ESTÁCIO DE SÁ

FACULDADE DE ENGENHARIA

CURSO DE ENGENHARIA ELÉTRICA

CAMPUS PRAÇA XI

Redes de Computadores I

          1. Professor Jorge Bitencourt

Exercícios do Capítulo 3 do Livro Redes de Computadores (Kurose)

Data: 25 de Novembro de 2009

Aluno: Teo Pires Marques
Matricula: 200602116859

Solução:

a,b,c,d)

Servidores

Número da porta de origem

Número da posta de destino

A para S

467

23

B para S

513

23

S para A

23

467

S para B

23

513

e) sim.

f) não.

Solução:

Suponhamos que os endereços dos IP's dos Hosts A, B e C são a, b, c.

Para o host A: porta de origem=80, endereço IP origem = b, porta destino=26145, IP destino=a

Para o host C, processo esquerda, porta de origem=80, endereço IP origem=b, porta destino=7532, IP destino=c

Para host C, processo direita: Porta de origem=80, endereço IP origem=b, porta destino=26145,IP destino=c.

Solução:

Complemento de 1 = 1 1 1 0 1 1 1 0

Para detectar erros, o receptor adiciona as quatro palavras (as três palavras originais e oschecksum). Se a soma contém um zero, o receptor sabe que ocorreu um erro.

Todos um bit erros serão detectados, mas dois bits de erro não podem ser detectado (por exemplo, se o último dígito da primeira palavra é convertido para um 0 e o último dígito da segunda palavra é convertido para um 1).

Solução:

Supondo que o remetente está em estado de "espera por 1 de cima" e o receptor em estado de "Espera por 1 de baixo." O remetente envia um pacote com número de série 1, e as transições para "aguarde por ACK ou NAK 1". Supondo agora que o receptor recebe o pacote com seqüência número 1 corretamente, e envia um ACK, e as transições de estado "Espere por 0 a partir de baixo", à espera de um pacote de dados com o número de seqüência 0. No entanto, o ACK é corrompido. Quando o remetente rdt2.1 recebe o ACK corrompido, ele reenvia o pacote com seqüência número 1. No entanto, o receptor está esperando por um pacote com número de seqüência 0 e como sempre envia um NAK quando não recebe um pacote com número de seqüência 0. O remetente terá sempre que enviar um pacote com seqüência número 1, e o receptor responderá sempre NAK para esse pacote. Nunca irá avançar frente este estado.

Solução:

Consideremos o porquê precisamos de seqüência de números no primeiro lugar. Vimos que o remetente precisa da seqüência de números para que o receptor possa dizer se umpacote de dados é um “duplicado” de um pacote de dados já recebidos. No caso de ACKs, oremetente não precisa desta informação (ou seja, um número de seqüência em um ACK) para informar ao detectar um ACK duplicado. Um ACK duplicado é evidente para o receptor rdt3.0, desde quando ele tem ACK recebido, o original é transferido para o próximo estado. O ACK duplicado não é o das necessidades do remetente e, portanto, é ignorado pelo remetente rdt3.0.

Solução:

O lado remetente do protocolo rdt3.0 difere do lado do remetente do protocolo 2.2 em quetimeouts foram adicionados. Vimos que a introdução de timeouts acrescenta opossibilidade de pacotes duplicados para o remetente-a-receptor fluxo de dados. No entanto, oreceptor no protocolo rdt.2.2 já pode manipular pacotes duplicados. (Receiver-sideduplicados em rdt 2.2 surgiriam se o receptor enviou um ACK que foi perdido, e o remetenteentão retransmitir os dados antigos). Daí o receptor no protocolo rdt2.2 também irá funcionar como o receptor no protocolo RDT 3.0.

Solução:

Suponha que o protocolo já está em funcionamento há algum tempo. O remetente está em estado de "espera para a chamada de cima "(canto superior esquerdo) e o receptor está no estado"espera por 0 de baixo ". Os cenários de dados corrompidos e ACK corrompidos são mostrados na Figura:

Solução:

Aqui, vamos adicionar um timer, cujo valor é maior do que o tempo conhecido de propagação.Adicionamos um evento de “tempo limite” para o "Aguardar ACK ou NAK0" e "aguardar por ACK ou NAK1 ". Se o evento de timeout (tempo esgotado) ocorre, o pacote mais recentemente transmitido é retransmitido. Vamos ver por que este protocolo irá ainda trabalhar com o receptor rdt2.1. Suponha que o limite é causada por um pacote de dados perdidos, ou seja, um pacote sobre o remetente a canal receptor. Neste caso, o receptor nunca recebeu a transmissão anterior e, do ponto de vista do receptor, se o tempo limite de retransmissão é recebido, é exatamente como se o tempo da transmissão original está sendo recebida.Suponha agora que um ACK é perdido. O receptor irá eventualmente retransmitir opacotes em um tempo limite. Mas uma retransmissão é exatamente a mesma ação que se tomequando um ACK é ilegível. Assim, a reação do remetente é a mesma que com uma perda, como com um ACK ilegível. O receptor 2,1 rdt já pode lidar com o caso de um ACK ilegível.

Solução:

O protocolo funcionaria, uma vez que uma retransmissão seria o que aconteceria se houvessempacotes recebidos com erros que realmente foram perdidos (e o receptor nunca sabe qual desses eventos vai ocorrer). Para começar, a questão mais sutil por detrás desta questão, tem que existir “tempo limite” para ocorrer. Neste caso, se cada cópia extra do pacote é ACK então cada ACK recebido extra faz com que outra cópia extra do atual pacote seja enviado, em um número n de vezes, n pacotes são enviados, aumentando sem limite de n tendendo ao infinito.

Solução:

Solução:

Num protocolo NAK, a perda de pacotes x só é detectado pelo receptor quando pacotex+1 é recebido. Isto é, os receptores recebe x-1 e x+1 e, em seguida, apenas quando x+1 érecebido, o receptor percebe que x foi perdido. Se há uma longa demora entre atransmissão de x e a transmissão de x+1, então será um longo tempo até que x possa serrecuperado. Por outro lado, se os dados estão sendo enviados, muitas vezes, a recuperação em um esquema NAK pode acontecer rapidamente. Além disso, se os erros são freqüentes, seguidos NAKs são apenas enviados ocasionalmente (quando necessário), e ACK nunca são enviados, isso gera uma redução significativa no feedback no NAK-only apenas no caso sobre o ACK-only caso único.

Solução:

Leva 8 microssegundos (ou 0,008 milissegundos) para enviar um pacote.

para que o remetente utilize 90 por cento, devemos ter:                               util = 0,9 = (0.008n) / 30,016ou n aproximadamente 3377 pacotes.

Solução:

Em nosso protocolo de transferência de dados confiável GBN, o remetente mantem o envio de pacotes até que recebe um NAK. O NAK é gerado para n pacote apenas e se todos os pacotes até n - 1 forem recebidos corretamente. Isto é, n é sempre o menor número de seqüência de um pacote que ainda está para ser recebido. Quando receber um NAK para n pacote, ele simplesmente começa termina novamente a partir n pacotes. Não existe um número máximo de pacotes não confirmados no canal. Observe o remetente realmente não sabe quantos pacotes são desconhecidos. Se o número de seqüência atual, se K e o NAK passado foi de n pacotes, então pode haver tantos como k - (n - 1) os pacotes não confirmados no canal.Observe também que um receptor não sabe que n pacote está faltando até um pacote com ummaior número de seqüência for recebido! Assim, quando a taxa de dados é baixa(isto é, uma grande quantidade de tempo entre as transmissões de pacotes), levará mais tempo para um receptor perceber um pacote que falta do que quando a taxa de dados é alta.

Solução:

O remetente irá esperar até receber um ACK para um par de mensagens (seqnum e seqnum +1) antes de passar para o próximo par de mensagens. Os pacotes de dados tem um campo de dados e realizam um número de duas seqüência de bits. Ou seja, a seqüência válida os números são 0, 1, 2 e 3. ACK mensagens transportam o número de seqüência do pacote de dados que eles estão reconhecendo. O FSM para o emissor e o receptor são mostrados na Figura. Vide o Estado remetente registros se (i) não foram recebidos ACKs para o par atual, se (ii) um ACK paraseqnum (apenas) foi recebido, ou um ACK para seqnum +1 (apenas) foi recebido. Com este valor, vamos supor que o seqnum é inicialmente 0, e que o remetente enviou o primeiroduas mensagens de dados (para obter os dados de ida). Vide cronograma de rastreamento:

Remetente

Receptor

fazer par (0,1)

enviar pacote 0

0 pacote

1 pacote enviado

1 pacote recebido

1 pacote no buffer

Enviando ACK 1

Receber ACK 1

(timeout)

pacote reenviar 0

0 pacote recebido

Entregar par (0,1)

Enviar ACK 0

receber ACK 0

Solução:

Esse problema é uma variação sobre o parar e esperar um simples protocolo (rdt3.0).

Porque o canal pode perder as mensagens e porque o remetente pode enviar uma mensagem que um dos receptores já recebeu (seja por causa de um timeout prematuro ou porque o outroreceptor ainda não recebeu os dados corretamente), números de seqüência são necessários. Como em rdt3.0, um número de seqüência 0-bits será suficiente.O emissor e o receptor FSM são mostrados na Figura do problema anterior. Neste problema, o Estado do remetente indica se o remetente tem recebido um ACK de B (apenas), a partir de C (apenas) ou nem C nem B. O Estado receptor indica qual o número de seqüência do receptor é esperado.

Comentários