Nos Correios também
A implementação do protocolo em Linux é uma base sólida para desenvolvimentos posteriores em Unix/Posix.

Nossa empresa, Equação Informática, é especializada em endereçamento - produzimos um Guia Postal Eletrônico e prestamos serviços de Auditoria de Endereços em cadastros já montados. No início de 1999 publicamos um documento especificando o acesso ao Guia Postal Brasileiro (GPB) na forma de um serviço de rede, batizado como Protocolo de Endereçamento Postal Brasileiro (PEP/Br). Suas principais características são mostradas no próximo parágrafo. A especificação completa pode ser consultada em www.equacao.com.br.

Um cliente cria um canal de comunicação com o servidor, que gerencia os arquivos do GPB. Cada comando enviado gera uma resposta, que pode ter uma ou mais linhas. O servidor é responsável por analisar o comando e executá-lo, acessando o GPB quando necessário. Cada linha da resposta é composta de uma porção numérica de três dígitos, seguida do texto correspondente. O servidor deve controlar vários clientes simultaneamente, e cada cliente é estanque, não interferindo nas atividades dos outros clientes.

Após publicar a especificação, iniciamos o trabalho de implementação do servidor do protocolo. TCP/IP foi o canal de transporte escolhido, por sua popularidade. A primeira plataforma implementada foi Windows, com Visual Studio 6, C++ e MFC. Em seguida, partimos para Linux, usando GNU C.

Decidimos a implementação nestas duas plataformas pelas seguintes razões: o ambiente Windows é usado na maioria das empresas no País e o servidor pode ser instalado em qualquer uma das máquinas da rede, oferecendo o serviço para as outras máquinas Linux, o que tem se mostrado uma alternativa interessante quanto a estabilidade, confiabilidade e custo/benefício.

Embora tivéssemos mais de dez anos de experiência em programação C/C++, os ambientes de desenvolvimento eram novidade para nós (como usuários dos compiladores Borland, quase nunca usamos Visual C++, e no Linux precisávamos de algo para sair do estágio de curiosidade em nossa empresa). A oportunidade era excelente para nos lançarmos nestes novos caminhos. A implementação do protocolo em Linux deixaria uma base sólida para desenvolvimentos posteriores em Unix/Posix.

O primeiro passo para ambas as plataformas foi procurar exemplos de como codificar um programa servidor usando sockets TCP/IP. Encontramos o exemplo Windows no CD da Microsoft Developer's Network (MSDN). Para Linux, os fontes de um servidor ftpd foram encontrados numa rápida pesquisa na Internet (Yahoo). A estrutura de arquivos do GPB foi a mesma em ambas as implementações, ou seja, arquivos ASCII com registros de comprimento fixo. O mesmo algoritmo de pesquisa foi usado.

Então começamos a perceber as diferenças entre os ambientes. A leitura seqüencial de registros foi mais rápida em Linux do que em Windows - tão mais rápida que pensamos ter errado em alguma coisa. A diferença foi comprovada por um pequeno programa que lia um arquivo cem vezes, registro a registro. Num Pentium 233 MMX com 96 MB RAM, HD 10 GB e Windows 95, o programa compilado em Borland C++ 5.0 foi executado em 27 segundos, e em Visual C++ 6 em 6 segundos. O mesmo programa, num Pentium 166 com 64 MB RAM, HDs totalizando 10 GB e Conectiva Linux 2.0.36, foi executado em 4 segundos. Nada mal para uma máquina com um terço a menos de capacidade computacional e memória.

A estrutura geral do código também foi mais simples em Linux. Um servidor TCP/IP em Windows deve manter um socket em estado de espera. Quando uma conexão é requisitada, um novo socket é criado, e um thread é lançado para gerenciar esta conexão. Em Linux, uma única conexão é gerenciada, pois múltiplas instâncias do programa podem ser lançadas pelo daemon inetd.

O ambiente de desenvolvimento é um ponto forte a favor do Windows. O IDE do Visual Studio foi melhor do que qualquer outro que tivemos a oportunidade de pôr as mãos até o momento. Em Linux, acabamos por usar o ambiente gráfico KDE, com uma janela aberta para a execução de MAKE, outra para a execução do programa recém-compilado, e janelas com os editores de texto em cada arquivo fonte aberto. Como o programa envolveu poucos arquivos fonte, e as janelas puderam ser espalhadas por áreas de trabalho diferentes, o trabalho acabou fluindo agradavelmente, embora não com a mesma simplicidade e coerência do Visual Studio.

Ambos os resultados não comprometeram o tamanho total da aplicação (64 KB em Linux, 303 KB em Windows, para aproximadamente 180 MB em dados). O desempenho de ambos os programas ficou dentro do esperado, com tempos de resposta aceitáveis. Como os tempos de resposta eram pequenos demais para uma medição caseira, fizemos a cronometragem da execução do comando de apresentação de todos os logradouros da localidade de São Paulo, SP. Seria algo como selecionar 60.000 registros, construir 60.000 linhas de resposta, empilhá-las e remetê-las pelo socket. Em Linux foram necessários aproximadamente 43 segundos para iniciar a listagem dos logradouros, enquanto, em Windows, 160 segundos foram gastos na mesma tarefa - para nós, reflexo direto da melhor manipulação de arquivos. É importante lembrar que a máquina Linux era menos potente do que a máquina Windows.

As conclusões tiradas desta experiência são as seguintes:

• É inacreditável a quantidade de documentação disponível para consultas na Internet, tanto para Windows quanto para Linux.
• A manipulação de arquivos sob Linux é mais rápida do que sob Windows.
• Linux é a opção a ser seguida para desenvolvimentos de servidores TCP/IP, principalmente se seu servidor deve ser projetado para suportar muitos clientes simultaneamente.
• Windows oferece os melhores ambientes para desenvolvimento com mais conforto e facilidade de uso.

Sidney Passos
spassos@ruralsp.com.br