Livros de redes informáticas

UNIVERSIDADE ESTÁCIO DE SÁ

FACULDADE DE ENGENHARIA

CURSO DE ENGENHARIA ELÉTRICA

CAMPUS PRAÇA XI

Redes de Computadores I

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 os

checksum). 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 um

pacote de dados é um “duplicado” de um pacote de dados já recebidos. No caso de ACKs, o

remetente 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 que

timeouts foram adicionados. Vimos que a introdução de timeouts acrescenta o

possibilidade de pacotes duplicados para o remetente-a-receptor fluxo de dados. No entanto, o

receptor no protocolo rdt.2.2 já pode manipular pacotes duplicados. (Receiver-side

duplicados em rdt 2.2 surgiriam se o receptor enviou um ACK que foi perdido, e o remetente

entã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 o

pacotes em um tempo limite. Mas uma retransmissão é exatamente a mesma ação que se tome

quando um ACK é ilegível. Assim, a reação do remetente é a mesma que com uma perda, como com um ACK ilegível. O receptor