Universidade Federal do Cear Centro de Tecnologia Departamento de Engenharia de Teleinformtica - DETI

Redes de Computadores I (TI075) 2011.1

Aula #25 Camada de Transporte (ii)

Danielo G. Gomes
danielo@ufc.br

Fortaleza, 19/5/2011

Contedo do Captulo 3

3.1 Servios da camada de transporte 3.2 Multiplexao e demultiplexao 3.3 Transporte no orientado para conexo: UDP 3.4 Princpios da transferncia confivel de dados

3.5 Transporte orientado para conexo: TCP

estrutura do segmento transferncia confivel controle de fluxo gerenciamento de conexes

3.6 Princpios de controle de congestionamento 3.7 Controle de congestionamento do TCP

2/30

Principles of Reliable data transfer

important in app., transport, link layers toptop-10 list of important networking topics!

3/30

Principles of Reliable data transfer

important in app., transport, link layers toptop-10 list of important networking topics!

characteristics of unreliable channel will determine complexity of reliable data transfer protocol (rdt)
4/30

Principles of Reliable data transfer

important in app., transport, link layers toptop-10 list of important networking topics!

characteristics of unreliable channel will determine complexity of reliable data transfer protocol (rdt)
5/30

Reliable data transfer: getting started

rdt_send(): called from above, (e.g., by app.). Passed data to deliver to receiver upper layer deliver_data(): called by rdt to deliver data to upper

send side

receive side

udt_send(): called by rdt, to transfer packet over unreliable channel to receiver

rdt_rcv(): called when packet arrives on rcv-side of channel

6/30

Transferncia confivel: o ponto de partida

Iremos: desenvolver incrementalmente os lados transmissor e receptor de um protocolo confivel de transferncia de dados (rdt) considerar apenas fluxo unidirecional de dados

mas info de controle flui em ambos os sentidos!

Usar mquinas de estados finitos (FSM) p/ especificar os protocolos transmissor e receptor

evento causador da transio de estado aes executadas na transio de estado

estado: neste estado o prximo estado determinado unicamente pelo prximo evento

estado 1

evento aes

estado 2

7/30

rdt1.0: transferncia confivel sobre canais

confiveis

canal de transmisso perfeitamente confivel

no h erros de bits no h perda de pacotes

FSMs separadas para transmissor e receptor:

transmissor envia dados pelo canal subjacente receptor l os dados do canal subjacente
8/30

rdt2.0: canal com erros de bits

canal subjacente pode trocar valores dos bits num pacote
lembre-se: checksum UDP pode detectar erros de bits lembre-

a questo: como recuperar esses erros?

reconhecimentos (ACKs): receptor avisa explicitamente ao transmissor que o pacote foi recebido corretamente reconhecimentos negativos (NAKs): receptor avisa explicitamente ao transmissor que o pacote tinha erros transmissor reenvia o pacote ao receber um NAK

novos mecanismos no rdt2.0 (em relao ao rdt1.0): rdt1.0):

deteco de erros retorno ao transmissor: mensagens de controle (ACK,NAK) receptorreceptor->transmissor

9/30

rdt2.0: especificao da FSM

pare e espera Transmissor envia um pacote, e ento aguarda resposta do receptor

10/30

rdt2.0: operao com ausncia de erros

rdt_send(data) snkpkt = make_pkt(data, checksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && isNAK(rcvpkt) Wait for Wait for call from ACK or udt_send(sndpkt) above NAK

rdt_rcv(rcvpkt) && corrupt(rcvpkt) udt_send(NAK) Wait for call from below rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) extract(rcvpkt,data) deliver_data(data) udt_send(ACK) 11/30

rdt_rcv(rcvpkt) && isACK(rcvpkt)

rdt2.0: cenrio de erro

rdt_send(data) snkpkt = make_pkt(data, checksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && isNAK(rcvpkt) Wait for Wait for call from ACK or udt_send(sndpkt) above NAK

rdt_rcv(rcvpkt) && corrupt(rcvpkt) udt_send(NAK) Wait for call from below rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) extract(rcvpkt,data) deliver_data(data) udt_send(ACK) 12/30

rdt_rcv(rcvpkt) && isACK(rcvpkt)

rdt2.0 tem uma falha fatal!

O que acontece se o ACK/NAK for corrompido?
Transmissor no sabe o que se passou no receptor! no pode apenas retransmitir: possibilidade de pacotes duplicados remetente usa ACKs/NAKs ACKs/ p/ ACK/NAK do receptor? E se perder ACK/NAK do remetente? retransmitir, mas pode causar retransmisso de pacote recebido certo!
13/30

Lidando c/ duplicatas:
transmissor inclui nmero de seqncia em cada pacote transmissor retransmite o ltimo pacote se ACK/NAK chegar com erro receptor descarta (no entrega a aplicao) pacotes duplicados

O que fazer?

rdt2.1: transmissor, trata ACK/NAKs corrompidos

14/30

rdt2.1: receptor, trata ACK/NAKs corrompidos

rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq0(rcvpkt) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && (corrupt(rcvpkt) sndpkt = make_pkt(NAK, chksum) udt_send(sndpkt)
Esperar 0 de baixo Esperar 1 de baixo

rdt_rcv(rcvpkt) && (corrupt(rcvpkt) sndpkt = make_pkt(NAK, chksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && not corrupt(rcvpkt) && has_seq1(rcvpkt) sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt)

rdt_rcv(rcvpkt) && not corrupt(rcvpkt) && has_seq0(rcvpkt) sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt)

rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq1(rcvpkt) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt)

15/30

rdt2.1: discusso
Transmissor: no. de seq no pacote bastam dois nos. de seq. (0,1). Por qu? deve verificar se ACK/NAK recebidos esto corrompidos duplicou o no. de estados
estado deve lembrar se pacote corrente tem no. de seq. 0 ou 1

Receptor: deve verificar se o pacote recebido duplicado

estado indica se no. de seq. esperado 0 ou 1

nota: receptor no tem como saber se ltimo ACK/NAK foi recebido bem pelo transmissor

16/30

rdt2.2: um protocolo sem NAKs

mesma funcionalidade do rdt2.1, usando apenas

ACKs ao invs de NAK, receptor envia ACK para ltimo pacote recebido sem erro receptor deve incluir explicitamente no. de seq
do pacote reconhecido

ACKs duplicados no transmissor resultam na

corrente

mesma ao do NAK: retransmisso do pacote

17/30

rdt3.0: canais com erros e perdas

Nova hiptese: canal de transmisso tambm pode perder pacotes (dados ou ACKs)
checksum, no. de seq., ACKs, retransmisses podem ajudar, mas no sero suficientes

Abordagem: transmissor aguarda um tempo razovel pelo ACK

retransmite se nenhum ACK for recebido neste intervalo se pacote (ou ACK) apenas atrasado (e no perdido): retransmisso ser duplicata, mas uso de no. de seq. j cuida disto receptor deve especificar no. de seq do pacote sendo reconhecido requer temporizador
18/30

P: como lidar com perdas?

transmissor espera at ter certeza que se perdeu pacote ou ACK, e ento retransmite desvantagens?

19

19/30