WirelessBR

Série de artigos sobre VoIP
Segundo artigo - Parte 02

Camada de transporte 

Os protocolos de transporte da arquitetura isolam sessões através de portas (ports). Uma sessão full-duplex entre duas aplicações é identificada por um par de portas – origem (source port) e destino (destination port) – em cada sistema. Os números de porta de origem e destino, que fazem parte do cabeçalho (header) dos protocolos de transporte, são números binários com 16 bits, portanto podem assumir valores (expressos em decimal para consumo humano) de 0 a 65535. 

Aplicações que funcionam no paradigma client-server abrem sessões através de um procedimento denominado three-way handshake: 

a)   O server abre uma porta para recebimento das requisições iniciais dos clients, e fica aguardando. Esta porta é denominada o well-known port do server. Nos protocolos padronizados pelo IETF, os well-known ports são administrados pelo ICANN[7] (que assumiu as funções da IANA[8]), e são designados na metade baixa da faixa de numeração (0 a 32767). Para protocolos não padronizados, recomenda-se usar apenas well-known ports na metade alta da faixa de numeração (32768 a 65535). Chamaremos estas faixas de numeração de porta, daqui para a frente, de low ports e high ports; 

b)   O primeiro pacote vindo de um client usa como destination port o well-known port do server, e como source port um high port arbitrário. Normalmente este pacote inicial contém, como carga útil (payload), uma primitiva HELLO do protocolo de aplicação; 

c)   Supondo que o server tenha condições de atender ao client, ele responde com um pacote que usa como destination port o mesmo high port designado pelo client no source port do seu pacote inicial, e como destination port um outro high port arbitrário. Tipicamente este pacote contém uma primitiva ACK (acknowledgement) do protocolo de aplicação como payload; 

d)   A partir daí, o client e o server prosseguem com a sessão. O client usando como source port o mesmo high port que ele selecionou em (b), e como destination port o high port selecionado pelo server em (c). E o server usando como source port o mesmo high port que ele selecionou em (c), e como destination port o high port selecionado pelo client em (b). 

A figura 2 ilustra este processo. 

Figura 2 – Three-way handshake

Para facilitar a vida dos programadores de aplicação, existe uma API chamada socket interface, que permite ao programador implementar um serviços de sessão adequado ao seu caso. Já existem versões desta API portadas para todos os ambientes que eu já ouvi falar. 

Falta ver como, exatamente, ocorre o transporte dos pacotes de aplicação. O IETF padronizou dois protocolos para esta função: transmission control protocol – TCP, e user datagram protocol – UDP. 

O UDP oferece serviço de transporte na modalidade best-effort delivery, também conhecido como serviço de datagrama. Não existe nenhuma garantia sobre o que vai acontecer com os pacotes enquanto em trânsito, e a responsabilidade pela detecção e eventual recuperação de erros na transmissão cabe ao protocolo de aplicação. 

O TCP oferece serviço de transporte confiável, com flow control. Ele é capaz de detectar e recuperar os seguintes tipos de erros na transmissão dos pacotes: perda, duplicação e troca de ordem. 

O flow control implementado pelo TCP usa alguns bits no header para: numeração seqüencial dos pacotes transmitidos, confirmação de recebimento de pacotes e sinalização de sobrecarga. O algoritmo utilizado chama-se janela deslizante (sliding window), e funciona assim:

a)   No início da sessão, as partes estabelecem o número máximo de pacotes que podem ser transmitidos por uma parte sem que haja confirmação explícita de recebimento pela outra parte. Este número é a largura da janela;

b)  Cada parte estabelece um limite de transmissão igual ao número seqüencial do último pacote que teve recepção confirmada pela outra parte mais a largura da janela, e transmite até que este limite seja atingido;

c)   Se o limite de transmissão é atingido, a transmissão cessa até o recebimento de uma confirmação, dentro de um limite de tempo (timeout);

d)   Se o limite de tempo se esgotar sem recebimento de confirmação, aquela janela é considerada perdida, e retransmitida. Se a mesma janela não for confirmada por um certo número de vezes consecutivas (tipicamente três), a sessão é encerrada;

e)  Quando uma confirmação é recebida, o início da janela é “deslizado” para o número do último pacote confirmado, e o processo de transmissão continua, como em (b).

Se uma das partes começa a deslizar constantemente a janela, sem que tenha sido atingido o número de pacotes limite da janela, ela assume que a outra parte pode suportar uma carga maior de transmissão, e aumenta a sua largura da janela. 

Se uma das partes fica sobrecarregada na recepção, ela sinaliza no sentido reverso, ligando o bit de source quench do header TCP. A outra parte, ao receber pacotes com o bit de source quench ligado, diminui a sua largura de janela de transmissão, até passar a receber pacotes com o bit de source quench novamente desligado. 

Muito bem... já temos um serviço de sessão e transporte que funciona. Resta saber agora como encaminhar os pacotes entre sistemas diferentes, mas isto já é assunto para a próxima seção.