Protocolo de transporte em tempo-real (Real- Time Transport Protocol) Definido na RFC 3350 Normalmente usado sobre o UDP Serviços

Transcrição

1 RTP Protocolo de transporte em tempo-real (Real- Time Transport Protocol) Definido na RFC 3350 Normalmente usado sobre o UDP Serviços Identificação do tipo de carga útil (mídia) Números de sequência Estampa de tempo

2 RTP Não possui Controle de fluxo Controle de erros Confirmação Mecanismo de solicitação de retransmissões

3 RTP Posição do RTP na pilha de protocolos (fonte: Tanenbaum)

4 RTP - formato do cabeçalho Formato do cabeçalho RTP (fonte: Tanenbaum)

5 RTP - principais campos Tipo de carga útil (payload type) (7 bits) Indica o algoritmo de codificação usado Número de sequência (16 bits) UDP não possui Usado para detectar pacotes perdidos Aplicação pode usar interpolação Estampa de tempo (32 bits) Indica o instante da amostragem do primeiro octeto no pacote

6 RTP - principais campos Identificador de sincronização da fonte (32 bits) Informa a que fluxo o pacote pertence Usado para multiplexar e demultiplexar vários fluxos de dados em um único fluxo de datagramas UDP

7 RTCP Protocolo de controle de transporte em temporeal (Real-Time Transport Control Protocol) Também definido na RFC 3350 Pacotes RTCP enviados em multicast contém relatórios de remetente e/ou receptor com dados estatísticos Remetente pode mudar a taxa de transmissão Destinatário pode sincronizar diferentes fluxos de mídias em uma sessão RTP

8 RTCP Possui um problema potencial de escalabilidade Exemplo Sessão RTP com um remetente e vários receptores em multicast Total de tráfego RTP não muda se o número de receptores aumenta Total de tráfego RTCP aumenta linearmente com o número de receptores Por causa dos relatórios periódicos dos receptores Solução cada participante reduz o tráfego RTCP à medida que o número de participantes da conferência aumenta

9 Princípios da transferência confiável Válidos para as camadas aplicação, transporte e enlace Apresentados na camada transporte Características dos canais não confiáveis determinarão a complexidade dos protocolos de transferência confiáveis de dados Reliable Data Transfer (RDT) Unreliable Data Transfer (UDT)

10 Princípios da transferência confiável Série de protocolos cuja complexidade aumenta são apresentados Usa pacote no lugar de segmento Trata somente a transferência unidirecional de dados Usa máquina de estados finitos estendida

11 Transferência confiável de dados no transporte (fonte: Kurose) udt_

12 Transferência confiável de dados no transporte (fonte: Kurose) rdt_send():chamada da camada superior, (ex., pela aplicação). Passa dados para entregar à camada superior receptora deliver_data():chamada pela entidade de transporte para entregar dados para cima lado transmissor lado receptor udt_send():chamada pela entidade de transporte, para transferir pacotes para o receptor sobre o canal não confiável rdt_rcv():chamada quando o pacote chega ao lado receptor do canal

13 RDT 1.0 Transferência confiável sobre um canal confiável Não há erros binários Não há perdas de pacotes

14 RDT 1.0 Máquinas de estados finitos do RDT 1.0 (fonte: Kurose)

15 RDT 1.0 Não há diferença entre unidade de dados (SDU) e pacote Não há necessidade do destinatário enviar informação ao remetente Supõe que o destinatário pode receber dados a qualquer velocidade

16 RDT 2.0 Transferência confiável sobre canal com erros binários Não há perdas de pacotes Uso de solicitação automática de repetição (Automatic Repeat request - ARQ) Correção antecipada de erros (Forward Error Correction - FEC) não usada

17 Protocolos ARQ Detecção de erros Acrescenta sobrecarga (ex.: soma de verificação) unidade de dados diferente do pacote Realimentação do destinatário Para que o remetente tenha ideia do que se passa no destinatário Uso de reconhecimento positivo (acknowledgment ACK) Uso de reconhecimento negativo (negative acknowledgment NACK) Retransmissão

18 Protocolos ARQ Para e espera Go-Back-N Seletive Repeat

19 RDT 2.0 ACK ou NACK podem ter o comprimento de um bit Se o remetente receber um NACK, o protocolo retransmite o pacote Não considera que o ACK e o NACK podem estar corrompidos

20 Máquinas de estados finitos do RDT 2.0 (fonte: Kurose)

21 RDT 2.0 Protocolo para e espera (stop-and-wait) Só pode enviar novo dado se receber o ACK ACK ou NACK pode estar corrompido Retransmissão dos pacotes de dados Problema: pacotes duplicados Destinatário não sabe se o ACK ou o NACK que enviou chegou corretamente, ou seja, não sabe se o pacote recebido contém novos dados ou se é uma retransmissão Solução: uso de número de sequência

22 RDT 2.1 Considera que ACK e NACK podem ser corrompidos Receptor descarta pacotes duplicados Para o protocolo para e espera Um bit para número de sequência Remetente acrescenta o número de sequência ACK e NACK não precisam indicar o número de sequência Não há perda de pacotes

23 Máquina de estados finitos do remetente do RDT 2.1 (fonte: Kurose)

24 Máquina de estados finitos do destinatário do RDT 2.1 (fonte: Kurose) rdt_rcv(rcvpkt) && (corrupt(rcvpkt) sndpkt = make_pkt(nak, checksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && not corrupt(rcvpkt) && has_seq1(rcvpkt) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq0(rcvpkt) extract(rcvpkt,dados) deliver_data(dados) sndpkt = make_pkt(ack, checksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && corrupt(rcvpkt) Esperar 0 de baixo Esperar 1 de baixo sndpkt = make_pkt(ack, checksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq1(rcvpkt) extract(rcvpkt,dados) deliver_data(dados) sndpkt = make_pkt(ack, checksum) udt_send(sndpkt) sndpkt = make_pkt(nak, checksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && not corrupt(rcvpkt) && has_seq0(rcvpkt) sndpkt = make_pkt(ack, checksum) udt_send(sndpkt)

25 RDT 2.1 NACK não precisa ser utilizado Solução: envio do ACK para o último pacote corretamente recebido Dois ACKs para um mesmo pacote (ACKs duplicados) destinatário não recebeu corretamente o pacote seguinte ao que se refere o ACK