UNIVERSIDADE FEDERAL DE PERNAMBUCO CENTRO DE INFORMÁTICA
RELATÓRIO
INFRA-ESTRUTURA DE COMUNICAÇÃO
Equipe:
André Felipe Pereira de Melo Bernardo Reis
Onildo Ferraz João Pedro Kamei
Thiago Henrique da Paz Thiago Lessa
SUMÁRIO
1. Introdução...pág.3
2. Descrição da aplicação...pág.4
3. Descrição das classes do programa...pág.5
4. Formato das mensagens...pág.6
5. Remoção do jitter...pág.7
6. Conclusão...pág.8
INTRODUÇÃO
Esse relatório tem como objetivo descrever as funcionalidades do projeto desenvolvido para a disciplina de Infra-estrutura de Comunicação. A aplicação desenvolvida transmite voz através da rede e permite conversações, pois a transmissão é bidirecional.
Estas aplicações são conhecidas como VoIP (voz sobre IP).
As transmissões de áudio são feitas utilizando o protocolo UDP, pois a perda alguns pacotes é tolerável. O programa também utiliza o protocolo TCP para o estabelecimento da conexão.
A aplicação foi desenvolvida em Java e para capturar o áudio, foi utilizada a API JavaSound.
DESCRIÇÃO DA APLICAÇÃO
Ao inicializar o programa, é criado um socket TCP para ficar esperando solicitações de novas conexões. O servidor TCP fica esperando as solicitações na porta 8000, mas o usuário pode mudar o número da porta, se desejar.
Para começar uma conversa, o usuário deve digitar o número IP do destinatário e o número da porta UDP que deseja receber o áudio. Um socket TCP é criado para iniciar a conexão. Esse socket TCP envia a solicitação ao destinatário e espera pela resposta do host. Nesse momento, os seguintes eventos podem ocorrer:
O host não foi localizado. O socket TCP espera até 4 segundos pela resposta. Se após esse intervalo de tempo não houver resposta, a mensagem “host não localizado” aparecerá na tela.
O host não respondeu à solicitação. Nesse caso, o host foi localizado, mas não respondeu à solicitação de iniciar a conexão do usuário. Então, a mensagem
“erro com o socket” aparecerá na tela.
O destinatário rejeitou a chamada. O socket TCP espera até 12 segundos pela resposta do destinatário. Se depois desse intervalo de tempo o destinatário não responder, a mensagem “chamada rejeitada” aparecerá.
O destinatário aceitou a chamada. Assim, a mensagem “conectado” aparecerá na tela.
Quando a conexão é estabelecida, são criados 2 socket’s UDP, o servidor UDP e o cliente UDP. O servidor UDP fica esperando a chegada dos pacotes com o áudio e os reproduz. O cliente UDP recebe o áudio do microfone e envia-os para o destinatário.
Dessa forma é possível ter conversações, pois o envio e recebimento de voz se dá por dois socket’s diferentes. Após o término da conversa, o servidor UDP e o cliente UDP são fechados.
DESCRIÇÃO DAS CLASSES DO PROGRAMA
Main: A classe principal do programa. Nela estão contidos os códigos da interface gráfica. Nela também tem uma classe interna chamada VerificarGui, que fica verificando os estados das flags das outras classes e atualizando a interface gráfica.
TCPCliente: Classe que cria o socket TCP que inicia a conexão ou que fecha a conexão.
TCPServidor: Classe que cria o socket TCP que fica esperando solicitações de novas conexões.
EnviarDados: Classe que captura o áudio do microfone, encapsula em um pacote UDP e envia-os ao destinatário.
ReceberDados: Classe que fica esperando a chegada dos pacotes com áudio e os reproduz. Nele também contém o algoritmo de remoção do jitter.
FORMATO DAS MENSAGENS
O formato das mensagens na conexão TCP possui 3 bytes. O primeiro byte é o da escolha da opção e os outros 2 bytes são a porta UDP em que o host está esperando receber dados.
No lado do cliente TCP, o byte da escolha pode assumir 2 valores:
1 , quando o cliente deseja iniciar a conexão com o host.
2, quando o cliente deseja fechar a conexão.
No lado do servidor TCP, o byte da escolha pode ser:
1, quando o destinatário aceita a chamada.
2, quando o destinatário rejeitou a chamada.
3, quando o destinatário já está ocupado.
O formato na conexão UDP possui 167 bytes, sendo divididos assim:
1 byte para o número de seqüência;
6 bytes para o timestamp;
160 bytes para o áudio.
O número de seqüência é necessário para a ordenação dos pacotes, pois como os pacotes são enviados por UDP, não se tem nenhuma garantia que os pacotes cheguem ao destinatário, ou que cheguem na ordem correta. O timestamp é necessário para o cálculo do jitter.
REMOÇÃO DO JITTER
Jitter é o nome que se dá à variação do atraso entre pacotes sucessivos. Assim, quando existe uma variação de atraso elevada, o recebimento dos pacotes se dá de forma irregular.
Uma solução do problema é esperar uma determinada quantidade de tempo antes de reproduzi-los para que, desta forma, a variação do atraso não tenha influência sobre os dados. Esse tempo de espera pode ser definido para ser estático, por exemplo, 100ms, ou de forma dinâmica, utilizando-se alguns algoritmos de cálculo do tempo. No projeto, foi implementado o tempo de espera dinâmico, que utiliza o jitter para o cálculo do tempo.
O jitter é calculado como:
jitter = | (t2 – t1) – (s2 – s1) | onde,
t1 é o timestamp do pacote 1, que é enviado pelo cliente;
t2 é o timestamp do pacote 2, também enviado pelo cliente;
s1 é o timestamp do pacote 1 quando este chega no destinatário;
s2 é o timestamp do pacote 2, quando este chega no destinatário.
CONCLUSÃO
Com o projeto, foi possível verificar a importância do conhecimento de redes de computadores para a sua implementação. Deve-se ter em mente todas as dificuldades existentes quando se utiliza a rede, como atrasos e perdas de pacotes. Com aplicações multimídia essa preocupação deve ser constante, pois a inteligibilidade do programa cai bastante devido à atrasos e perdas de pacotes.
