Relatório
Final
Identificação
Grande Área CNPq: Ciências Exatas e da Terra
Área CNPq: Telemática
Título do Projeto: Desenvolvimento de um protocolo leve para “cluster” de
computadores
Diretório de Grupos CNPq: Grupo de Sistemas Inteligentes
Linha de pesquisa do Grupo: Recuperação Inteligente de Informações
Pesquisador Responsável: Sérgio Antônio Andrade de Freitas
Nome do sub-projeto do aluno: Implementação de um protocolo de redes leve para
o “cluster” de computadores do Departamento de Informática
Nome do Bolsista: Jaci Alves de Souza Júnior
2
1) INTRODUÇÃO
O computador é uma ferramenta poderosa para se resolver problemas, desde a
sua criação a ciência tem trabalhado para aumentar o seu poder de processamento,
tornando essa máquina cada vez mais eficiente. Mas ainda assim há problemas que,
devido à sua complexidade, demandam uma quantidade de processamento tão grande
que um único computador levaria anos para resolvê-los. Uma das técnicas usadas para
resolver este problema é o processamento paralelo [9] que consiste em dividir o problema
em partes menores que serão processadas ao mesmo tempo (paralelamente) em vários
computadores. A esse conjunto de máquinas interligados em uma rede local [10] dá-se o
nome de cluster [2].
Um cluster é um conjunto de máquinas (com a mesma configuração ou não), que
se comunicam através de uma rede de interconexão cujo poder de processamento pode
ser semelhante a de um supercomputador, porém a um custo bem menor. Durante o
processamento essas máquinas necessitam de trocar mensagens entre si, sendo que,
dependendo do problema a ser resolvido, o número de mensagens trocadas é muito
grande. Se a comunicação entre os computadores não for suficientemente rápida, o
cluster pode passar mais tempo trocando mensagens do que resolvendo o problema
propriamente dito. Portanto é importante que a rede local que interliga cada computador e
o protocolo utilizado na comunicação sejam eficientes.
O Departamento de Informática da UFES adquiriu, através do edital do CTPETRO,
um cluster de 64 máquinas ( também chamadas de nós ), cada uma delas com um
processador Athlon XP 1800 MHz, memória RAM de 256MB, disco rígido de 20GB e
interface de rede ethernet 3Com de 100Mbits. Dois switches 3Com Super Stack3 4300 de
48 portas chaveados por um link GigaBit, interligam as máquinas na rede. O sistema
operacional é o Red Hat Linux 7.1 com a versão do kernel 2.4-18-27.7x. Atualmente o
cluster do departamento de Informática é o mais rápido do Brasil, e se encontra na 50ª
posição do rank mundial segundo o site clusters.top500.org. Em testes de desempenho
realizados em fevereiro de 2003 esse supercomputador atingiu a marca de 51Gflps (51
bilhões de operações de ponto-flutuante por segundo). Mais informações sobre o cluster
do Departamento de informática podem ser encontradas no site do Laboratório de
Computação de Alto Desempenho (LCAD)1 onde o cluster esta montado.
1
Endereço eletrônico do LCAD: http://www.inf.ufes.br/~lcad
3
O protocolo de comunicação utilizado neste cluster, até o momento, é o TCP/IP
[11]. Este protocolo foi originalmente criado para interligar máquinas na Internet [11], que
é, por natureza, uma rede complexa e heterogênea, onde as mensagens que trafegam
podem facilmente se perder no meio do caminho ou então serem atrasadas se o caminho
estiver congestionado ou ainda podem chegar ao destino contendo erros. O protocolo
TCP/IP trata todos esses possíveis erros e garante que a mensagem chegará correta ao
seu destino. Ao contrário da Internet, a rede de interconexão do cluster é um ambiente
controlado,
homogêneo
e confiável ( com uma taxa de erro pequena ),
não
necessitando de um protocolo tão robusto quanto o TCP/IP [11].
Baseado no fato de que o protocolo TCP/IP não é o mais apropriado para um
ambiente controlado, José Carlos Campana Filho [1], propôs em seu projeto final de
graduação um novo protocolo de comunicação para o cluster denominado TCPCamp. Em
seguida, Oziander Paula Nunes [5], realizou testes comparativos com simulações do
TCP/IP e do TCPCamp no ambiente do cluster do DI.
Através deste projeto de iniciação científica foi dada a continuidade a essa linha
de pesquisa dentro do Departamento de Informática da Ufes. O objetivo deste trabalho é
de otimizar a troca de mensagens entre os nós do cluster do DI: (1) reduzindo o tamanho
do cabeçalho de cada pacote, o que aumenta a quantidade de dados enviados em cada
um deles, (2) simplificando o processo de detecção de erros, o que implica em acelerar o
empacotamento dos dados a serem enviados e (3) reduzindo o número de pacotes de
confirmação, ou seja, ao invés de se fazer a confirmação de um único pacote, pode-se
confirmar o recebimento de um conjunto de pacotes.
A justificativa para este projeto é que o cluster do Departamento de Informática da
UFES é usado para aplicações tais como: simulação de poços de petróleo, simulação da
distribuição de poluentes na atmosfera, processamento de texto em larga escala, cálculo
em águas profundas , algoritmos genéticos para o problema do cacheiro viajante entre
outras. Essas aplicações são executadas ao mesmo tempo e cada uma delas utiliza os
recursos de várias máquinas do cluster que se comunicam entre si, tornando a troca de
mensagens muito intensa. Vale ainda ressaltar que a utilização dos recursos dessa
máquina esta disponível para toda a comunidade acadêmica do brasil, já existem
aplicações de pesquisadores vinculados a outras instituições de pesquisa em outros
estados sendo executadas no cluster do DI. Otimizar o processo de comunicação entre as
máquinas do cluster contribui para acelerar a execução de cada aplicação e
4
conseqüentemente para uma melhor a utilização dos recursos do cluster do DI pela
comunidade acadêmica.
O trabalho foi dividido em duas etapas:
I – Avaliação (simulação) dos modelos propostos por Campana [1] no
ambiente do cluster com subsequente extensão/adaptação dos mesmos.
II – Implementação do modelo resultante da fase I através de um módulo
dinâmico [7] [8] para o kernel do linux.
A fase de avaliação foi concluída em janeiro de 2003. Da adaptação dos modelos
avaliados foi proposto um outro protocolo de comunicação: CCP (Cluster Communication
Protocol) para ser implementado na fase seguinte. A fase de implementação teve início
em fevereiro de 2003 e o resultado dessa fase é um módulo dinâmico carregável [7] [8]
que provê as funcionalidades do CCP e que pode ser acoplado ao kernel do sistema
operacional linux, este módulo foi escrito na linguagem de programação C.
Este relatório está assim estruturado: na seção 2 é feita uma breve descrição dos
modelos TCPCamp e os resultados da sua avaliação. A seção 3 é dedicada ao
funcionamento do protocolo CCP (Cluster Communication Protocol),
que é um
aprimoramento do TCPCamp. A seção 4 mostra detalhes da implementação do CCP em
baixo nível, na seção 5 são apresentados os resultados dos testes realizados com CCP e
na seção 6 as conclusões da análise desses resultados.
2) OS MODELOS TCPCAMP E SUA A AVALIAÇÃO
Os
modelos proposto por Campana [1] descrevem 4 protocolos que foram
baseados nos protocolos TCP/IP e RTP [6]:
1 - TCPCamp Mínimo, com o menor tamanho de cabeçalho, não possui aviso de
recebimento nem controle de erros, esse protocolo foi modelado para se obter o máximo
de desempenho na comunicação.
2 - TCPCamp Padrão, é semelhante ao protocolo TCP/IP, seu cabeçalho é uma
adaptação do cabeçalho TCP e do cabeçalho IP, possui procedimento simplificado para a
detecção de erros (bit de paridade) e confirmação de recebimento para cada pacote
enviado.
5
3 - TCPCamp JV (janela variável), que é derivado do modelo padrão, possui
mesmo cabeçalho e comportamento que o anterior a exceção de um parâmetro a mais
(tamanho de janela) que indica quantos pacotes podem ser enviados antes de esperar por
um pacote de confirmação (ack ), o que diminui o tráfego de pacotes na rede.
4 - TCPCamp CDV (campo de dados variável)
também derivado do modelo
padrão, possui um parâmetro que permite especificar qual o tamanho do campo de dados
a ser enviado em cada pacote, esta flexibilidade é importante porque para uma
quantidade pequena de dados é melhor transmitir mensagens pequenas enquanto que
para uma grande porção de dados,
aumentar o tamanho das mensagens é mais
vantajoso.
Os modelos TCPCamp foram primeiramente avaliados por Campana, através de
testes realizados com apenas duas máquinas fora do ambiente do cluster. Os testes
foram realizados com simulações de cada um dos modelos TCPCamp e também uma
simulação do TCP/IP, todas as simulações usam em nível mais baixo, para a transmissão
real de dados , sockets TCP/IP. Os resultados obtidos por Campana comprovaram que os
modelos TCPCamp tinham uma melhor performace em relação ao TCP/IP, sendo que o
modelo TCPCamp Mínimo obteve os menores tempos, seguido do modelo de janelas
variáveis (TCPCamp JV).
Com a chegada do cluster ao Departamento de Informática, Oziander Paula Nunes
[5] deu continuidade ao trabalho de avaliação desses modelos, realizando no ambiente do
cluster os mesmos testes de Campana, porém, com grugos de 4,8,16,32 e até 64
máquinas clientes enviando arquivos para uma única máquina servidora. Da análise dos
resultados pôde-se concluir que o TCPCamp Mínimo é a melhor solução para
implementação, mas não é apropriado para qualquer tipo de rede, visto que não garante
correção de erros, já o protocolo TCPCamp aproxima-se do protocolo TCP/IP para
arquivos pequenos com poucas máquinas, mas se mostra mais eficiente à medida que o
tamanho do arquivo e o número de máquinas aumenta. O protocolo TCPCamp JV mostrase mais eficiente quanto maior for o tamanho da janela, vale lembrar que escolha do
tamanho da janela deve levar em conta a quantidade de memória RAM disponível, visto
que quanto maior a janela maior será a quantidade de memória reservada para cada
conexão, semelhantemente o protocolo TCPCamp CDV mostra-se mais eficiente quanto
maior for o tamanho do campo de dados, tamanho este limitado pelo tamanho máximo de
um frame Ethernet: 1500 bytes.
6
3) O CLUSTER COMMUNICATION PROTOCOL (CCP)
Baseado nos modelos TCPCamp e nos resultados da avaliação dos mesmos foi
proposto um novo protocolo: CCP (Cluster Communication Protocol). Nas subseções a
seguir é apresentado o seu funcionamento detalhando aspectos da
hierarquia de
camadas, do cabeçalho de pacotes do CCP, do controle de erros e do controle de fluxo.
3.1) Hierarquia de Camadas CCP
Para facilitar o entendimento estrutural do CCP está esquematizado na fig. 1 a
hierarquia de camadas das arquiteturas de rede TCP/IP, TCPCamp e CCP.
Camada de Transporte
( TCP )
Camada de Rede
( IP )
Camada de Enlace
Camada de Transporte
( TCPCamp )
Camada de Rede
( IpCamp )
Camada de Enlace
Camada de Transporte
( CCP )
Camada de Enlace
Camada Física
Camada Física
Camada Física
Arquitetura TCP/IP
Arquitetura TCPCamp
Arquitetura CCP
Fig. 1: Hierarquia de Camadas
A arquitetura de rede da Internet (TCP/IP) está organizada em quatro camadas:
Camada de Transporte (TCP) cuja função é estabelecer uma comunicação confiável fima-fim entre a entidade transmissora e a receptora, Camada de Rede (IP) que é
responsável pelo endereçamento lógico e roteamento dos pacotes, Camada de Enlace
(SLIP, PPP, Ethernet, FastEthernet, etc. ) responsável pela comunicação entre máquinas
fisicamente
conectadas
e
a
Camada
Física
cuja
função
é
transmitir
bits.
Semelhantemente, a arquitetura TCPCamp está organizada em quatro camadas onde
cada uma delas desempenha o mesmo papel de sua correspondente na arquitetura
TCP/IP. Já a arquitetura CCP não possui a camada de rede, resultando numa hierarquia
de apenas 3 camadas, ou seja , o processo de envio e recebimento de pacotes na
arquitetura CCP possui uma etapa a menos tornando essa arquitetura mais eficiente que
as outras duas.
7
3.2) O cabeçalho de pacotes CCP
Uma das idéias básicas do TCPCamp é a redução do tamanho dos cabeçalhos
TCP e IP, que somados resultam num montante de 40 bytes, através da
eliminação/redução de alguns campos desses cabeçalhos. A economia é a 28 bytes para
o cabeçalho do TCPCamp Minimo e de 16 bytes para os outros modelos. O tamanho do
cabeçalho do CCP é de 6 bytes o que representa uma economia de 34 bytes em relação
cabeçalho ao TCP/IP, ou seja, cada pacote CCP pode enviar até 34 bytes de dados a
mais que um pacote TCP/IP o que significa que para uma transmissão de 10MB de
informação, seriam necessários aproximadamente 7.250 pacotes TCP/IP ou 7.080
pacotes CCP. A seguir ilustramos o cabeçalho CCP.
tipo
3 bits
ack_this parity
1 bit
num. sequência
1 bit
11bits
Porta Origem
16bits
Porta Destino
16bits
DADOS
Fig. 2: Cabeçalho CCP
/*----------------------------------------------------------------------------------------------------------------------------*/
typedef struct header {
__u16 type:3, /* {data,ack,nack,sleep,wake_up,ini,fin}
ack_this:1,
/* flag de req. de ack
parity:1,
/* bit de paridade
nseq 11;
/* seq number
__u16 sport;
/* source port
__u16 dport;
/* destination port
*/
*/
*/
*/
*/
*/
}header;
/*-------------------------------------------------------------------------------------------------------------------------*/
Fig. 3: Estrutura C do Cabeçalho CCP
ƒTIPO: Pode assumir um valor DATA, ACK, NACK, SLEEP, WAKE_UP, INI ou FIN, usado
para identificar o tipo do pacote, ou seja , qual tratamento deve ser dado a ele.
ƒ ACK_THIS: Indica ao receptor que o pacote é o último da janela.
8
ƒ PARITY: Bit de paridade, serve para identificar erros.
ƒ NUMERO DE SEQUÊNCIA: Número de identificação do pacote.
ƒ PORTA ORIGEM : Número que identifica o canal de comunicação na máquina que
enviou o pacote (remetente).
ƒ PORTA DESTINO: Número que identifica o canal de comunicação na máquina que
receberá o pacote (destinatário).
O principal motivo do tamanho reduzido desse cabeçalho é a eliminação de todos
os campos do cabeçalho IP, isso é possível porque o protocolo IP (Internet Protocol), foi
projetado para permitir a interconexão de redes de computadores que utilizam a
tecnologia de comutação de pacotes. O ambiente inter-rede consiste em hosts
(computadores) conectados através de hubs e swicthes, criando uma rede local, que por
sua vez, é interligada através de routers (roteadores) a outras redes, a função do IP é
rotear pacotes de uma rede para outra.
A rede de comunicação do cluster é composta de apenas uma rede local, ou seja,
os pacotes não precisam ser roteados pelo protocolo IP para chegarem a estação destino.
A tarefa de endereçamento é realizada pelos switches que interligam os nós do cluster.
Dado um pacote com seu endereço destino MAC (endereço físico da placa de rede) o
switch é capaz de encaminhá-lo corretamente ao seu destino. Outro fator que contribuiu
para a diminuição do cabeçalho CCP, foi a redução do tamanho do número de seqüência
de 32 bits para 11 bits e a eliminação do campo acknowledgment number (ack), também
de 32 bits, que está presente no cabeçalho TCP/IP, que possibilita o uso da técnica
piggybacking [12], a qual permite que um pacote de confirmação (ack) venha de “carona”
com um pacote de dados.
3.3 ) Fluxo Normal do CCP
O funcionamento básico do CCP (fig. 4) é semelhante ao do TCPCamp: A
entidade transmissora envia um conjunto de n pacotes ( janela de tamanho n) e espera a
confirmação do recebimento dos pacotes enviados, esse processo se repete até que toda
a informação (em forma de pacotes) tenha sido transmitida. O número de seqüência que
é usado para identificar os pacotes não precisa ser maior que 2n, número suficiente para
que o receptor possa fazer distinção entre pacotes da janela i e os pacotes da janela i +1.
Transmissor
Transmissão:
Janela 01
9
Receptor
Pacote 01
.
.
.
Pacote n
recepção
esperando ack
ack
Transmissão:
Janela 02
Pacote n+1
.
.
.
Pacote 2n
recepção
esperando ack
ack
Transmissão:
Janela 03
.
.
.
Pacote 01
.
.
.
.
.
.
Fig. 4: Fluxo Normal do CCP
3.4) Controle de Erro
Mesmo um ambiente controlado como a rede de interconexão do cluster não está livre de
erros. Alguns pacotes podem simplesmente não chegar ao seu destino, ou então serem
distorcidos/corrompidos durante o seu trajeto até o destino. Ao receber o último pacote da
janela (último pacote enviado pelo transmissor antes de esperar pelo ack ), o receptor
checa se todos pacotes chegaram corretamente, em caso negativo, ou seja, um ou mais
pacotes não chegaram ao destino, o receptor sinaliza ao transmissor, através do envio de
um pacote do tipo nack, quais pacotes se perderam pelo caminho. Ao receber um nack, o
transmissor retransmiti somente os pacotes cujos números de seqüência estão contidos
no nack.
Surge um problema quando o último pacote da
janela se perde: ambos,
transmissor e receptor, ficam parados esperando um pelo outro, o primeiro fica em espera
pelo ack e o segundo, por sua vez espera pelo último pacote da janela(que se perdeu)
para então enviar o ack ao primeiro, essa situação de espera mútua por tempo indefinido
10
é chamada de deadlock. O mesmo problema ocorre quando um ack ou nack se perde no
caminho de volta. Para resolver este o problema de deadlock a estação transmissora
agenda uma retransmissão do último pacote da janela, caso um ack ou nack não chegue
num certo intervalo de tempo o último pacote é então retransmitido.
Pacotes corrompidos são detectados através do código de correção de erros, que
no caso do CCP se resume a apenas um bit de paridade, ao identificar um pacote com
erros a entidade receptora despreza-o. A fig. 5 é um esquema do controle erros do
protocolo CCP.
Transmissor
Receptor
Pacote 01
Transmissão:
Janela 01
Pacote 02
Pacote 03
.
.
.
Pacote n
esperando ack
erro
erro
recepção
enviando nack
nack
Retransmissão:
Pacote 01
Pacote 02
recepção
ack
Fig. 5: Controle de Erros
3.5) Controle de Fluxo
O controle de fluxo é necessário quando a estação transmissora envia pacotes mais
rapidamente do que a estação receptora pode receber. Antes de enviar um ack à entidade
transmissora, o receptor verifica em seu buffer interno de armazenamento se há espaço
suficiente para armazenar mais uma janela de pacotes, em caso negativo é enviado ao
transmissor um pacote do tipo sleep, ao invés do ack. Quando estiver pronto para receber
11
uma nova janela o receptor envia um pacote wake_up (veja a fig. 6) ao transmissor, e a
comunicação segue seu fluxo normal.
Transmissor
Receptor
Pacote 01
Transmissão:
Janela 01
Pacote 02
Pacote 03
.
.
.
recepção
Pacote n
esperando ack
Pouco espaço no buffer
de armazenamento
sleep
“Dormindo”
wake_up
Fig. 6: Controle de Fluxo
4) A IMPLEMENTAÇÃO DO CPP
Um protocolo de comunicação para rede de computadores é um conjunto de
funcionalidades
que
viabilizam
a
comunicação
entre
duas
máquinas.
Essas
funcionalidades precisam ser agrupadas e adicionadas ao sistema operacional de cada
computador, dessa forma os usuários podem, através de chamadas de sistema (system
call), tirar proveito dessas novas funcionalidades
agora disponibilizadas pelo sistema
operacional.
A maneira mais fácil de se adicionar novas funções ao sistema operacional Linux
é através de módulos dinâmicos [7] [8] que podem ser acoplados(ou desacoplados)
dinamicamente ao kernel do sistema sem a necessidade de recompilar todo o kernel ou
12
de se reinicializar a máquina. Um exemplo do uso de módulos são os drivers de
dispositivos de E/S [7] como placas de vídeo, placas de som, interfaces de rede etc.
KERNEL
KERNEL
CCP
Fig. 7: Adicionando o módulo CCP ao kernel
A implementação2 do protocolo CCP baseou-se nessa idéia, ou seja, foram criados
dois módulos dinâmicos para o Linux: o primeiro, cujo o código fonte está armazenado no
arquivo ccp.c, provê as funcionalidades de comunicação do protocolo e o segundo, um
char driver[7] armazenado no arquivo interface.c, que provê acesso a essas
funcionalidades através do arquivo /dev/ccp. Para que um usuário possa enviar ou
receber dados usando o protocolo CCP, basta abrir esse arquivo e escrever ou ler
diretamente do descritor.
Uma outra maneira de prover acesso as funcionalidades do protocolo CCP seria
através das chamadas de sistema (system call). Essa não foi a opção escolhida pois para
se adicionar uma nova chamada de sistema seria necessário recompilar o kernel do
sistema operacional.
4.1) A Máquina de estado finitos CCP
O protocolo CCP foi especificado através de uma máquina de estados finitos [4].
Além de facilitar a compreensão do comportamento funcional do protocolo, a máquina de
estados finitos ajuda a estruturar o código de implementação, tornando-o mais claro e
manutenível visto que o diagrama de transição de estados da máquina serve como um
mapa para implementação. Por isso o protocolo CCP foi implementado como uma
máquina de estados finitos. O diagrama de transição de estados, referente ao remetente
(processo de envio) é apresentado na figura 8.
2
O código fonte do protocolo CCP pode ser encontrado na url: http://www.inf.ufes.br/~jjunior/ccp
13
pacote ini
INICIO CONEXÃO
requisição de envio
ENVIANDO
envio de uma janela
ESPERANDO ACK
tempo de retrans. expirado
chegada de um sleep
chegada de um ack
“DORMINDO”
ACK RECEBIDO
ACK_TIMEOUT
chegada de um ack
chegada de um wake_up
tempo de retrans. expirado
tempo de retrans. expirado 10 vezes
pacote fin
CONNECTION_TIMEOUT
FIM CONEXÃO
Fig. 8: A Máquina de estados finitos CCP
O estabelecimento de uma conexão (INICIO CONEXÂO) tem início com a envio de
um pacote do tipo ini, então uma estrutura de dados é alocada na memória principal para
guardar as informações referentes a essa conexão, como por exemplo o estado atual. A
partir desse momento requisições de envio de informações podem ser solicitadas.
Quando uma solicitação ocorre o estado atual da máquina é atualizado para ENVIADO, e
os pacotes da primeira janela começam a ser enviados. Após o envio do último pacote da
janela o estado corrente é alterado para ESPERANDO ACK no qual nenhuma ação é
realizada até a chegada de um pacote do tipo ack. Se nenhum erro ocorrer e o
destinatário estiver pronto para receber uma nova janela (espaço no buffer interno) um
ack é enviado ao remetente confirmando o recebimento dos pacotes da janela enviada.
14
Ao receber o pacote de ack o estado atual é atualizado para ACK RECEBIDO, estando
novamente pronto para enviar uma nova janela de pacotes.
4.2) Acesso à Camada de Enlace
Antes de começar a implementação do módulo CCP foi necessário conhecer
algumas funções de acesso aos serviços da camada de enlace disponibilizadas pelo
kernel do linux e também pelo driver da placa de rede. Dentre essas funções, as
principais são aquelas responsáveis pelo envio e recebimento de frames ethernet [12] [3].
No tutorial Adding a new protocol in LINUX [13] há uma descrição detalhada
dessas funções utilizadas para enviar e receber frames ethernet, além de um exemplo de
como adicionar um novo protocolo ao nível da camada de rede à versão 2.4 do kernel do
linux. Esse tutorial foi traduzido para a língua portuguesa e aprimorado durante este
projeto de iniciação científica e está disponível na Internet3.
4.3) Principais funções do kernel utilizadas
Dentre as funções disponibilizadas pelo kernel do sistema operacional Linux
utilizadas no módulo CCP, pode-se destacar:
•
dev_alloc_skb (int tam) : esta função aloca um pacote do tamanho desejado.
•
dev->hard_header (...) : Função do driver da placa de rede que dado um pacote
e os endereços origem e destino, constrói o cabeçalho ethernet para o pacote.
•
dev_queue_xmit (sk_buff* pacote): Coloca um pacote numa fila de saída para
ser enviado pela placa de rede.
•
dev_add_pack (...): Transfere um pacote do driver do dispositivo para o módulo
CCP.
4.4) Principais funções implementadas
Grande parte do trabalho realizado pelo módulo CCP que possibilita troca de
informação entre duas ou mais máquinas, é realizado por apenas duas funções:
3
http://www.inf.ufes.br/~jjunior/tutorial
15
•
ccp_output ( ccb * conexao, unsigned char * dados , int tam)
A função ccp_output recebe um ponteiro para uma conexão e uma porção
de dados de envio, em seguida aloca na memória um pacote preenche seu
cabeçalho e o seu campo de dados, o pacote é então colocado numa fila para
posteriormente ser enviado pela placa de rede. Se o pacote em questão for o
último da janela a função agenda a retransmissão do pacote e põe o processo
usuário para dormir esperando pelo ack. O processo se repete até que toda a
porção de dados tenha sido enviada.
•
ccp_input ( struct sk_buff *pacote)
A função ccp_input recebe como parâmetro um pacote e é chamada
diretamente pelo kernel. Quando um pacote chega à interface de rede, esta lança
uma interrupção indicando a chegada de um pacote. O sistema operacional
assume o processador para tratar a interrupção chamando o driver do dispositivo
que irá salvar o pacote em alguma região na memória. Através de uma chamada
a ccp_input o kernel passa o pacote recebido para o módulo CCP. O que essa
função faz é identificar a conexão a qual pertence o pacote e tratá-lo conforme o
seu tipo e o estado atual da conexão. Por exemplo, se o pacote é do tipo ack e o
estado correte da conexão a qual ele está relacionada é ESPERANDO ACK, a
função ccp_input simplesmente atualizará o estado da conexão para ACK
RECEBIDO.
16
5) TESTES E RESULDADOS
5.1)Testes de Correção
Foram realizados alguns testes especificos para verificar a correção do protocolo
CCP. Algumas porções de código foram intencionalmente introduzidas no módulo para
provocarem erros tais como:
•
Perda de um ou mais pacotes de dados (DATA).
•
Perda da de um pacote de dados com um flag ack_this.
•
Perda de um pacote do tipo ack .
•
Perda de um pacote do tipo nack .
•
Perda de um pacote do tipo sleep.
Esses erros são os mais freqüentes numa rede heterogênea. Em todas essas
situações o protocolo se comportou como o esperado, tratando esses erros corretamente.
Outros erros tais como: Perda de um pacote do tipo wake_up e pacotes corrompidos não
foram testados visto que seu tratamento ainda não havia sido devidamente implementado
no módulo CCP.
5.1)Testes de Desempenho
Para testar o desempenho do protocolo CCP e compará-lo ao protocolo TCP/IP
foram implementados 4 programas ( 2 servidores e 2 clientes ) capazes de transferir
arquivos
entre
duas
máquinas,
dois
deles
utilizando
comunicação
TCP/IP
(tcpServer/tcpClient) e os outros dois utilizando comunicação CCP (ccpServer/ccpClient).
Todos os testes foram realizados no ambiente do cluster mas com apenas duas
máquinas, porque a noção de portas lógicas ainda não havia sido implementada no
módulo CCP o que não permitia a comunicação de uma mesma máquina com várias
outras.
Nos primeiros testes realizados os programas que utilizavam o protocolo CCP,
para arquivos de 10MB, foram 4 vezes mais lento do que os outros que utilizavam
TCP/IP. Isso ocorreu devido a um erro no módulo CCP que fazia o remetente esperar por
um pacote do tipo ack após o envio de um pacote de dados, semelhante a uma janela de
tamanho 1.
17
Após a correção desse erro, o protocolo CCP se mostrou mais eficiente que o
protocolo TCP/IP na transferência de arquivos grandes (10MB) porém para arquivos
menores, de 2MB, foi um pouco mais lento.
Os Testes de desempenho foram realizados em duas máquinas do cluster com
transferência de arquivos de 2MB, 4MB e 10MB. Foram usados dois valores para o
tamanho da janela do protocolo CCP: 10 e 40 pacotes. Os resultados dos testes podem
ser conferidos na tabela 1 e 2. A tabela 1 apresenta e compara os valores dos testes
obtidos com o protocolo CCP variando apenas o tamanho da janela. A tabela 2 apresenta
e compara os valores dos testes obtidos com o protocolo CCP (janela=40) e TCP/IP.
PROTOCOLO CCP (janela=10)
PROTOCOLO CCP (janela=40)
Tam.
MÉDIA
Tam.
MÉDIA
Arquivo
Arquivo
Tempo (s)
Tempo (s)
2MB
0.242
2MB
0.219
4MB
0.475
4MB
0.436
10MB
1.183
10MB
1.081
DIFERENÇA ENTRE OS PROTOCOLOS
Tam.
DIFERENÇA ENTRE AS MÉDIAS
Arquivo
Tempo (s)
2MB
0.023
4MB
0.039
10MB
0.102
Tabela 1: Comparação entre os resultados dos testes do CCP variando a janela.
Os resultados dos testes comprovaram que o aumento da janela pode tornar o
protocolo CCP mais eficiente. Para cada um dos arquivos enviados, o ganho obtido, em
média, foi de um pouco menos de 10% na mudança de tamanho da janela de 10 para 40
pacotes. Porém deve se ressaltar que o número de retransmissões aumentou
significantemente com o aumento da janela, o que implica dizer que o aumento exagerado
do tamanho da janela pode tornar o processo de comunicação mais lento, além de
sobrecarregar a rede com várias retransmissões de pacotes.
18
PROTOCOLO CCP (janela=40)
PROTOCOLO TCP/IP
Tam.
Tam.
MÉDIA
MÉDIA
Arquivo
Arquivo
Tempo (s)
Tempo (s)
2MB
0.219
2MB
0.205
4MB
0.436
4MB
0.881
10MB
1.081
10MB
1.787
DIFERENÇA ENTRE OS PROTOCOLOS
Tam.
DIFERENÇA ENTRE AS MÉDIAS
Arquivo
Tempo (s)
2MB
-0.014
4MB
0.445
10MB
0.706
Tabela 1: Comparação entre os resultados dos testes do CCP e TCP/IP
O protocolo CCP foi aproximadamente 51% mais eficiente que o TCP/IP na
transferência de arquivos de 4MB, e quase 40% mais rápido na transmissão de arquivos
de 10MB. Esses resultados já eram esperados pois haviam sido profetizados pelos
resultados obtidos com a avaliação dos modelos TCPCamp. Nota-se, porém, que com o
aumento do tamanho do arquivo a eficiência do CCP em relação ao TCP/IP diminui, isso
acontece porque o número de retransmissões aumenta a medida que aumenta a
quantidade de informação sendo transmitida.
O TCP/IP foi aproximadamente 7% mais eficiente que o protocolo CCP na
transferência de arquivos de 2MB, o que não era esperado. Uma possível razão é o fato
de que, ao contrário do CCP, o protocolo TCP/IP teve um comportamento muito variado,
sendo que alguns dos tempos de envio de um mesmo arquivo tiveram uma discrepância
de mais de 400%. Provavelmente os testes realizados com o arquivo de 2MB não foram
suficientes para capturar o comportamento médio do TCP/IP.
6) DISCUSSÃO/CONCLUSÕES
Conforme já havia sido previsto através das avaliações dos modelos TCPCamp, o
protocolo CCP (derivado desses modelos) é mais eficiente que o TCP/IP. A redução do
tamanho de cabeçalho e do número de pacotes de confirmação se traduz em uma
economia que pode chegar a mais de 50%. O objetivo desse projeto de iniciação científica
foi alcançado, através da utilização do protocolo implementado, a troca de mensagens
entre os nós do cluster do Departamento de Informática pode ser otimizada.
Deve-se ressaltar que a proposta inicial era a implementação funcional dos
modelos TCPCamp, no entanto os resultados da avaliação desses modelos mostraram
19
que era possível simplificar ainda mais o processo de comunicação que envolve os nós
do cluster. Baseado nessa conclusão um novo protocolo foi elaborado e chamado
CCP(Cluster Communication Protocol). O protocolo CCP consiste em uma simplificação
dos modelos TCPCamp. Essa simplificação facilitou a implementação
desse protocolo
como um módulo dinâmico para o sistema operacional Linux, e ao mesmo tornou esse
protocolo um pouco menos abrangente que modelos TCPCamp e o próprio TCP/IP,
servindo apenas para a comunicação
entre máquinas de uma mesma rede. Essa
abrangência reduzida é devido a eliminação da camada IP da hierarquia de camadas
desse protocolo.
7) BIBLIOGRAFIA
[1] Campana, José. Proposta de um Protocolo Leve para Clusters de Computadores.
Monografia de Projeto Final de Graduação, Departamento de Informática da UFES, 2002.
[2] Ferreira, Luiz. Linux HPC Clusters Instalation. 1ª Edição. Editora Redbooks. 2001.
[3] Herrin, Glenn. Linux IP Networking. Url: http://www.cs.unh.edu/cnrg/gherrin/.
[4] Holzmann, Gerard. Desing and Validation of Computer Protocols. Prentice Hall.
1991.
[5] Nunes, Oziander. Avaliação de um protocolo leve no cluster de Computadores do
DI/UFES. Monografia de Projeto Final de Graduação, Departamento de Informática da
UFES, 2003.
[6] Real Time Protocol. Almeida, Juliana. Url: http://www.gta.ufrj.br/grad/01_2/vidconf/rtp.html.
Última visita: 29/07/2003.
[7] Rubini, Alessandro. Linux Device Drivers, 2ª Edição. Editora O´reilly. 2001.
[8]
Salzman,
Perter.
The
Linux
Kernel
Module
Programming
Guide.
Url:
http://jamesthornton.com/linux/lkmpg/
[9] Skilicorn,
David. Models and Languages for Parallel Computation. 2002.
[10] Soares, Luiz F. Redes de Computadores das Lans, Mans e Wans às redes ATM.
2ª Edição. Editora Campus. 1995.
[11] Stevens, Richard. TCP/IP Illustrated:The Protocols. 1ª Edição. Editora AddisonWesley. 1998.
[12] Tanenbaum, Andrew. Computer Networks. 3ª Edição. Prentice Hall. 2000.
Última visita: 29/07/2003.
[13] Zhu, Wenbin. Adding a new Protocol in LINUX. Url: http://www.unm.edu/%7Ezhuwb.
Última visita: 29/07/2003.
20
7) APOIO
Programa Institucional de Bolsas de Iniciação Científica (PIBIC-UFES)
8) AGRADECIMENTOS
Ao professor Sérgio por me orientar em todo o processo de aprendizagem.
À minha família pelo apoio e compreensão.
A Oziander pelo auxílio na avaliação dos modelos TCPCamp.