Redes - Capitulo 3 Kurose

EXERCÍCIOS (CAPÍTULO 3)

R3. Número de porta de fonte: y. Número de porta do destino: x.

R4. Um desenvolvedor de aplicação pode não querer que o seu aplicativo use o controle de congestionamento do TCP, pois ele pode estrangular a taxa de envio do aplicativo em momentos de congestionamento. Além disso, alguns aplicativos não precisam de transferência confiável de dados, que é fornecido pelo TCP.

R5. Vídeo e áudio toleram certas perdas de informação, característica do UDP.

R6. Sim, o desenvolvedor da aplicação pode colocar a transferência de dados confiável para o protocolo da camada de aplicação.

R7. Sim, os dois segmentos serão direcionados para o mesmo socke no Computador Ct. Para cada segmento recebido, o sistema operacional providencia o processo com os endereços IP para determinar a origem dos segmentos individuais.

R8. Para cada conexão, o servidor cria uma conexão socket separada, quando o Computador C recebe a conexão, ele examina quatro campos diferentes, endereço IP de origem, numero da porta de origem, endereço IP de destino, e numero da porta de destino para determinar quem fez a solicitação. O identificador para A e B tem 80 como porta de destino, mas tem diferentes numeros de IP de origem.

R9. Para saber se o pacote que chega contém uma nova informação ou se é uma retransmissão.

R10. Para tratar perdas.

R11. Ainda seria necessário. O fato do atraso ser constante e conhecido só implica que agora o remetente sabe que o pacote ou o ACK (ou NACK) foi perdido. Antes, o ACK (ou NACK) ainda poderia estar sendo enviado quando o time-out expirasse.

R12. Não foi possivel fazer a execução do applet, a tentativa se deu em dois computadores diferentes, sendo feitas todas as atualizações necessárias, e ainda assim sem obtenção de sucesso.

R13. Idem 12.

R14.

(a) Falso.

R15.

(a) 20 bytes.

(b) ACK 90.

R16. Serão enviados 3 segmentos. 1° segmento: seq = 42 (correspondente ASCII do caractere ‘c’) e ACK = 79; 2° segmento: seq = 79 e ACK = 43; 3° segmento: seq = 43 e ACK = 80.

R18. Falso, o valor de ssthresh é ajustado para a metade do seu valor atual.

P6. Se o remetente estiver no estado “Esperar chamada 1 de cima” e o destinatario estiver no estado “Esperar 1 de baixo”. O remetente envia um pacote com numero de sequência 1 e muda para “esperar por ACK ou NAK 1” esperando por um ACK ou NAK, e se o destinatario recebe um pacote com sequencia 1 corretamente, envia um ACK, e muda para “Espera 0 de baixo” esperando agora um pacote de sequencia 0, mas o pacote ACK esta corrompido, quando o remetente manda um ACK corrompido, reenvia o pacote de sequencia 1, no entanto o destinatario esta esperando por 0 e então envia NAK, assim o remetente sempre estara enviando pacotes com sequencia 1, e o destinatario continuara enviando NAK’s, permanecendo no mesmo estado.

P7. Os pacotes ACK não requerem um número de sequência para detectar um ACK duplicado. Um ACK duplicado é claro para o receptor do rdt3.0, uma vez que quando um ACK é recebido, ele já é transmitido para o próximo estado.

P8. O time-out no rdt2.2 acrescenta a possibilidade de pacotes duplicados no fluxo de dados do remetente ao destinatário. Por isso, o receptor rdt2.2 funcionará como o receptor rdt3.0.

P9.

P11. Ainda funcionaria, desde que a retransmissão acontecesse se o pacote recebido com erros realmente se perdesse.

P15. Sim, isso faz com que o remetente mande dados de forma pipeline no canal, um possivel problema é se o segmento de dados se perde no canal , então o remetente nao ira reenviar esses segmentos, a menos que haja algum mecanismo de recuperação de perda.

P25. a) No segundo segmento o numero de sequencia é 197, o numero da porta de origem é 302 e o de destino é 80.

b) Se o primeiro segmento chega antes do segundo, no reconhecimento do primeiro segmento de chegada, o numero de reconhecimento é 197, o numero da porta de origem é