typedef void (Garoto_Hipotenusa)(void )

Lucene Search

2010-04-28T10:37:00.005-03:00

Para quem precisa disponibilizar um mecanismo de busca para um site, que permita indexação de conteúdos em diversos formatos (PDF, ODT, DOC, registros de banco de dados, etc.), a solução Lucene Search, da Apache Foundation (http://lucene.apache.org/) supre eficientemente essa demanda.

Nesse post, pretendo mostrar, de forma sucinta, como o recurso de indexação e busca pode ser implementado com Lucene Search, usando um framework JEE, no caso, o JBoss Seam (http://seamframework.org), ou outro qualquer de interesse do desenvolvedor.
Primeiro, é preciso permitir que as suas entidades (JPA ou Hibernate) tenham a capacidade de gerar informações de índice (metadados), que serão gravados em disco, a cada vez que um dado for alterado no banco. Haverá, é lógico, uma preocupação sobre quais campos da entidade (digamos, o tipo Pessoa será indexado unicamente pelo campo str_nome da tabela pessoa) serão indexados. Para configurar os eventos do Lucene Search, de forma que eventos de escrita no banco atualizem os "listenes" do Lucene, é preciso configurar o arquivo "ejb-jar.xml" ou o "hibernate.cfg.xml", com os seguintes itens de configuração:

<property name="hibernate.search.default.indexBase"> value="./lucene_indexes/"/>
<property name="hibernate.ejb.event.post-insert" value="org.hibernate.search.event.FullTextIndexEventListener"/>
<property name="hibernate.ejb.event.post-update" value="org.hibernate.search.event.FullTextIndexEventListener"/>
<property name="hibernate.ejb.event.post-delete" value="org.hibernate.search.event.FullTextIndexEventListener"/>

No caso, a propriedade "hibernate.search.default.indexBase" configura o diretório onde serão gravados os índices. É permitido usar diretórios relativos, como no caso acima, que configura o diretório de índices para o caminho lucene_indexes, que será referenciado dentro do path atual configurado para esse contexto. Dependendo do servidor de aplicação, o diretório "." pode referenciar o diretório server, do diretório padrão de instalação do JBoss, ou o server/default/deploy. Caso não exista o diretório acima, será automaticamente criado (criará o diretório server/default/deploy/lucene_indexes).
Outro passo importante é copiar as bibliotecas do Lucene e do Hibernate Search (que serão adicionados no arquivo MANIFEST.MF, no diretório META-INF):

lucene-core.jar
hibernate-search.jar
hibernate-commons-annotations.jar
hibernate-annotations.jar
lucene-highlighter-2.1.0.jar

Após isso, é necessário inserir as anotações específicas do Lucene e do Hibernate Search. A primeira indicará, na declaração da sua classe POJO (JPA/Hibernate) que ela será indexada:

@Entity
@Indexed
@Table(name = "relator", schema = "juris")
public class Relator implements java.io.Serializable {
...

É preciso marcar o campo da entidade que representa o índice. Na verdade, qualquer campo único pode ser usado. A anotação DocumentId apenas ajudará o Lucene a garantir a unicidade dos registros:

@Id
@DocumentId
@Column(name = "id_relator", unique = true, nullable = false)
public short getIdRelator() {
return this.idRelator;
}

Dentro da definição dessa entidade, agora é necessário especificar quais campos são indexados, e como eles serão indexados:

@Column(name = "str_nome_relator", length = 500)
@Length(max = 500)
@Field(index=Index.TOKENIZED,store=Store.YES,
analyzer= @Analyzer(impl = BrazilianAnalyzer.class))
public String getStrNomeRelator() {
return this.strNomeRelator;
}

Nesse ponto, cabem algumas explicações: o parâmetro index permite dizer se o campo será quebrado em tokens (trechos de caracteres), ou será tratado como uma sequência única. No caso, por ser um campo String composto por nome e sobrenome do relator, é aconselhável usar a constante Index.TOKENIZED. O parâmetro store diz se o campo será armazenado em arquivo, e pode ser visualizado através da ferramenta Luke (http://code.google.com/p/luke/). Essa ferramenta, por sinal, é muito útil para estudar a forma com que o Lucene gera os índices em arquivo, permitindo simular buscas usando diferentes analizadores semânticos de linguagens.

O outro parâmetro (analyzer) permite definir um analizador semântico diferente do Inglês. No caso, existe um BrazilianAnalyzer, e isso é muito importante, pois o tratamento sobre caracteres acentuados, por exemplo, é viabilizado através dos analizadores. Caso um analizador adequado não seja usado, internamente o Lucene pode ignorar caracteres acentuados, por exemplo, como se fossem símbolos inválidos. Ademais, o analizador específico para a linguagem que você utiliza para armazenar dados permite que uma busca por "Abraão" ou "Abraao" retorne o mesmo resultado. O recurso de internacionalização dos Analyzers permite ignorar detalhes de acentuação, melhorando a qualidade da busca.

Agora, já é possível fazer uma busca, usando o trecho a seguir:

try
{
QueryParser parser =
new MultiFieldQueryParser( new String[] {
"strNomeRelator"
},
new BrazilianAnalyzer() );
Query luceneQuery = parser.parse(nome_relator);

FullTextQuery ftq = entityManager.createFullTextQuery(luceneQuery
,Relator.class);
} catch (ParseException exc) {
}

Na chamado a classe MultiFieldQueryParser, nós passaremos como parâmetro: o campo que foi indexado, e que será buscado agora; e o analizador utilizado (BrazilianAnalyzer). Normalmente, pode-se passar null para o analyzer, pois ele já foi configurado na entidade Relator. Dessa forma, nós ainda não criamos a Query Lucene, apenas criamos um "criador de Queries Lucene". A seguir, nós chamamos o método parse, herdado da classe ancestral QueryParser, passando como parâmetro o valor que se quer buscar (por exemplo, a variável String nome_relator poderia conter "José", pois queríamos buscar por José na base). Com a query em mão, criaremos a FullTextQuery, essa sim que fará a busca propriamente dita na base de índices.

Para retornar a lista de registros encontrados, devemos chamar:

List<relator> resultPrimary = ftq.getResultList();

No próximo post, veremos como executar outras funções, como: marcar os hits encontrados, procurar em múltiplas tabelas, etc.

Google Treasure Hunt 3: Busca em Profundidade (Depth-First Search)

2008-08-16T01:20:00.001-03:00

Esse é outro problema do Google Treasure Hunt que eu resolvi. Esse foi o mais fácil de todos, e realmente não era necessário nenhum conhecimento de programação. Tenha-se em mente apenas que o não uso de programação para resolvê-lo não é de modo algum divertido! Tente ensinar seu computador a fazê-lo por você… O problema que eu obtive no Google foi o seguinte:

“Below is a diagram of a computer network. The nodes are hosts on the network, and the lines between them are links. A packet is sent out from host P with a destination of 4.229.231.150. Which nodes does the packet pass through on its way to the destination? (include start and final node in your answer)”

O diagrama para o modelo da rede acima foi fornecido na forma da tabela de roteamento a seguir:

“

A 26.40.28.17 75.174.216.140 => 126.186.188.58 26.40.28.17 => 17.100.195.84 4.229.231.0/24 => 75.174.216.140 13.157.234.26

B 13.157.234.26 76.246.145.72 => 53.12.68.161 126.186.188.58 => 75.174.216.140 53.12.68.0/24 => 26.40.28.17 17.100.195.84

C 53.12.68.161 75.174.216.140 => 219.88.219.35 229.23.61.42 => 13.157.234.26 17.100.195.0/24 => 103.19.57.145 126.186.188.58

D 103.19.57.145 86.60.122.237 => 86.60.122.237 117.146.177.141 => 53.12.68.161 229.23.61.0/24 => 219.88.219.35 212.222.1.12

E 4.229.231.150 4.229.231.150 => 103.19.57.145 54.35.7.207 => 54.35.7.207 126.186.188.0/24 => 199.223.210.72 229.23.61.42

F 54.35.7.207 4.229.231.150 => 229.23.61.42 13.157.234.26 => 199.223.210.72 26.40.28.0/24 => 4.229.231.150 86.60.122.237

G 86.60.122.237 229.23.61.42 => 54.35.7.207 13.157.234.26 => 103.19.57.145 103.19.57.0/24 => 212.222.1.12 219.88.219.35

H 212.222.1.12 126.186.188.58 => 219.88.219.35 75.174.216.140 => 86.60.122.237 103.19.57.0/24 => 103.19.57.145 229.23.61.42

I 229.23.61.42 4.229.231.150 => 4.229.231.150 117.146.177.141 => 54.35.7.207 126.186.188.0/24 => 199.223.210.72 212.222.1.12

J 199.223.210.72 53.12.68.161 => 229.23.61.42 4.229.231.150 => 54.35.7.207 219.88.219.0/24 => 219.88.219.35 4.229.231.150

K 219.88.219.35 4.229.231.150 => 199.223.210.72 17.100.195.84 => 212.222.1.12 126.186.188.0/24 => 86.60.122.237 103.19.57.145

L 117.146.177.141 4.229.231.150 => 219.88.219.35 117.146.177.141 => 126.186.188.58 26.40.28.0/24 => 76.246.145.72 75.174.216.140

M 75.174.216.140 199.223.210.72 => 13.157.234.26 4.229.231.150 => 117.146.177.141 126.186.188.0/24 => 17.100.195.84 26.40.28.17

N 17.100.195.84 4.229.231.150 => 26.40.28.17 219.88.219.35 => 13.157.234.26 17.100.195.0/24 => 75.174.216.140 76.246.145.72

O 76.246.145.72 4.229.231.150 => 17.100.195.84 86.60.122.237 => 126.186.188.58 13.157.234.0/24 => 53.12.68.161 117.146.177.141

P 126.186.188.58 13.157.234.26 => 53.12.68.161 4.229.231.150 => 76.246.145.72 103.19.57.0/24 => 26.40.28.17 117.146.177.141

”

Como você talvez tenha suposto, o primeiro símbolo é o ID do nó de rede, seguido por seu número IP. A seguir, você tem uma sequência de 3 regras de roteamento, o nó pode ver se essa regra em específico serve para o pacote entrante (incoming packet, ou pacote de rede no estágio de ingresso ao roteador). O ultimo número IP nos dá a rota padrão (“default route”), apenas no caso em que esse nó não encontrou nenhuma regra de roteamento que coubesse para um dado pacote (a rota padrão é como um “else” após uma sequência de “IF”s...).No caso do pacote chegar à rota padrão, esse pacote será direcionado para o host definido pelo endereço IP na última coluna da tabela acima.

Criei uma solução em C++, que usa um método de busca em profundidade para buscar por um caminho válido saindo de um dado nó para outro no modelo de rede do problema. Minha idéia foi fazer a função de busca em profundidade (em ingles, “depth-first search”) andar de nó em nó (nós são rotulados como: A, B, C, etc.), iterando sobre cada uma das regras da tabela de roteamento, e procurando por cada uma dessas regras que possa rotear adequadamente o pacote através da rede. A função abaixo é auto-explicável:

“

bool RoutingTable::routeTo( string node, string* resp )

{

bool do_it_again = true;

RoutingEntry rentry = findRouteEntry( node );

if ( rentry.doneThis() )

return false;

resp->append( rentry.getId() );

if ( rentry.getAddress().compare(getFinalDestination()) == 0 ) {

return false;

}

vector<RoutingRule> routing_rules = rentry.getRules();

vector<RoutingRule>::iterator i;

rentry.markThis(true);

// go through each of the routing rules

for ( i = routing_rules.begin(); ( i != routing_rules.end() ) &&

do_it_again; i++ )

{

if ( (*i).canRoute(getFinalDestination()) ) {

do_it_again = routeTo( (*i).getRedirection(), resp );

} // if

} // for

rentry.markThis(false);

// no rules; asks the default gateway…

if ( do_it_again )

{

do_it_again = routeTo( rentry.getDefaultRoute().getRedirection(),

resp );

}

return do_it_again;

}

”

Nessa solução usei apenas a STL do C++, ou C++ Standard Template Library (STL). Todos os nós são armazenados em estruturas como elementos de um vector, e são localizadas por símbolos de ID (A, B, C, etc.), ou por números IP (método findRouteEntry()). Cada nó tem a sua própria estrutura “Rules” (que você pode obter chamando getRules()). Uma vez processadas, cada uma dessas regras pode apontar para um outro nó da tabela, e a função routeTo pode atuar de forma recursiva sobre uma dada regra. Se nenhuma regra suficiente para combiner com o pacote for encontrada, a função routeTo é chamada sobre o nó retornado pela chamada a “getDefaultRoute”:

“

// no rules; asks the default gateway…

if ( do_it_again )

{

do_it_again = routeTo( rentry.getDefaultRoute().getRedirection(),

resp );

}

“

As chamadas para a função markThis() são para evitar recursões infinitas (iterar sobre os mesmos nós, de uma forma circular e muitas vezes irreversível, levando ao esgotamento de recursos computacionais). A semântica é simples: markThis(true), quando o código precisar entrar numa “regão crítca”, e markThis(false) quando tiver saído da região crítica.

Você conseguiria encontrar a diferença entre o método de roteamento que eu formulei para o que é implementado por roteadores de rede de verdade (de fabricantes como Cisco)? Talvez meus posts anteriores com questões da certificação CCNA da Cisco possam ajudar...

Google Treasure Hunt 2 - MapReduce?

2008-06-30T22:57:00.006-03:00

Para resolver o Google Treasure Hunt 2, decidi usar um velho programa para busca de arquivos implementado em C++ usando multi-threading. Eu mudei algumas partes do código, só para garantir que possa fazer a busca pelos 2 padrões especificados no problema, e escolhi usar o framework Qt (da Trolltech) que tem algumas funções muito legais para lidar com arquivos, e isso é realmente verdade – você não precisa de mais nada, a não ser as classes QFile e QDir e derivadas delas.

Se você gosta de programação distribuída, talvez você já tenha ouvido falar no modelo MapReduce, desenvolvido pela Google (www.google.com). De acordo com Jeffrey Dean e Sanjay Ghemawat, em um artigo (“Distributed Programming with MapReduce”) escrito para o interessante livro “Beautiful Code” (O’Reilly, 2007), “MapReduce was developed as a way of simplifying the development of large-scale computations at Google.” (tradução: “O MapReduce foi desenvolvido como uma forma de simplicar o desenvolvimento de processamento em larga-escala no Google”) Acredito que esse problema proposto no Google Treasure Hunt não seja realmente um “processamento em larga-escala”, mas eu gostei da forma como o MapReduce funciona, e decidi aplicar esse conceito ao meu programa.

Aqui está o problema número 2 do Google Treasure Hunt:

Here is a random zip archive for you to download:
GoogleTreasureHunt08_14338682343771558225.zip

Unzip the archive, then process the resulting files to obtain a numeric result. You'll be taking the sum of lines from files matching a certain description, and multiplying those sums together to obtain a final result. Note that files have many different extensions, like '.pdf' and '.js', but all are plain text files containing a small number of lines of text.

Sum of line 4 for all files with path or name containing BCD and ending in .js
Sum of line 5 for all files with path or name containing foo and ending in .xml
Hint: If the requested line does not exist, do not increment the sum.

Multiply all the above sums together and enter the product below.
(Note: Answer must be an exact, decimal representation of the number.)

Se você der uma olhada no código fonte, existem 2 threads; o primeiro (Mapper) obtêm a lista de arquivos com um padrão de nomes fornecido (no meu caso, nomes contendo “BCD” e com extensão “.js”, ou contendo “foo” e terminando com “.xml”); o segundo thread (Reducer) utiliza a lista com nomes de arquivos do thread Mapper e faz uma outra busca mais profunda dentro de cada um dos arquivos pré-selecionados (para obter os valores de números nas linhas de número “4”). O principal método do Mapper é o seguinte:

bool FileSearchMap::depthFirstTraversal(const QString& currentDir)

{

QDir dirP(currentDir);

QString temp;

QString fileName;

QStringList entryP = dirP.entryList();

QStringListIterator entryL(entryP);

while (entryL.hasNext())

{

producerMutex.lock();

if (myFileCount == 5)

{

bufferNotFull.wait(&producerMutex);

} // if - mutex and signal

producerMutex.unlock();

fileName.clear();

temp = entryL.next();

if ((temp != ".") && (temp != ".."))

{

fileName = currentDir;

fileName.append('\\');

fileName.append(temp);

if (isDirectory(fileName))

{

depthFirstTraversal(fileName);

}

else

{

if (isRegular(fileName))

{

unsigned int ftype = 0;

if ( ( fileName.endsWith(".js") ) &&

( fileName.contains("BCD") ) )

ftype = TXT_FILE_PATTERN;

else if ( ( fileName.endsWith(".xml") ) &&

( fileName.contains("foo") ) )

ftype = XML_FILE_PATTERN;

if ( ftype != 0 )

{

DirEntry dentry( fileName, ftype );

queueMutex.lock();

textFiles.push(dentry);

queueMutex.unlock();

producerMutex.lock();

++myFileCount;

producerMutex.unlock();

bufferNotEmpty.wakeAll();

}

} // if - isDirectory / isRegular

} // if

} // while

return true;

}

O método acima sera chamado exatamente uma vez, a partir do método “run” da minha implementação do QThread no Mapper. Colocando o método depthFirstTraversal para rodar, primeiramente ele obtêm todos os arquivos do diretóro, chamando o método entryList, da classe QDir. Então um iterator é instanciado sobre a lista de arquivos anteriormente obtida, e, enquanto estiver iterando sobre os arquivos, e antes que qualquer coisa eu faço uma chamada à função wait da estrutura QWaitCondition: a “wait condition” é um tipo de variável de condição usada para sincronizar threads, interrompendo-o no caso de ter obtido 5 arquivos (claro, pode ser qualquer número que você queira). Porque obter exatamente 5 arquivos e interromper a execução, esperando para que a estrutura QWaitCondition seja liberada? Isso é usado de forma a criar um buffer com capacidade para 5 arquivos (no máximo), a partir do qual o thread Reducer pode iterar sobre cada um dos arquivos listados pelo thread Mapper, abrir cada um desses arquivos, e procurar pelo critério de busca dado. Dessa forma, o thread Reducer pode lidar apenas com uma lista de 5 arquivos, esgotá-la, e depois permitir que o Mapper preencha com mais alguns novos arquivos encontrados. Essa é a primeira regra usada para sincronizar os 2 threads: “Mapper, comece a cobrir o buffer com os nomes dos arquivos encontrados, até que ele tenha 5 elementos. Daí, espere até que o Reducer consuma alguns desses arquivos, pois a partir disso você pode obter mais alguns arquivos. Faça isso até o fim dos tempos”. Agora, o thread Reducer, obtendo todos os arquivos que o Mapper consiga procurar:

void KeySearchReduce::run()

{

DirEntry dirEntry;

int cnt = 0;

{

prod->producerMutex.lock();

if (prod->myFileCount == 0)

{

prod->bufferNotEmpty.wait(&prod->producerMutex);

if (prod->isSearchDown())

{

prod->producerMutex.unlock();

return;

}

prod->producerMutex.unlock();

prod->queueMutex.lock();

dirEntry = prod->getFirstTextFile();

prod->queueMutex.unlock();

QFile infile(dirEntry.getFileName());

if (!infile.open(QIODevice::ReadOnly | QIODevice::Text) )

continue;

QString line;

unsigned int i = 0;

QTextStream in(&infile);

if ( dirEntry.getFileType() ==

FileSearchMap::TXT_FILE_PATTERN ) {

while (!in.atEnd())

{

line = in.readLine();

++i;

if ( i == 4 ) {

lineP2Count += atol(line.toLocal8Bit().constData());

++foundCount;

break;

}

} // while

} else if ( dirEntry.getFileType() ==

FileSearchMap::XML_FILE_PATTERN ) {

while (!in.atEnd())

{

line = in.readLine();

++i;

if ( i == 5 ) {

lineP1Count += atol(line.toLocal8Bit().constData());

++foundCount;

break;

}

} // while

} // if - getFileType()

infile.close();

prod->producerMutex.lock();

prod->myFileCount--;

prod->producerMutex.unlock();

prod->bufferNotFull.wakeAll();

} while (!prod->isSearchDown());

}

O Reducer na primeira linha do comando “do” diz o seguinte: “Ei Mapper, você tem algum arquivo para que eu possa procurar pelo informação numérica na linha X? Caso você não tenha arquivo algum, eu esperarei um pouco, até que você tenha algo para mim...” Então, para cada arquivo que o thread Reducer processa, ele avisará ao Mapper, de forma a que ele possa alimentar mais o buffer. No caso do Mapper estiver dormindo em um buffer cheio com 5 elementos, ele será acordado e então recomeçará a cobrir o buffer com arquivos – isso é feito com uma chamada a prod->bufferNotFull.wakeAll(), encontrado no fim do loop principal do Reducer. A chamada a wakeAll faz com que todos os threads que estejam dormindo sobre essa variável de condição acordem imediatamente (ou quase). Com isso, o Mapper pode estar dormindo na linha bufferNotFull.wait(&producerMutex), no início do loop de busca, e essa chamada à função wakeAll a partir do Reducer pode liberar o bufferNotFull (uma instância do QWaitCondition), permitindo ao Mapper reiniciar o processo de completar o seu buffer de 5 elementos de novo. Tudo o que o Mapper tem que fazer é cobrir o buffer com nomes de arquivos.

Nós estamos lidando aqui com recursos compartilhados, e os mutexes são de uso obrigatório (veja as referências às instâncias de QMutex no código fonte) uma vez que essa aplicação é multithreaded, e não queremos que ocorram condições de corrida.

Colocando tudo junto:

FileSearchMap* mapper = new FileSearchMap;

KeySearchReduce* reducer = new KeySearchReduce;

mapper->setDirectory( dir );

reducer->setMapper( mapper );

mapper->start();

reducer->start();

mapper->wait();

reducer->wait();

long long a1, a2;

cout << argv[1] << " contains " <<>getFoundCount()

<< " files that contains " <<>getLineCount()

<< " lines for the pattern 1 ( " << (a1 = reducer->getLineP1Count()) <<

" ) and pattern 2 ( " << (a2 = reducer->getLineP2Count()) << " )." << endl;

long long response = a1*a2;

cout << "Response: (" <<>")" << endl;

Aqui, a chamada getLineP1Count() retorna a soma de todos os numeros na linha 4, nos arquivos com o primeiro padrão; e getLineP2Count() faz o mesmo para o padrão de busca 2.

Claro, dá pra resolver o problema todo sem usar capacidade de multithread, mas aí não tem graça! :)

Doctor Dobb's Code Talk

2008-06-20T20:08:00.004-03:00

Para quem gosta de ler coisas sobre programação, um excelente site sempre foi o da revista Doctor Dobb's Journal [www.ddj.com]. Agora eles disponibilizaram um serviço de blog para os leitores. As discussões são sempre muito interessantes, para quem gosta de coisas como otimização de código, "thread-local heaps", arrays multi-dimensionais, desenvolvimento de software distribuído, e qual a melhor máquina para programar. Quem tiver a fim de participar, começa dando uma olhada no meu blog:
http://dobbscodetalk.com/index.php?option=com_myblog&task=view&id=531&Itemid=29

Vejo vocês lá!

Google Treasure Hunt 4

2008-06-16T19:33:00.013-03:00

O Google resolveu disponibilizar uma espécie de competição, onde são propostos problemas e pede-se a solução deles, cujas respostas sugerem (na verdade, praticamente obrigam) a aplicação de algum recurso computacional. Até onde eu sei, os problemas são únicos para cada candidato, o que inviabiliza qualquer tentativa de “trabalho em conjunto”. Chama-se de “Google Treasure Hunt 2008” [http://treasurehunt.appspot.com/]. O conjunto de problemas apresentado (atualmente, contando com apenas 4) assemelha-se aos vistos em outros campeonatos de programação, como o International Collegiate Programming Contest (ICPC), da Association for Computing Machinery (ACM) [www.acm.org]. Resolvi o último desses problemas (o quarto), e detalho aqui como cheguei à solução.

O problema proposto foi o seguinte:

“Find the smallest number that can be expressed as

the sum of 11 consecutive prime numbers,

the sum of 25 consecutive prime numbers,

the sum of 513 consecutive prime numbers,

the sum of 1001 consecutive prime numbers,

the sum of 1129 consecutive prime numbers,

and is itself a prime number.

For example, 41 is the smallest prime number that can be expressed as

the sum of 3 consecutive primes (11 + 13 + 17 = 41) and

the sum of 6 consecutive primes (2 + 3 + 5 + 7 + 11 + 13 = 41).”

Para solucionar o problema proposto, resolvi utilizar a linguagem de programação C++, pelos recursos que a STL oferece (estruturas como set’s, vector’s, operações sobre conjuntos, etc.). Antes de tudo, o grande problema foi o de gerar os números primos. De modo que o problema não se refere a um limite razoável para a quantidade de números primos que a solução envolva, gerar uma tabela com todos os números primos até o limite considerável de 100.000, por exemplo, resolvi obter uma listagem pronta com o todos os números primos abaixo de 100 mil [http://members.aol.com/MICRO46/primes_1.zip], um total de exatamente 78498 primos. A razão de usar uma tabela pronta foi que o método que eu estava usando para gerar essa lista de primos demorava algo em torno de 4 minutos... Posteriormente, otimizei o procedimento para durar menos de 0,5 segundos, e gerei o resultado em disco. Contudo, quem não tiver afim de gerar essa quantidade de primos, esses arquivos prontos são uma mão na roda. Com o conjunto de primos em mãos, apliquei o procedimento seguinte:

1) Calcular as somas dos números primos em cada um dos intervalos (11, 25, 513, 1001, 1129) – isso implica em somar os primos em todos os subintervalos de tamanho 11, por exemplo, dentro do conjunto de primos, o que gerou uma seqüência de 78488 intervalos de tamanho 11, até 77.370 subintervalos de tamanho 1129;

2) Fazer uma intersecção de conjuntos, 2 a 2, com os conjuntos resultantes da operação acima (por exemplo, as somas de todos os subintervalos de tamanho 11 geram um conjunto) – o objetivo é obter as somas que são comuns entre esses conjuntos de somatórios de primos;

3) Ordenar o conjunto intersecção resultante e mostrar o primeiro valor (ou seja, o menor).

Para as etapas 1 e 2, o método que usei foi o seguinte:

void

sum_subintervals(const vector<long>& primes, unsigned long max,

set<long>* pivot)

{

unsigned long soma = 0, j = 0, old_sum = 0;

set<long> sums;

for (j = 0; j <>

{

soma += primes.at(j);

} // for

sums.insert(soma);

while ( (j <>

{

old_sum = soma;

soma = old_sum - primes.at(j-max) + primes.at(j);

++j;

sums.insert(soma);

}

set<long> s;

if (pivot->size() != 0)

{

set_intersection(sums.begin(), sums.end(), pivot->begin(),

pivot->end(), inserter(s, s.end()) );

pivot->clear();

copy(s.begin(), s.end(), inserter(*pivot, pivot->begin()));

}

else

{

copy( sums.begin(), sums.end(), inserter(*pivot, pivot->end()) );

}

O código é pouco óbvio, mas eu explico: o que ele faz é pegar intervalos de um certo tamanho (11, 25, 513, etc.) e somar os elementos nesse intervalo. Uma solução bastante elementar seria tentar somar diretamente todos os valores, e fazer isso para cada intervalo. Computacionalmente, no entanto, esse método repete desnecessariamente operações de soma (a maior parte dos elementos seriam somados duplicados entre subintervalos consecutivos). Foi exatamente nessas somas supérfluas que o algoritmo que eu fiz gerou otimizações. Por exemplo, o primeiro subintervalo de tamanho 11 é o seguinte:

{2, 3, 5, 7, 11, 13, 17, 19, 23, 29, 31}

O próximo subintervalo é assim:

{3, 5, 7, 11, 13, 17, 19, 23, 29, 31, 37}

Qual a diferença entre os 2? No segundo, inseriu-se o 37 e removeu-se o 2. De forma geral, cada subintervalo adiciona à seqüência anterior o próximo elemento primo, e remove o primeiro elemento da sequência anterior do resultado. Aplicando esse método iterativamente, foi possível reduzir a complexidade da solução de uma exponencial (em função do quadrado do conjunto de primos) para uma solução linear, com o esforço de execução variando apenas sobre o tamanho da tabela de primos.

Pra finalizar, a parte mais simples do código apenas mostra o algoritmo acima rodando em cima de cada constante do problema:

set<long> all_sums;

int nums[5] = { 11, 25, 513, 1001, 1129 };

int i;

for (i = 0; i < 5; i++)

{

sum_subintervals(primes, nums[i], &all_sums);

}

if (all_sums.size() > 0)

cout << "Solution: " << *(all_sums.begin()) << endl;

Nem precisei ordenar o conjunto resultante, porque a classe template “set” da Standard Template Library já adiciona os elementos em ordem na estrutura. Quando tudo dá certo, na submissão aparece isso:

Correct answer: XXXXXXXXXX
Your answer was: Correct

Your answer was correct! Congratulations, you're part-way there.
There will more questions over the coming weeks, and the first person to answer them all correctly will win a prize, so keep trying!

Boa sorte!

CCNA / WANs

2008-05-28T18:48:00.001-03:00

Questão CCNA sobre “Wide Area Networks” (WAN):

“Why won’t the serial link between the Corp router and the Remote router come up?

Corp#sh int s0/0

Serial0/0 is up, line protocol is down

Hardware is PowerQUICC Serial

Internet address is 10.0.1.1/24

MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec,

reliability 254/255, txload 1/255, rxload 1/255

Encapsulation PPP, loopback not set

Remote#sh int s0/0

Serial0/0 is up, line protocol is down

Hardware is PowerQUICC Serial

Internet address is 10.0.1.2/24

MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec,

reliability 254/255, txload 1/255, rxload 1/255

Encapsulation HDLC, loopback not set

A. The serial cable is faulty.

B. The IP addresses are not in the same subnet.

C. The subnet masks are not correct.

D. The keepalive settings are not correct.

E. The layer 2 frame types are not compatible.”

Avaliando cada um dos itens, temos que a letra “A” não pode ser verdadeira porque, se assim o fosse, a mensagem após o comando “sh int s0/0” (ou melhor, “show interface serial0/0”) indicaria que a interface Serial0/0 estaria “down” e não “up” (“Serial0/0 is up”). Tal informação indicaria uma falha física, como um cabo serial desconectado ou com defeito – contudo as coisas parecem funcionar na linha física serial. Apenas após a vírgula vemos algo mais esclarecedor; há uma mensagem indicativa dizendo “line protocol is down”. O protocolo estar não-funcional, mas a linha serial estar perfeita, nos faz levantar 2 hipóteses possíveis: se estivéssemos trabalhando com mecanismos de roteamento dinâmico, divergências em parâmetros de sincronização do tipo “Dead timers” (como os encontrados no RIP e no EIGRP) que especificam o tempo em que uma mensagem permanece válida até ser automaticamente descartada dentro do tempo determinado (estratégia usada para evitar loops de roteamento), poderia causar problemas de comunicação e gerar mensagens de “protocol is down”; caso não estejamos lidando com algoritmos de roteamento, inúmeros utilitários do Cisco IOS poderiam ser úteis aqui, mas das telas podemos deduzir de forma direta o que pode estar ocorrendo de ruim...

Acontece que os protocolos PPP e HDLC não são inteiramente compatíveis. Para não conhecedores das plataformas Cisco, isso pode parecer um contra-senso, porque o protocolo PPP prevê o uso do HDLC para encapsular datagramas sobre linhas seriais. Acontece que o HDLC ao qual a listagem acima se refere diz respeito a uma versão proprietária do High-Level Data Link Control, que funciona com um formato diferente de frame HDLC, incluindo um campo a mais chamado “Proprietary”. Esse belo fruto da inovação Cisco é incompatível com o padrão ISO HDLC, e acaso você queira interligar roteadores de diferentes fabricantes, vai ser melhor optar por um formato padrão de encapsulamento como o PPP.

Voltando ao mostrado no enunciado, e do acima exposto, temos que os roteadores acima estão utilizando formatos diferentes e incompatíveis de roteamento: HDLC no roteador Remote, e PPP no roteador Corp. Trocar o formato de um ou de outro já resolveria o problema, e portanto a letra “E” esclarece exatamente a razão do problema, porque ambos HDLC e PPP são protocolos de enlace de dados, ou seja, de camada 2 (layer 2).

Access Control Lists - ACLs

2008-05-14T18:46:00.002-03:00

Tópicos que tem ocorrido com mais freqüência são aqueles relacionados com segurança, apesar de ser um assunto mais freqüente em exames mais avançados como o CCNP e o CCIE. Na questão abaixo, um exemplo básico com Access Control Lists (ACLs), retirado do livro “CCNA Study Guide, Sixth Edition”, do Todd Lammle:

“You configure the following access list:

access-list 110 deny tcp 10.1.1.128 0.0.0.63 any eq smtp

access-list 110 deny tcp any eq 23

int ethernet 0

ip access-group 110 out

What will the result of this access list be?

A. Email and Telnet will be allowed out E0.

B. Email and Telnet will be allowed in E0.

C. Everything but email and Telnet will be allowed out E0.

D. No IP traffic will be allowed out E0.”

Na questão, uma lista de comandos do roteador é apresentada, e pede-se o resultado da execução de tal lista num roteador hipotético. Aqui deve-se ter sempre em mente uma interpretação recorrente nas provas da Cisco: que o que não constar da relação de comandos, presume-se que foi omisso. Ou melhor, a lista de comandos começa exatamente com a primeira sentença de “access-list ...”, e termina com “ip access-group 110 out”. O trecho então não é parte de uma entrada do administrador de rede, mas sim uma sequência completa e indivisível de comandos.

Os comandos de access-lists na questão acima são no formato “extended”, ou seja, são no formato que começa com a definição da ação (“deny” ou “permit”), o intervalo de hosts de origem, o intervalo de hosts destino e, possivelmente, condições que especificam em que porta a restrição vai se impor. As listas extended são numeradas com identificadores de 100 a 199, e com elas é possível filtrar pacotes por campos IP de camada 3 e até alguns serviços de camada 4 ou maior (WWW, Telnet, SMTP, etc.), o que amplia o espectro de usos possíveis para as ACLs, como por exemplo mitigar ataques Denial-of-Service (DoS), DoS Smurfs, IP Spoofing, etc. É possível estabelecer regras que serão aplicadas especificamente a pacotes TCP com a flag SYN setada, por exemplo, o que serve de ajuda contra ataques de SYN flood. Certo, apenas “mitigar”, não necessariamente impedir tais ataques, dada a dificuldade em definir regras sobre grupos de pacotes suspeitos num universo tão grande de possibilidades de ataques. Mas a utilidade das ACLs ainda assim é muito bem vinda e quebra alguns galhos.

Quando é preciso definir regras que se apliquem a apenas um par de hosts, como a sentença “access-list 110 deny ip host 172.16.10.3 host 172.16.20.5”, por exemplo, que bloqueia pacotes IP com campo de origem 172.16.10.3 e destino para 172.16.20.5, a tarefa é imediata. Contudo, é mais comum, na definição das regras de ACLs, quando é necessário que sejam aplicadas regras a um intervalo de hosts numa sub-rede, pode-se recorrer aos wildcards. Vamos dizer que queiramos aplicar determinada regra ao conjunto de hosts nas sub-redes de 192.168.113.0 até 192.168.140.0. Primeiro, calcule quantas sub-redes existem entre os endereços anteriores; diminuindo 113 de 140 (140 – 113), obtemos 27. Agora é preciso achar uma potência de 2 que seja maior ou igual a esse intervalo; temos que 32 é maior que 27 (16 é outra potência de 2, mas é menor que 27), e portanto nos serve para esse propósito. Esse valor é 32 é o tamanho do bloco, e quando diminuído de 1, nos traz o endereço de wildcard. Nesse caso, temos que o endereço de wildcard para esse intervalo é 0.0.31.255. O terceiro octeto, que guarda informações das sub-redes onde serão aplicadas a regra de ACL, tem valor 31, representado um bloco de 32 (192.168.113.0 até 192.168.145.0). Esse intervalo é maior do que o que o intervalo que queremos, mas serve ao propósito. O quarto octeto contêm um valor de 255, que permite a presença de qualquer valor, e nos garante que todos os hosts nessas sub-redes sejam também contemplados com a regra ACL.

De volta à questão, a primeira sentença aplica a regra de que será descartado qualquer pacote SMTP (porta 25) com origem em quaisquer dos hosts em 10.1.1.128 até 10.1.1.192 (wildcard = 0.0.0.63, bloco igual a 64). A segunda regra descarta todos os pacotes com destino ao serviço de Telnet (porta 23). Logo a seguir, essas 2 regras são aplicadas à interface E0 (ethernet0) para saída (“out”), ou seja, em “post-routing”, após o pacote ter sido roteado localmente no roteador e estar prestes a ser encaminhado para a interface de saída, as regras são aplicadas. A princípio, até aí tudo bem, temos 2 regras, uma que nega totalmente serviços para a porta 23, e outra que nega serviço SMTP (porta 25) para um conjunto de hosts. A alternativa C parece convidativa, mas algo vai errado na lista de acesso: se era esse o fim almejado pelo administrador (negar pacotes para serviços portas 23 e 25), ele deveria ter incluído a regra “permit ip any” no final da lista de acesso, porque a última regra é “deny ip any”, o que faria com que qualquer pacote tivesse o repasse concedido pela interface ethernet0. Devido à omissão dele, a interface E0 vai perder comunicação com o mundo. Alternativa D é a correta.

RIP Troubleshooting

2008-04-28T21:35:00.004-03:00

Continuando na linha dos enunciados que abranjam o maior número de conceitos, temos essa questão, que apresenta pontos importantes e que costuma marcar presença nas seções da prova CCNA relacionadas a troubleshooting e protocolos de roteamento:

“Which of the following is true regarding the following output? (Choose two.)

04:06:16: RIP: received v1 update from 192.168.40.2 on Serial0/1

04:06:16: 192.168.50.0 in 16 hops (inaccessible)

04:06:40: RIP: sending v1 update to 255.255.255.255 via FastEthernet0/0 (192.168.30.1)

04:06:40: RIP: build update entries

04:06:40: network 192.168.20.0 metric 1

04:06:40: network 192.168.40.0 metric 1

04:06:40: network 192.168.50.0 metric 16

04:06:40: RIP: sending v1 update to 255.255.255.255 via Serial0/1 (192.168.40.1)

A. There are three interfaces on the router participating in this update.

B. A ping to 192.168.50.1 will be successful.

C. There are at least two routers exchanging information.

D. A ping to 192.168.40.2 will be successful.”

Um ponto que merece destaque nessa questão é procurar listar o que ela quer que você saiba, a partir da situação exposta. Na assertiva A, o que ela procura saber sobre a quantidade de interfaces de rede. As assertivas B e D, sobre a conectividade com as redes 192.168.40.0 e 192.168.50.0, ou melhor, se pacotes ICMP “ping” podem ser enviados e recebidos com sucesso para essas redes. A letra D pede o número mínimo de roteadores na transação acima.

Para saber exatamente quantas interfaces estão participando no cenário acima, é útil olhar cuidadosamente nos trechos do log que mencionam atualizações (updates) de tabelas de roteamento RIP, saindo do roteador atual para o mundo externo. As linhas 3 e 8, do log em negrito, anunciam envios (sending) para atualização de tabelas de rotas, que passam respectivamente, “via FastEthernet0/0” e “via Serial0/1”. Como não existem mais mensagens desse tipo (“sending v1 update”), do acima exposto podemos deduzir que apenas 2 interfaces de rede são apresentadas. A assertiva A é falsa, pois alega um mínimo de 3 (o mínimo é 2).

Dos questionamentos sobre o número de interfaces no roteador, partimos para a quantidade de roteadores que participam das mensagens de debug do RIP, anunciando e/ou recebendo rotas novas. Se mensagens do tipo “sending v1 update” nos ajudaram a encontrar as interfaces de rede, as mensagens “received...” vão nos dizer quais (e principalmente quantos) roteadores participam do handshake do RIP pra estabelecimento dinâmico de rotas, uma vez que apenas roteadores podem anunciar e atualizar rotas. Do parágrafo anterior, vemos que esse roteador anuncia (mensagens “sending...”) através de 2 interfaces (Serial0/1 e FastEthernet0/0), e recebe uma atualização de rotas através da Serial0/1 (do roteador 192.168.40.2). Temos 2 roteadores, um que é o roteador local (a partir do qual temos acesso à mensagem de log), e outro que emite uma mensagem de anúncio de rotas (192.168.40.2, via interface Serial0/1). A letra C está certa.

Restam-nos as letras B e D. As linhas 2 e 7 nos dizem a mesma coisa, ou seja, que a rota para a rede 192.168.50.0 é “alcançada” após 16 hops, e portanto inalcançável (linha 2). A linha 7 nos descreve que essa mesma rede tem métrica 16, o que significa a mesma coisa, em vista do fato de que o RIP tem métrica máxima de 15, para rotas possíveis e roteáveis. Métrica 16 é rota inacessível, desligada pelo administrador ou “envenenada” pelo próprio algoritmo do RIP, para evitar anúncios de circulares de rotas impossíveis (estratégia conhecida como “poisonous routing”, envenena a rota e anuncia ela desse jeito, para que as outras redes a enxerguem como proibida e assim evitar que outros roteadores na área administrativa anunciem essa rota inválida a outros roteadores). Como esse host 192.168.50.1 faz parte da rede 192.168.50.0, e como essa rede é métrica 16, um ping para esse host retornaria uma mensagem de inalcançável. Letra “B” está errada.

A letra D quer saber se um ping para o host 192.168.40.2 pode ser alcançável, e a resposta é sim, e temos 2 evidências para garantir isso: primeiro, que na linha 6 vemos que quando o roteador vai construir as entradas da tabela de roteamento, momento no qual algumas rotas dinâmicas externas são reconhecidas e acrescentadas, a rota para a rede 192.168.40.0 apresenta-se com métrica 1 – isso quer dizer que a rota para essa rede passará primeiro pelo “next hop router”, ou seja, o roteador vizinho, conectado pela interface Serial0/1. Uma métrica ótima, que perde apenas para as métricas de rotas estáticas e para as diretamente conectadas (as com flag “S” e as com métrica 0, respectivamente). Isso serviria para garantir que a rede 192.168.40.0 é acessível, mas não que um ping para o host 192.168.40.2 pode ser realizado com sucesso. Contudo, a primeira linha de log nos garante isso, porque o anúncio da tabela de rotas para essa rede veio exatamente do roteador de endereço IP 192.168.40.2. Uma coisa legal com roteamento dinâmico é que as rotas são configuradas nas 2 direções, e se recebemos uma mensagem de 192.168.40.2, certamente que poderemos enviar mensagens para lá também (a menos que uma ACL tenha sido colocada de barreira, impedindo tráfego ICMP de saída no roteador conectado à S0/1). A letra D está correta também.

Respostas: C e D

Sub-redes e Roteadores

2008-04-16T19:29:00.001-03:00

Uma questão do exame CCNA muito interessante, que resume muitos dos conceitos sobre as funções básicas dos dispositivos de roteamento e segmentação em sub-redes:

“A router receives a packet on interface 172.16.45.66/26. The source IP of the packet is 172.16.45.127/26 and the destination is 172.16.46.191/26. How will the router handle the packet?

A. The destination is a host on another subnet, so the router will not forward the packet.

B. The destination is a host on the same subnet, so the router will forward the packet.

C. The destination is a broadcast address, so the router will not forward the packet.

D. The destination is a network address, so the router will forward the packet.”

A princípio, percebemos que todos os endereços IP são /26, ou seja, os 2 bits iniciais do quarto octeto são usados para identificação de sub-redes (24 < 26 < 32, ou seja, quarto octeto), e os 6 restantes são usados para host, o que nos dá um total de 4 sub-redes (2 bits de rede, elevado a 2) e 62 hosts (contando os endereços reservados para a base da rede, e para o broadcast da respectiva sub-rede, teríamos um total de 64). Como o número de sub-redes é bastante restrito, convêm que listemos cada um desses intervalos, para averiguarmos as condições de chegada desse pacote:

172.16.46.0 à 172.16.46.63 (0-63)

172.16.46.64 à 172.16.46.127 (64-127)

172.16.46.128 à 172.16.46.191 (128-191)

172.16.46.192 à 172.16.46.255 (192-255)

A matemática básica para a enumeração desses intervalos de sub-redes é simples: basta obter o comprimento de cada intervalo, calculando o espaço reservado para os hosts no endereço base acima: ou seja, 6 bits denotam um espaço de representação de 64, então a primeira sub-rede iniciará no IP terminado em 0, e terminará no IP terminado em 63 (63 – 0 + 1 = total de 64). O endereço inicial da próxima sub-rede será o último endereço válido para a sub-rede antecedente mais 1, ou melhor, 172.16.46.64 (63 + 1), e o endereço final será 64 (endereço inicial) mais o número de hosts nesse intervalo (64, igual para todas as sub-redes), menos 1, porque começamos a numeração com 0, desde o primeiro subintervalo. E assim, prossegue-se até que todos os intervalos tenham sido listados.

A partir da lista de sub-redes que fizemos, percebemos que o endereço de destino 172.16.46.191 é um endereço de broadcast. O endereço de broadcast será sempre o último numa dada sub-rede (por isso mesmo, não contabilizamos esse endereço na atribuição de um host válido dentro de uma determinada sub-rede – ele será sempre reservado para broadcast). Ora, temos que os roteadores segmentam as redes em domínios de broadcast, e por isso, não perpetuam pacotes incidentes em suas portas que tenham um endereço de broadcast como destino (popularmente falando, endereços de broadcast não são roteáveis). A letra C é a resposta.

Uma observação: veja que o endereço fonte do pacote direcionado pelo roteador, pertence à mesma sub-rede da interface do roteador, ou seja, a sub-rede de 172.16.46.64 até 172.19.46.127 ( 64 < 66 < 127 ). O que aconteceria se isso não fosse verdadeiro, se o endereço fonte estivesse em um segmento de rede divergente da que a interface do roteador pertença?

Segmentação em Sub-redes

2008-04-09T19:41:00.000-03:00

Uma matéria comum às questões do exame CCNA, refere-se aos cálculos de sub-rede. A maior parte das questões não obriga a realização de cálculos extensivos, mas envolvem prática com as regras de segmentações em sub-redes, saber discernir entre endereços de escopo privado e público, bem como ter alguma noção do sistema de numeração binário. Ainda, noções básicas sobre Teoria dos Números, principalmente no que diz respeito à divisibilidade, pode ser bastante útil (mas não imprescindível).

Na questão abaixo, apresenta-se um endereço IP válido e pede-se qual a sub-rede que envolve o endereço dado:

“What is the subnet address of the host with an IP address of 172.16.159.159/22?

A. 172.16.128.0

B. 172.16.156.0

C. 172.16.159.128

D. 172.16.159.0

E. 172.16.192.0

F. 172.16.0.0”

A princípio, percebemos que só serão válidos endereços de sub-rede nas assertivas acima que se refiram à classe B – por ser um endereço de rede /22, e sendo 22 maior que 16 (segundo octeto) e menor que 24 (que se referiria ao quarto octeto), decorre disso que foi expandido o espaço de 16 bits de rede originais da classe B, para 22 bits de rede. Ou seja, com 6 bits (22 – 16) mascarados no terceiro octeto destinados a identificação de sub-redes, e com 10 bits (32 – 22) restantes para referência a host, deduz-se facilmente que são permitidas 64 sub-redes nessa configuração, com 1022 (2 elevado a 10, menos 2) hosts possíveis em cada uma das sub-redes (elimina-se 2 do total de hosts, simplesmente porque um dos endereços é para identificar a própria sub-rede, e o outro endereço não contabilizado como host é o endereço de broadcast, também único para cada sub-rede).

Voltando ao que é necessário ao enunciado, precisamos saber qual sub-rede engloba o host referido. A máscara de rede é de classe B, mas com 2 bits mascarados para host no terceiro octeto, mais 8 desses bits no quarto e último octeto. Esses 2 bits do terceiro octeto são pertinentes para nossa solução, porque são exatamente eles que conferirão mobilidade para a quantidade de sub-redes, por conta do seguinte: 6 bits do terceiro octeto podem variar indistintamente, mas os outros 2 bits são fixos, ou invariáveis, no que se refere à numeração de sub-redes, porque esses 2 bits se referem a hosts, e não são contabilizados na seqüência de sub-redes disponíveis. Isso significa dizer que, sempre que formos atribuir uma sub-rede válida a essa máscara, devemos notar que os 6 bits denotam livremente uma sub-rede, mas os 2 bits do terceiro octeto não podem ser “invadidos” pelos bits de sub-rede (pois pertencem a hosts). Essa é a lógica na criação de sub-redes: alguns bits válidos da seção original de host são desperdiçados para que possam então ser criadas mais sub-redes, e facilitar a segmentação dos hosts, o que traz diversas vantagens, como a departamentalização da rede e o incremento em segurança, por exemplo. No nosso caso, com uma máscara de classe B, teríamos 16 bits para rede, e 16 bits para host: em alguns casos, 16 bits para os hosts pode ser demasiado, portanto alguns desses bits poderiam ser usados para segmentação de redes (no nosso caso, expandimos para mais 6 bits de sub-redes). Por exemplo, a seqüência a seguir compõe-se de sub-redes válidas para a máscara /22 (255.255.252.0): 172.16.148.0, 172.16.152.0, 172.16.156, e assim por diante, sempre de 4 em 4, por conta dos 2 bits de host que são invariáveis, exclusivamente no que diz respeito à numeração de sub-redes.

Já que o terceiro octeto dos endereços de sub-rede que fazem parte da rede 172.16.0.0 denota parte da sub-rede, com 6 bits, e parte do host, com 2 bits, a faixa de endereços disponíveis para sub-redes inicia-se em 0 no terceiro octeto, e vai saltando de 4 em 4 (por conta do total de combinações dos 2 bits reservados para hosts). A faixa de endereços válidos é então: 172.16.0.0, 172.16.4.0, 172.16.8.0, 172.16.12.0, ..., 172.16.252.0 (num total de 64 sub-redes). Dessas 64 sub-redes, apenas uma delas engloba o endereço 172.16.159.159. Para que a encontremos, teremos que encontrar o primeiro número inteiro menor do que 159, e que seja divisível por 4. Aplicando esse processo na prática, pegamos o número 159 (terceiro octeto, que nos interessa), e dividimos por 4 – daí, vemos que dessa divisão decorre um número fracionário (39,75), ou seja, retorna resto, portanto, não divisível por 4. Passamos então para o número imediatamente anterior (158), dividimos por 4, o que nos dá 39,5, que também não é o que queremos. Continuando nesse processo, percebemos que 156 divide 4 (sem resto). E é exatamente essa a resposta: 172.16.156.0, a sub-rede referente ao endereço de host 172.16.159.159 (/22). Resposta: letra “B”.

Mais um assunto típico de prova, mas que do ponto de vista do dia-a-dia do profissional de redes, implica na maior parte apenas curiosidade típica de “hackers”, que se interessem por saber a qual sub-rede pertença um dado host – um gerente de redes competente mantém sempre uma documento com as faixas de sub-redes configuradas. Mas, é lógico, automatizar mentalmente o cálculo de faixas de redes é sempre uma ajuda...

STP - Spanning Tree Path Cost

2008-03-18T20:17:00.001-03:00

Uma questão mais simples sobre o processo de “Spanning Tree”, essencial para o entendimento de eliminação de loops de rede a nível de enlace em switchs:

By default, which of the following factors determines the spanning-tree path cost?

A. It is the individual link cost based on latency

B. It is the sum of the costs based on bandwidth

C. It is the total hop count

D. It is dynamically determined based on load

O protocolo STP (“Spanning Tree Protocol”) é definido por um padrão IEEE chamado 802.1d, e foi inicialmente desenvolvido pela Digital Equipment Corporation (DEC). Como costuma ocorrer com freqüência num mundo dominado por padrões tecnológicos, a especificação oficial da IEEE para o STP não é de todo compatível com a versão criada pela DEC. Contudo, há atualmente um esforço em desenvolver um protocolo STP que seja efetivamente compatível com a especificação inicial, que será chamado 802.1w.

De forma simples, o protocolo STP evita que ocorram loops a nível de rede em switches de camada 2 (camada de Enlace, no modelo OSI). Atuando de forma intermitente, o algoritmo do STP (chamado, de forma óbvia, Spanning Tree Algorithm) cria uma topologia ótima (ou quase ótima) da rede, na qual não ocorram rotas redundantes, e links de switches que sirvam de conexão a rotas que possam ocasionar redundância são desligados em determinados momentos (principalmente quando os switches conectando segmentos de uma rede estão em processo de convergência – uma fase necessária quando os switches negociam quais rotas eles manterão, e quais links precisarão ser bloqueados). Para que isso ocorra, cada porta de um switch pode estar em um dos seguintes estados: Blocking (Bloqueado), Listening (Escutando), Learning (Aprendendo), Forwarding (Repassando) e Disabled (Desabilitada). Os nomes são auto-explicativos, mas uma observação importante merece ser dada para 2 desses estados: o estado Learning significa que o switch está efetivamente preenchendo sua tabela de endereços MAC, usados no roteamento a nível de enlace; e o estado Listening, um meio termo entre Blocking e Forwarding, significa que nem a porta está bloqueada (ou seja, recebe os frames de sincronização do STP – também chamados de BPDUs, ou “Bridge Protocol Data Unit”), nem muito menos pode repassar frames adiante. O objetivo disso tudo é que depois do switch ter passado pelo necessário estágio de convergência (passagem da porta de Blocking para Forwarding), e assim a rede esteja sem loops de roteamento, ele possa enfim repassar para frente os frames recebidos...

Voltando à resposta, a convergência no STP passa por uma etapa em que uma das portas é eleita a “porta designada”, que vem a ser a porta com a largura de banda mais alta – é particularmente importante descobrir quais das portas num switch oferece a maior vazão, porque vai ser unicamente por essa porta que o vai ser calculado o caminho mais curto para o outro switch (sim, para o STP, o caminho mais curto é aquele que passa pela porta com maior largura de banda... apesar de que seria possível inúmeras outras medidas, o STP aceita apenas essa)

Ora, se um caminho (path) pode ser definido por uma seqüência de portas, e uma vez que em cada switch há apenas uma dessas portas que sirvam de caminho, então o custo de uma rota pode ser definido como a soma dos custos de cada uma das portas no caminho. Letra (B) a correta.

OSPF - Open Shortest Path First

2008-02-16T00:08:00.004-03:00

Mais uma questão nos moldes das que são encontradas no exame CCNA, só que dessa vez envolvendo algoritmos de roteamento entre roteadores:


On the topic of the OSPF hello protocol; which of the statements below are true?
(Select two answer choices)
A. The OSPF Hello protocol provides dynamic neighbor discovery.
B. The OSPF Hello protocol detects unreachable neighbors in 90 second intervals.
C. The OSPF Hello protocol maintains neighbor relationships.
D. The OSPF Hello protocol negotiates the correct parameters between neighboring
interfaces.
E. The OSPF Hello protocol uses timers to elect the router with the fastest links at the
designated router.
F. The OSPF Hello protocol broadcast hello packets throughout the internetwork to
discover all routers that are running OSPF.

Resposta: A, C
O protocolo Hello do OSPF (Open Shortest Path First) serve como um meio de estabelecer as relações de vizinhança entre roteadores. É por meio desse tipo de pacote que se torna possível reconhecer potenciais roteadores numa vizinhança, e que poderão ser reconhecidos como "Neighbor Router", "Designated Router", ou "Backup Designated Router", e a partir dos quais serão construídas as listas de adjacências, de onde serão escolhidas as melhores rotas baseadas nos custos das interfaces de saída do roteador. O Hello serve tanto para estabelecer as vizinhaças, como também para mantê-las ativas, sempre que possível e para que rotas que se tornaram inválidas possam ser removidas. Além do protocolo Hello, o OSPF trabalha em conjunto com mais 4 mensagens: Database Description, Link State Request, Link State Update, Link State Ack.
A letra B se refere a um timer de 90 segundos, que não é utilizado pelo OSPF. Apesar disso, é necessário que o timing entre os pacotes Hello subsequentes estejam em sincronia, caso contrário não seria possível relações de vizinhança. (o OSPF usa algo com uma variante do "round-trip time", encontrada no TCP para descobrir de forma ativa quando um envio de pacote não chegou ao destino, e possivelmente não vai ser retransmitido). A letra E é falsa, porque o Hello não serve para identificar quem dos roteadores vizinhos possam estar usando ou não OSPF.

WAN com Frame-Relays no CCNA

2008-01-20T12:00:00.000-03:00

Continuando com a explanação acerca dos objetivos e sobre a forma como as questões são cobertas na avaliação CCNA, irei mostrar alguns exemplos parecidos com os da prova. Pra começar, na questão abaixo, vemos um tema recorrente nos últimos exames, que são aqueles assuntos envolvendo WAN e redes Frame-Relay:

From the network configuration below, both the Matriz and Filial offices are configured as shown below:

Matriz# show running-config
Filial# show running-config

interface Serial0/0 interface Serial0/0
ip address 10.0.8.1 255.255.248.0 ip address 10.0.15.2 255.255.248.0
encapsulation frame-relay encapsulation frame-relay
frame-relay map ip 10.0.15.2 200 frame-relay map ip 10.0.8.1 100
! !
router rip router rip
network 10.0.0.0 network 10.0.0.0

The Filial router can be successfully pinged from the Matriz office, but the Filial users can't access the server at the Matriz office.
Based on the output above, what do you suspect is the cause of this problem?

A. The Frame Relay PVC is down.
B. The IP addressing on the Central/Remote serial link is incorrect.
C. RIP routing information is not being forwarded.
D. Frame Relay inverse-ARP is not properly configured.

Como muitas das questões encontradas no exame, é comum o uso da técnica de eliminar as alternativas menos prováveis (ou absurdas) primeiro. Avaliando as alternativas na ordem, vemos as letras A e B não se configuram como causas para o problema citado na questão, uma vez que, de acordo como o enunciado, é possível obter resultados positivos com as respostas aos pacotes ICMP enviados pelo utilitário "ping". Do suposto no enunciado, está estabelecida sim uma PVC, e as interfaces estão todas funcionando a contento (caso contrário, seriam obtidas mensagens do tipo "Host Unreachable" na resposta ao ping).
A alternativa D refere-se a um recurso chamado Inverse Address Resolution ProtocolIARP) (, que é usado para estabelecer, dinamicamente, números DLCI a endereços IP de interfaces no roteador que serve de ponta a Permanent Virtual Connections (PVCs). Com o IARP, se torna desnecessário estabelecer rotas estáticas para os canais Frame-Relay, mas da leitura do resultado do comando show running-config, vemos que é feito o uso de comandos "frame-relay map", que fazem exatamente a mesma coisa, só que de forma estática. Por não depender do IARP, a afirmativa contida na alternativa D também não explica o mal-funcionamento da rede.
Da remoção das 3 outras alternativas, a alternativa C aponta como a única correta. Revendo a situação proposta, percebemos que as interfaces em questão não estão permitindo broadcast/multicast, o que invalida a atuação do algoritmo RIP de roteamento, uma vez que ele usa de endereços broadcast, na versão 1 do protocolo, e endereços do tipo multicast, na versão 2. O protocolo RIP faz uso de broadcast/multicast para gerar as relações de vizinhança com roteadores próximos, e assim criar a sua topologia de roteamento. E Frame-Relay, por padrão, não repassa broadcasts. Bastaria acrescentar-se a opção broadcast ao comando frame-relay map para se corrigir o defeito de roteamento.

CCNA - Cisco Certified Network Associate

2007-12-26T14:59:00.000-03:00

Semana passada, mais precisamente no dia 21 de dezembro, fui aprovado no exame de certificação da CCNA, da Cisco. Sobretudo em relação ao que falam sobre a prova, cabe salientar que é tudo verdade, as questões são realmente difíceis. Vale ressaltar contudo o abuso de intencionais "cascas-de-banana" que aparecem com cada vez mais frequência à medida que esse exame, antes considerado "entry-level" da Cisco (agora a Cisco criou um mais básico, chamado CCENT), evolui no sentido de dificultar a trajetória de quem se habilita a seguir qualquer um dos "certification path" que a Cisco disponibiliza (Wireless, Security, etc.), onde o CCNA se localiza nos degraus iniciais na escalada Cisco.

Meu exame tinha 49 questões, e 75 minutos pra concluir. A nota mínima é 849, de um mínimo de 300 até um máximo de 1000. Não é permitido voltar à questão anteriormente respondida; uma vez que você tenha clicado no botão "Next", para passar para a próxima questão, não é mais possível corrigí-la. O resultado final é dado no exato momento em que você clica no "Next" da última questão, o que, aliado ao fato de não poder revisar as questões marcadas na prova, torna o resultado final sempre uma surpresa, de fazer gelar qualquer coração adolescente apaixonado... :)

As questões também não se limitam às de múltipla escolha: há tipos bem exóticos de questões, onde é proposto ao candidato um cenário falho de infraestrutura de rede, e lhe é solicitado acessar os respectivos dispositivos danificados de rede e entrar com os comandos que possivelmente tornarão a rede novamente operacional, num simulador em shell do Internetwork Operating System (IOS), o sistema operacional proprietário da Cisco que roda em switches e roteadores. As questões abusam da memorização, portanto não é considerada uma precaução extrema memorizar todas as distâncias administrativas e valores de timers para os protocolos de roteamento disponíveis, os termos técnicos para dispositivos de conexão ISDN e frame relay, nem mesmo as siglas que representam os status de rotas quando se executa comandos como "show ip ospf topology", por exemplo.

Ter passado no exame foi uma maratona de livros e referências, dentre as quais se destacam:
1. CCNA Study Guide, do Todd Lammle (http://www.amazon.com/CCNA-Certified-Network-Associate-640-802/dp/0470110082/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1198692515&sr=8-1);
2. Questões selecionadas do TestKing - CCNA (http://www.testking.com/certs/CCNA.htm);
3. CCNA 4.0: Guia da Certificação, do Marco Fillipetti (cobre bem a teoria, mas falta muito em relação ao nível das questões, que é superficial nesse livro);
4. Boson Router Simulator (http://www.boson.com/) - essencial pra exercitar as questões de simulação de cenários de topologia de rede.

Nos próximos posts, colocarei aqui algumas questões bem parecidas com as que eu vi no exame. Não seria permitido colocar na íntegra, uma vez que os candidatos ao CCNA são obrigados a assinar um contrato de confidencialidade...

Mais sobre GNU Autotools (parte IV)

2007-08-21T20:40:00.000-03:00

Continuando a superficial explanação acerca dos detalhes de definição de um arquivo configure.ac, que definirá como exatamente o build do nosso sistema em questão será gerado, e por quais bibliotecas precisará gerar dependências, veremos mais alguns exemplos de chamada de macros M4 que são de uso mais frequente.

As definições de arquivos configure.ac começam com chamadas de configuração ao autoconf. Para diferenciá-las em relação às macros comuns, remetesse à notação das macros, que assumem o prefixo AC. Por exemplo, a macro AC_CHECK_FUNCS realiza uma busca pelos nomes de funções passadas como parâmetro (listas de parâmetro em M4 são representadas não por vírgulas, mas por sequências de nomes de argumentos de função, separados por espaço e tendo por limites os símbolos especiais '[' e ']'). Após serem encontrados as origens dos nomes de função, o respectivo arquivo de biblioteca e adicionado como parâmetro de compilação dos fontes do sistema. Na chamada abaixo, as funções especificadas são verificadas e seus respectivos headers e binários de bibliotecas são referenciados para serem usados depois, através de variáveis execíficas, como CFLAGS e LDFLAGS:


AC_CHECK_FUNCS([memset socket stime strstr strtoul gethostname inet_ntoa localtime_r select strrchr localtime strptime])

Essa chamada em M4 é especialmente genérica, e pode ser usada de forma incondicional para todo nome de função que se suspeite estar presente no ambiente atual de desenvolvimento. Mas tem-se definidas outras chamadas mais particulares, que buscam por chamadas bem específicas de funções:


# Checks for library functions.
AC_FUNC_FORK
AC_FUNC_STRFTIME
AC_FUNC_MALLOC
AC_FUNC_MKTIME
AC_FUNC_VPRINTF

Todas as funções acima (fork, strftime, malloc, mktime, vprintf) são buscadas no ambiente atual, e adicionadas por padrão aos campos CFLAGS e LDFLAGS (quando necessário).

Pode-se definir parâmetros que são passados ao autoconf para que ele instrua de forma adequada a geração dos Makefiles. No código abaixo usa-se a macro AC_ARG_ENABLE para verificar se o parâmetro de linha de comando --enable-coverage foi aplicado, no caso do desenvolvedor necessitar da funcionalidade de compilação usando os recursos de teste de cobertura (coverage):


AC_ARG_ENABLE(coverage,
       AS_HELP_STRING([--enable-coverage],
               [enable coverage (default = no)]),
               [
                       if test $enableval = no; then
                               USE_COVERAGE=no;
                       else
                               USE_COVERAGE=yes;
                       fi
               ],[
                       USE_COVERAGE=no;
               ]
)

if [ test $USE_COVERAGE = yes ]; then
       CFLAGS="$CFLAGS -fprofile-arcs -ftest-coverage -O0"
       LDFLAGS="$LDFLAGS -lgcov"
fi

Caso o parâmetro --enable-coverage seja passado, a variável $USE_COVERAGE será definida com valor "yes", e serão adicionados os parâmetros necessários como atributos de compilação do gcc.

A chamada abaixo sinaliza ao utilitário automake que seja executado. Ele processará todos os arquivos texto com terminação ".am", e criará a partir deles os arquivos Makefile apropriados:


AM_INIT_AUTOMAKE($PACKAGE, $VERSION)

Tendo o arquivo configure.ac definido corretamente, além dos respectivos Makefile.am (que definirão os processos de compilação e geração das builds, rodando em cima do utilitário make), a execução de autogen.sh (um script de uso bastante difundido, apesar de não vir em distibuição padrão das principais GNU autotools - quase todo projeto autoconf usa um modelo similar de autogen.sh, que simplesmente irá executar os comandos autoconf, automake, libtool, etc. numa ordem pré-estabelecida e funcional).


# ./autogen.sh

O qual terminada a execução, pode vir acompanhado da chamada ao make para que o sistema de software seja compilado e instalado:


# make all install

GNU Autotools (parte III) - Configure.ac

2007-08-16T20:37:00.000-03:00

Chegamos à etapa mais interessante dessa rápida introdução aos recursos de deployment e geração de builds com autotools. Iniciaremos essa exposição detalhando a estrutura do arquivo de configuração configure.ac e as macros M4 úteis na sua composição. Relembrando, o configure.ac é um arquivo útil para se configurar as variáveis de ambiente, onde quer que o aplicativo em desenvovimento precisar ser empacotado. Dentro do configure.ac, declararemos coisas como o nome da distro, números de versão (minor e major versions), as bibliotecas que precisam se verificadas quanto da sua existência, passagem de parâmetros de compilação para os fontes, opções de debug e teste automatizado, etc. Abaixo temos um trecho útil do configure.ac:


#                                               -*- Autoconf -*-
# Process this file with autoconf to produce a configure script.

AC_PREREQ(2.50)

AC_INIT([gmyth],[0.3])

AC_CONFIG_SRCDIR([src/gmyth.h])
AC_CONFIG_HEADER(config.h)

dnl when going to/from release please set the nano (fourth number) right !
dnl releases only do Wall, SVN and prerelease does Werror too
AS_VERSION(gmyth, GMYTH, 0, 3, 0, 0, GMYTH_SVN="no", GMYTH_SVN="yes")
GMYTH_MAJORMINOR=$GMYTH_MAJOR_VERSION.$GMYTH_MINOR_VERSION
AC_SUBST(GMYTH_MAJORMINOR)

(...)

Logo no início do arquivo configure.ac, temos uma chamada à macro M4 AC_PREREQ, que irá definir como obrigatório o uso da versão 2.50 da ferramenta autoconf sobre esse arquivo específico de distribuição. Caso o desenvolvedor que baixe a versão da sua biblioteca no SVN da sua empresa, por exemplo, tentar gerar os builds automáticos e os arquivos Makefile, usando uma versão anterior a 2.50 do autoconf, o procedimento de build terminará com uma mensagem de erro ao usuário, informando a necessidade de uso de uma versão mais atual. A macro AC_INIT atribui um nome para a distro, além de uma versão inicial: isso será de extrema valia quando sua equipe de desenvolvimento estiver gerenciando o lançamento de novas releases do sistema, porque a versão presente nessa tag marcará a forma como funcionará o esquema de versionamento para todos os builds subsequentes. Logo abaixo dessa chamada, temos a AS_VERSION, que detalha a versão do build atual em seções de MAJOR e MINOR version, o que aumenta a precisão com que as releases do seu sistema de software em fase de deployment será lançado, o que costuma tornar mais fácil a comunicação com outras equipes importantes no processo de software, porque cria uma linguagem comum, onde uma equipe de teste, por exemplo, poderá discernir, através da numeração de 4 partes que compõe a versão, se o build representa uma nightly-build, ou um release M1 para usuário final, por exemplo.

A macro AC_SUBST é bastante comum, e representa num arquivo configure.ac a operação de declaração de variáveis, que poderão ser partilhadas entre inúmeros arquivos Makefile.am. Como, a priori, podemos supor que exista um arquivo Makefile.am para cada módulo que compôe o sistema, a importância dessa funcionalidade atribuída por AC_SUBST fica clara, pois aí teremos uma forma de espalhar entre os módulos dados que são de necessidade comum a todos eles (como nesse caso, os números de versão MINOR e MAJOR, que poderão ser usadas por diretivas de compilação em código, denotando compilação condicional de determinados trechos, baseados em versão de build).

Veremos depois mais macros M4 úteis. Mas a boa notícia, que serve sobremaneira na tarefa de gerar o arquivo configure.ac, e a ferramenta autoscan. Para usá-la, simplesmente rode-a dentro do seu diretório de projeto:


# autoscan

Essa ferramenta tem função dupla: caso você não tenha criado uma versão inicial do configure.ac, a ferramenta autoscan irá gerar automaticamente, baseado em inspeção do código da sua aplicação, um arquivo configure.ac exemplo, chamado configure.scan (basta renomeá-lo depois para configure.ac, caso ele atenda às suas necessidades). E caso contrário, você já tenha criado seu texto plenamente funcional para o configure.ac, mas deseja verificá-lo quanto à correção, e caso você não tenha esquecido de verificar alguma dependência, a autoscan poderá gerar um relatório de advertências, que poderão servir como dicas para que você melhore o seu configure.ac:


configure.ac: warning: missing AC_CHECK_FUNCS([gethostbyname]) wanted by: src/gmyth_vlc.c:227
configure.ac: warning: missing AC_CHECK_HEADERS([arpa/inet.h]) wanted by: gmyth_file_transfer.c:50
configure.ac: warning: missing AC_CHECK_HEADERS([netdb.h]) wanted by: gmyth_file_transfer.c:53
configure.ac: warning: missing AC_CHECK_HEADERS([netinet/in.h]) wanted by: src/gmyth_socket.c:52
configure.ac: warning: missing AC_CHECK_HEADERS([sys/param.h]) wanted by: src/gmyth_socket.c:44
configure.ac: warning: missing AC_CHECK_HEADERS([sys/time.h]) wanted by: src/gmyth_util.c:40
configure.ac: warning: missing AC_FUNC_REALLOC wanted by: src/gmyth_http.c:965
configure.ac: warning: missing AC_PROG_RANLIB wanted by: ltmain.sh:6817
configure.ac: warning: missing AC_TYPE_SIZE_T wanted by: src/gmyth_http.c:960

No log da autoscan acima, ela aconselha que eu faça a verificação de dependências de biblioteca para a minha aplicação, usando a macro AC_CHECK_FUNCS, que é bastante útil, e realiza uma busca nas bibliotecas (.so, .a, shared ou static libraries, etc.) por um determinado nome de função. Caso o nome de função solicitado seja encontrado, a biblioteca que o encapsula será incluída como parâmetro para que o GCC ou outro compilador a inclua como parâmetro de biblioteca.

Mais detalhes sobre a geração dos builds propriamente ditos no próximo post...

GNU Autotools (parte II) - Utilitários

2007-08-14T19:27:00.000-03:00

Na continuação da apresentação dos conceitos básicos de funcionamento das Autotools, conjunto de ferramentas usadas para automatização de geração de builds de software, veremos os arquivos fundamentais presentes numa distribuição que se aproveita da infraestrutura makefile. Observando um projeto típico que usa das autoconfs, alguns arquivos são característicos, e muitos deles são de presença mandatória:


data/
debian/
m4/
samples/
src/
tests/
AUTHORS
COPYING
ChangeLog
INSTALL
Makefile.am
NEWS
README
aminclude.am
autogen.sh
configure.ac
doxygen.cfg
gmyth.pc.in

A estrutura de diretórios acima foi obtida de: http://gmyth.svn.sourceforge.net/viewvc/gmyth/trunk/gmyth/. Os arquivos com nomes em maiúsculas são documentos texto, caracteres no formato ASCII, e são descritivos do projeto, contém metadados com informações importantes, como o nome dos autores do projeto (AUTHORS) e a licença de cópia e distribuição do código (COPYING). Eles são obrigatórios, e em alguns passos de processamento, é possível que ferramentas como autoconf retornem com erro, caso não encontrem tais arquivos, apesar da aparente função de baixa prioridade que seria a de informação sobre releases de software e nomes de autores.

A seguir, por ordem de importância, temos o Makefile.am. Esse arquivo é uma espécie de Makefile, tal como visto no último post, porém em estágio de pré-processamento, ou seja, contém estruturas e macros que ainda devem ser processadas, e utiliza de variáveis definidas na sequência de montagem de build comandada pelo arquivo configure.ac (que por sua vez gera o configure). O trecho seguinte de Makefile.am apresenta algumas estruturas fundamentais:


SUBDIRS= src samples tests

(...)

if HAVE_INDENT
indent:
      cd src; \
      make indent; \
      cd ..
endif

include aminclude.am

EXTRA_DIST =                    \
      autogen.sh                      \
      gmyth.pc.in                     \
      AUTHORS                       \
      COPYING                        \
      README

Esse arquivo Makefile.am será utilizado como entrada no utilitário automake, as macros chamadas a partir dele serão processadas como devido, e o arquivo texto resultante será transformado no arquivo Makefile, com estruturas semelhantes àquelas vistas no post passado, porém bem mais detalhada e complexa, Por sinal, os resultados de processamento das autotools costumam ser de leitura BEM difícil para quem não estiver habituado a Makefiles e programação em Shell Script, mas depurar uma distribuição com autoconf algumas vezes necessita-se inspecionar arquivos Makefile e configure auto-gerados a fim de identificar inconsistência ou erros (como um path de biblioteca inválido, ou variável de ambiente mal definida).

Ao rodar em cima desse arquivo Makefile.am, o automake definirá, na ordem, uma variável SUBDIRS, que listará os subdiretórios do projeto que contém outras definições Makefile.am. A variável SUBDIRS é padrão, e deve sempre ser definida quando se lida com projetos mais complexos, com vários Makefiles, porque é através dele que será determinada a abrangência e a forma como o build vai ser gerado: um diretório faltando pode prejudicar a release final, bem como a inclusão de um módulo em SUBDIRS que não seja possível de ser compilado em determinada arquitetura, pode gerar problemas na execução em alguma etapa de processamento das autotools... Durante a execução, serão processados, respectivamente, arquivos Makefile.am nos subdiretórios src, samples e tests.

Pode-se, dentro de um Makefile.am, determinar a criação condicional de targets, ou adição de qualquer trecho de código, usando variáveis definidas numa etapa anterior do automake, como o uso de variáveis definidas no configure.ac (autoconf). Aqui temos que a variável HAVE_INDENT é verificada com relação ao seu valor verdade e, caso a avaliação seja positiva, o target indent é criado. Essa variável será definida TRUE caso a opção de identação de código tenha sido informada em linha de comando (durante a chamada inicial aos autotools), bem como se a ferramenta indent foi encontrada na distribuição alvo. Abaixo, vemos o trecho de código do configure.ac que cria a variável HAVE_INDENT com o valor apropriado:


# checks if the indent tool can be found
AC_CHECK_PROG(HAVE_INDENT, indent, [Found!])
if test -n "$HAVE_INDENT"; then
      AC_DEFINE(HAVE_INDENT, 1, [AutoIndent found!])
fi

AM_CONDITIONAL(HAVE_INDENT, test -n "$HAVE_INDENT")

A macro M4 "AC_CHECK_PROG" funciona da seguinte forma: a variável HAVE_INDENT será declarada caso o aplicativo indent possa ser executado com sucesso em prompt de comando, imprimindo uma mensagem "Found!" em caso afirmativo. A macro AM_CONDITIONAL faz com que a variável HAVE_INDENT seja visível em escopo de arquivos de entrada Automake (Makefile.am), o que a torna passível de ser usada em expressões condicionais, como o trecho de avaliação do if no Makefile.am.

Na sequência, e voltando ao arquivo Makefile.am, temos a definição da macro EXTRA_DIST, que irá informar ao utilitário automake quais os arquivos que devem ser disponibilizados quando da geração do build de distribuição (aquele que fará parte do pacote de distribuição ao usuário do sistema de software). No caso da biblioteca GMyth acima, os arquivos distribuídos são aqueles que incorporam meta-dados de informação ao pacote (AUTHORS, COPYING), além de scripts úteis à geração do build (autogen.sh) e um arquivo de configuração para resolução de dependências (gmyth.pc.in), que serve como arquivo de entrada para o utilitário pkg-config, que procura resolver as dependências de biblioteca no ambiente constante à distribuição. Detalharemos depois o uso dessas outras ferramentas.

No próximo post, detalharei mais a respeito do processamento do configure.ac através do autotools...

Iniciando com GNU Autotools

2007-08-09T20:28:00.000-03:00

Muita gente procura em sites para desenvolvedores informações sobre como usar as ferramentas da GNU para gerenciamento de compilação de código-fonte, library linking com os binários, geração de bibliotecas e distribuição de código executável. Essas ferramentas são amplamenta conhecidas como "autotools" (automake, autoconf, libtool, etc.), e são usadas com frequência em projetos de software livre. E encontrar tais informações de uso, de forma simples e resumida, é tarefa que demanda a busca em inúmeros sites, bem como experimentações em linha de comando. Pra piorar, o mecanismo de funcionamento das autotools não é simples. Portanto, qual a real necessidade delas? Definindo da forma mais simples possível, autotools são aplicativos e scripts de linha de comando que facilitam o trabalho do desenvolvedor de aplicativos e bibliotecas no trabalho de gerar e linkar um código binário, por dinamizar a forma como esse produto vai ser disponibilizado em produção. Tal recurso provê meios de, automaticamente, buscar pela versão de uma biblioteca necessária para um determinado módulo do aplicativo, por exemplo. Isso é particularmente importante quando o projeto de software é uma atividade desenvolvida através da participação de membros em ambientes heterogêneos de desenvolvimento, facilitando o trabalho do programador no momento em que ele se vê, por exemplo, com uma dependência recém adicionada de biblioteca.

Vou tentar mostrar aqui como iniciar o uso dos Makefiles. A princípio, não abordarei como se cria um Makefile, porque esse vem sendo continuamente um trabalho menos necessária, uma vez que ferramentas como o automake/autoconf já facilitam muita coisa, através de inúmeras macros de automação pré-definidas em M4, uma espécie de meta-linguagem funcional usada para adicionar recursos de configuração e busca aos Makefiles, tal como a macro M4 chamada AC_CHECK_LIB, que checa no sistema de execução por uma biblioteca especificada, necessária para a distribuição. Me limitarei aqui a detalhar como começar um projeto em autoconf, que abstrai muitas das demandas de projetos complexos em Makefile.

Um arquivo de configuração GNU Make (Makefile) simplesmente especifica regras (tasks, ou tarefas) de compilação e geração de código com bibliotecas. Por exemplo, no arquivo Makefile abaixo:


%.o: %.c
  $(CXX) -c $(CFLAGS) $(INCLUDES) $< -o $@  


OBJ_FILES = gmu_dragwin.o gmu_dragwin_module.o  

TARGET = gmu_dragwin.so  

build: $(OBJ_FILES)      

     $(CXX) $(LDFLAGS) $(INCLUDES) $(LIBSPATH) $(OBJ_FILES) $(LIBS) -o $(TARGET)  


all: build

Aí vemos alguns conceitos importantes na definição de Makefiles: o conceito fundamental é o de tasks (tarefas) de manutenção, que são especificadas no texto acima por identificadores alfanuméricos seguidos de dois pontos. Daí temos a definição de 2 tasks básicas: build e all. A task build é simplesmente a que define a geração do produto específico do Makefile, a meta básica decorrente da execução deste. Tanto que é ela que vai especificar como parâmetro último na geração a variável $(TARGET), que está definida mais acima como sendo o nome de arquivo de biblioteca, "gmu_dragwin.so", que é o nome do nosso componente. A task (ou target) "all" é simplesmente uma conveniência do Makefile para que, caso não seja especificada taks alguma em momento de execução do procedimento de make, a taks build será a chamada default. A linha seguinte ao símbolo ":" de definição do target é chamada de pré-requisito, porque a realização dessa task depende da execução sem erros de cada um dos pré-requisitos determinados. Portanto, digitar em linha de comando o comando make, no mesmo nível de diretório em que se encontra o arquivo Makefile acima, irá resultar na geração dos códigos objetos e o arquivo gmu_dragwin.so, que se refere à biblioteca:


# cd drawin_library
# ls
Makefile     gmu_dragwin.c    gmu_dragwin_module.c
# make
# ls
Makefile      gmu_dragwin.c    gmu_dragwin_module.c
gmu_dragwin.o    gmu_dragwin_module.o    gmu_dragwin.so

A chamada a make sem task nenhuma, faz com que a task all seja buscada como a padrão, que por sua vez em nosso Makefile redireciona a tarefa para a build. Na chamada a make, poderia-se ter especificado a task desejada diretamente, tal como em: make build. O resultado seria exatamente o mesmo.

A terceira task no Makefile exemplo do texto acima é mais aprimorada, e admite um critério dinâmico para a necessidade de recompilação dos códigos-objeto dos arquivos fontes em linguagem C. A task %.o diz que toda referência no texto a qualquer pré-requisito, em qualquer target, que tenha um nome definido por uma sequência qualquer de caracteres alfanuméricos, seguido por uma string ".o" (por sinal, uma extensão de arquivo objeto), fará com que seja automaticamente chamada essa task, que por sua vez verificará a efetividade de cada um dos pré-requisitos. O primeiro pré-requisito será encontrar um arquivo de código-fonte com o mesmo nome do target, mas com extensão ".c":


%.o: %.c
  $(CXX) -c $(CFLAGS) $(INCLUDES) $< -o $@

No pré-requisito seguinte, será chamado o compilador GCC (cujo caminho no sistema de arquivos é apontado pela variável $(CXX)) com os parâmetros detalhados no target acima como sendo $<, que se refere ao nome do arquivo-fonte (por exemplo, gmu_dragwin.c); e a variável $@ aponta para o valor corrente do nome do target (p.e., gmu_dragwin.o). Esses recursos de substituição são amplamente utilizados, uma vez que permitem que o Makefile defina dinamicamente suas próprias regras, e são chamados de "regras de substituição" (pattern rules).

Uma vez tendo fundamentado os conceitos básicos de Makefile, veremos na sequência os detalhes de como as ferramentas de autotools criam tudo isso de forma mais prática, permitindo a definição de regras mais avançadas de configuração.

Real Case Application of Coverage Tests on Linux - Part 3

2007-05-12T20:08:00.000-03:00

These special topics on coverage tests I made are based on real case situations of tests implementation, when I used to think about a nice way to certify that the user requirements needs related to a MythTV protocol API implementation I´m developing are well concerned. This API is not the official one, based on the MythTV server and client implementations, but another totally different effort based on GObject/GLib frameworks and object model.

The main test architecture I had developed is to allow that the test script's writer could develops the testing scripts with the minimum possible effort. So, I choose to use Python as the language of choice on the test scripts, because it's easier to learn, and removes the extra step of compiling code, because Python is interpreted. Each one of these Python scripts do, at least, one basic task: start a process with the testing program, compiled with the gcov program line arguments. A very simple strategy had been used to guarantee that the process testing stoped at a given known time, and the Python script could be signalized about the program termination.

You can see all these concepts, and see how to code gcov-based tests in practice, seeing my contribution on GMyth's SourceForge: http://sourceforge.net/projects/gmyth.

Have a lot of fun! :)

More on Coverage Tests on Linux - Generating Better Reports

2007-05-10T20:01:00.000-03:00

At the last post, I showed up some code that could be interesting for testing purposes, and to see how the gcov do these automatic testing procedures. In fact, gcov uses a number of techniques to cover a given test code. Internally, we can say that gcov will insert into your program object file, some kind of meta-code, which will try for a large number of meaningful execution paths. So, it uses some know strategies to select what are the most effective paths he must to cover, because is theoretically impossible just try to cover all the possible situations when a program is running.

There are 2 main types of coverage: branch coverage and loop coverage. Just to give you an idea, in the branch coverage, it is important to verify that every branch has been taken. When it uses the loop coverage, gcov try to take all the execution paths through a loop. To see more about gcov and some information about some internal working issues, refer to http://gcc.gnu.org/onlinedocs/gcc/Gcov.html.

Since our gcov execution at the last article produced some files that encapsulates all the information above, we'd got almost all we need. But could be better if we could put all the data collected from gcov in a more beautiful and useful way. That is what a tool called lcov do:

lcov -d . -c -o test_gcov.info

This simple command will search for the files generated by gcov (*.gcda, *.gcno) at the current (".") directory (-d option), and put this in the test_gcov.info. This file has the collected information about the program execution and automatic testing, but is not yet in a human-readable form. But we can put this file as an input to a very useful tool, genhtml:

genhtml test_gcov.info

After this program script finishes execution, type "ls" on your prompt and see what it had just created: a lot of images (.png), CSS (cascading style sheets) and HTML files. Open the "index.html" in your preferable browser, and it will show you how powerful this tool can really be, as a valuable way to certify that your test scripts are covering the software requirements initially specified, which test cases are important, and if you can find some dead code that you can throw off.

Coverage Tests on Linux

2007-05-04T11:00:00.000-03:00

Every time you want to add a new test case to your software implementation (i.e., a library, a framework, a network server), your client may want to know how these tests are being done, if the test specifications corresponds to the software requisites, and how much of these functionalities are being covered by the test cases. It may be difficult to say to anyone that is not a real hacker, or doesn't know so much about your implementation, that your tests are being effective. In order to allow that your test case script start reporting how much it has been covering from the target implentation, there is a tool that you can use: GCOV and LCOV, a great effort from the LTP group.

These coverage testing tools can be helpful to you that want a kind of automatic process to determine how much of the code is actually being covered by your tests, which is always an indirect measure, but it works. And its very important to know that coverage tests cannot find logical errors in a program! The code coverage analysis is very well discussed in the software testing and quality assurance fields of software development, and I will show now how you can start using them to help you on your tests.

At first, you should compile the programs you want to be covered with 2 special GCC parameters: -fprofile-arcs and -ftest-coverage. If you want to apply coverage testing to an API you are developing, certainly you should add these parameters to all source code being compiled (if you are using autoconf, add this to the CFLAGS variable, on configure.{ac,in}). This will cause the GCC compiler to add special symbols inside the generated object files.

Now let's compile some code, including in there the coverage information. Here is a code example that will certainly fall into some memory error and cause incomplete code execution:


#include <stdlib.h>
#include <stdio.h>

int
main( argc, argv )
     int argc;
     char **argv;
{
     int x;
     char **str = (char**)malloc(20 * sizeof(char*));
     for ( x = 0; x < 23; x++ )
     {
             str[x] = malloc( 3 * sizeof (char) );
             if ( NULL == str[x] )
                     exit(-1);
     }

     exit(0);
}

Now, compile the code above with the following line:

gcc -ftest-coverage -fprofile-arcs test_gcov.c -o test_gcov

This will generate not only the test_gcov executable object, but another important GCOV object structure, which you can see as test_gcov.gcno. This is only part of the things you need to do before running the tests using the types of coverage GCOV do to you. After this .gcno file is generated, you should execute the application:

./test_gcov

This will create another important file, test_gcov.gcda. With this test run description file, the "gcov" tool will inform you about how much percent you program could be covered by its automatic testing procedures. So you can run gcov passing the test_gcov source code to be analyzed:

gcov test_gcov.c

And you will see something like the following:

File 'test_gcov.c'
Lines executed:85.71% of 7
test_gcov.c:creating 'test_gcov.c.gcov'

Next, we will see how to make better reports over your coverage test scripts, presenting them in .HTML, and showing these percentages for each line of covered code.

Nokia launched the first UPnP enabled device

2005-12-01T11:01:00.000-03:00

Last 29 November (tuesday), Nokia announced the first mobile device that is able to aply UPnP for doing ubiquitous (seamless) home media networking. The Nokia N80 was released with 2 another new devices, the N71 and N92, in the beggining of november. Using N80, you will now do things like listen to music stored on your computer (or through a UPnP-enabled living room audio system), or send photos or slides from your N80 to be presented on your home TV-set. The device can send files to be wirelessly printed on a printing kiosk, or a UPnP compatible printer. Since it is using UPnP, discovering of these devices is almost automatic, users don't need to know too much about the network infrasctructure.
A 3-MegaPixel digital camera is another very good feature in this mobile device. And it has the same size of a credit card. But the features that are more impressive are the ones related with UPnP.

See below:
http://www.connecting.nokia.com/NOKIA/nns.nsf/a/66B83764C6903DE6C22570C0004928A3

Quine: Self-reproducing programs

2005-10-14T19:57:00.000-03:00

Last week, I saw something that is, at least, an excentricity. There is some of Logic and Computer Theory inside of such things, but not necessarily you must to read a lot of Mathematics theory books to understand it. And that is the funniest thing in see this examples!
Tell me, what the program below, written in C language, is wanting to do? It seems, at first, not so difficult...

char a[] = "int main(){ printf(b,34,a,34,10,34,b,34,10,10,a,10); }";
char b[] = "char a[] = %c%s%c;%cchar b[] = %c%s%c;%c%c%s%c";

int main(){ printf(b,34,a,34,10,34,b,34,10,10,a,10); }

We can see two variable declarations. Next thing we observe is that these variables are characters arrays. And the content of the first variable (named "a"), seems to follow a familiar syntax, which computer hackers frequently uses for writing computer programs. So, the application above is doing only one thing: it is writing itself! It is interesting to pay attention to how these great programmers deals with the high an lows of the languages... (such as, variable scope, the time between the instant the variables starts living, and the moment the variable would not be referenced anymore). Maybe another example, only to show how it works... (coded using the Python language)

a = ['print "a =", a', 'for s in a: print s']
print "a =", a
for s in a: print s

(Author: Omar Antolin - omar@galois.fciencias.unam.mx)

Or another great quine example in C language (it is not only a self-printing, it is a palindrome too!):

/**/char q='"',*a="*//**/char q='%c',*a=%c%s%c*/};)b(stup;]d[b=]d-852
[b)--d(elihw;)q,a,q,q,2+a,b(ftnirps{)(niam;031=d tni;]952[b,",b[259];
int d=130;main(){sprintf(b,a+2,q,q,a,q);while(d--)b[258-d]=b[d];puts(
b);}/*c%s%c%=a*,'c%'=q rahc/**//*"=a*,'"'=q rahc/**/

Author: Dan Hoey

Maybe you think that it is not a great problem. But, can you make a program that can write its own contents? We may consider a major difficulty: you will write a program, and you will try to not do it so difficulty, because you want to print all source code on the screen - as much code you write, much more work you will have to print the contents. Remembering that you must to write everything, including all commands and instruction used to print and to present results on the screen! :)
Self-reproducing programs are not a so recent idea, and a very famous phylosopher and logician, called Willard van Orman Quine (1908-2000). He made many contributions to the phylosophy of language and phylosophy of Logic. He made a lot of works, such an improved normalization methodology enabling better optimization of SQL queries, for example. And was he that give his name to the concept of a program that can reproduce itself, or its own source code...
You can see a lot of references (and source codes) in this site, illustrating "quine": http://www.nyx.net/~gthompso/quine.htm

O Governo querendo dar armas para os bandidos???

2005-10-05T19:24:00.000-03:00

Pois é, esse é mais um assunto que dá o que falar. E não é por menos...
Uma coisa estranha aconteceu a poucos meses, o Governo quer que nós votemos "sim" no plebiscito. Para quê será???
Pra começar, tal referendo nem deveria existir. Pessoalmente, sou contra essa política de querer colocar uma responsabilidade tão complexa nas mãos de pessoas como nós, que não somos especialistas em Segurança Pública. Mas, sim, é verdade, eu voto NÃO! Eu sou contra o desarmamento!!! Porquê?
Existem várias razões para isso: imagine o que pensará o bandido que costuma assaltar à mão armada, depois que souber que as casas já não podem guardar armas de fogo? O que antes era permitido (ter uma arma em casa), depois que essa campanha da Globo der certo (o que, infelizmente, está acontecendo... a Globo sempre teve uma grande influência com as massas...), se tornará algo proibido. Sim, você acha inseguro ter uma arma em casa, só que o bandido acha que é SEGURO pra ele você NÃO TER!!! Ou seja, se você não tiver uma arma em casa, por opção, ou porque você resolveu doá-la ao Governo (e lógico que o bandido vai conseguir se convencer disso com mais facilidade se esse referendo for votado com inúmeros SIM), o bandido vai se sentir mais seguro de entrar nela, roubar os seus pertences, talvez te agredir gravemente (na verdade, MUITO gravemente... ou você acha que os bandidos vão passar a andar desarmados depois dessa lei?). E os bandidos vão se sentir mais seguros porque SABE que você PODE (por ser um bom cidadão...) não guardar uma arma.
Eu acho que o governo resolveu tocar numa ferida que já demorava a cicatrizar, e que agora foi reaberta. Antes, nós simples cidadãos, poderíamos ter essa arma tão efetiva que é a dúvida: se o ladrão não sabe que você tem arma em casa, ele não vai dar tiro no escuro. Caso contrário, para eles às vezes é até vantajoso apostar nisso e ver no que dá... Talvez, para benefício da maleficência, ele leve embora o seu aparelho de DVD e a sua vida.
Estão tirando um benefício pacífico, que é nosso, de nos defender com uma arma incólume, que é a dúvida, plantada com cuidado nas cabeças dos marginais que ficam de plantão em frente de tua casa, e que agora vão olhar com mais cuidado a quantas andam esse processo do Governo de derrubada da Segurança Pública...
Sou contra as armas, mas talvez seja uma boa idéia comprar uma.
Seria uma idéia melhor ainda que TODOS pensassem em comprar armas agora, antes que não seja mais possível (quem sabe...). Talvez você nem queira comprar mesmo uma arma, mas seria bom que pensasse, digamos, 5 minutos em comprar uma.
Se todos pensassem nisso, a gente consiga plantar de novo na cabeça dos marginais que o nosso lar, o lugar onde você convive, com a sua família, seus pais, sua mulher e seus filhos, é sagrado e inviolável, e que, caso contrário, a vida do próprio bandido estará em risco.
Eu prefiro esse benefício da dúvida amargando bem ácida no estômago dos marginais. É por isso que eu sou contra o desarmamento, e a favor da vida e do respeito.
Uma bela e concisa matéria na Veja: http://veja.abril.com.br/051005/p_076.html
Não confiem no Governo, o Governo não confia em vocês. Quem proíbe a venda de armas e impede que pessoas de bem a possuam, é porque não confia na força e na inteligência da população. Cuidem disso antes que seja tarde.

Contando de 1 a 100 (ANSI C)

2005-09-23T11:52:00.000-03:00

É o quê, hômi?
Contando de 1 a 100, sem uso de condicionais (if-then), nem loops. Lembrem que os operadores lógicos também não são permitidos (&&, ||, etc...). Mas, porque não pode usar os operadores lógicos?
Porque dizer "sem instruções condicionais", significa "sem operadores condicionais" em C. Isso se justifica pelo fato que todas as expressões em C (e C++) são sentenças (statements), uma vez que você sempre pode ignorar o resultado de uma expressão. E todos os operadores (incluindo os binários - &&, ||, ~, etc. - e unários) são também expressões, logo (juntando 1 com 2 na breve demonstração acima) todos os operadores são também sentenças.

(código obtido de Sitikant Sahu/Índia)


#include <stdio.h>
void func2(int lower,int upper);
void func(int lower,int upper)
{
printf("%d\n",upper);
func2(lower,--upper);
}
void func3(int lower,int upper)
{
exit(-1);
}
void func2(int lower,int upper)
{
void (*a)(int,int);
a = ((int)(&func) * !(!(upper-lower))) + ((int)(&func3) * (!(upper-lower))) ;
a(lower,upper);
}
main()
{
int lower,upper;
scanf("%d",&lower);
scanf("%d",&upper);

func2(lower-1,upper);
}

UPnP CyberLink

2005-09-22T13:38:00.000-03:00

Last month (august, 1st), an UPnP library I suggested to the OSSO Connectivity group personnel, was delivered on SourceForge. The new was sent on the Satoshi's Blog: http://www.cybergarage.org/blog/archive/2005_08_01_skonnoblog.html
Satoshi Konno is an engineer from Japan, and the main developer of CyberLink for C library. He made 2 (two) more versions of CyberLink before: one for C++ programmers, and another for Java developers. I made some contributions for this and the old (C++) release...
This is a very good new; OSSO is wanting for something non-C++ related for his UPnP applications, and the very stable version of CyberLink was, until then, the C++ release. This one is a very complete implementation, with a lot of features, like most of AV (audio-visual) aspects of UPnP. The C version of CyberLink only needs this missing AV features, but is very stable and well optimized, and was ready for working in embedded devices, like the japanese device T-Engine (in japanese; only Sobral would be able to read this page, I guess!) :)
This, definitely, is not the first effort to construct a stable UPnP implementation: several developers around the world invest his own time to create UPnP APIs, and some enterprises, like Intel made one implementation too. I had opportunity to use some of them... But I think CyberLink is the most well-designed and "developer friendly" UPnP library. And it is free (it has a BSD license).

Primeiro Post do Garoto Hipotenusa

2005-09-21T18:59:00.000-03:00

Depois de muito insistir em não criar esse blog, e após tanta pressão, criei agora um blog público, junto com a galera do Instituto.
Devo dizer que não é meu primeiro blog. Tenho outros blogs, alguns fictícios (para extravasar minha parte criativa!), outros diários pessoais, ou de grupos do qual participo (ou participei). Apesar da grande insistência: não, não vou dizer quais os nomes desse blogs! ;) Apenas espero que vocês continuem dando uma olhada por aqui, e que encontrem sempre coisas curiosas e interessantes...
Não vou escrever muita coisa aqui, quem quiser, pode dar uma olhada no meu perfil no Orkut: http://www.orkut.com/Home.aspx?xid=1511306046830256280
Voltar agora pra essa loucura de bateria de testes que não acaba nunca...

typedef void (*Garoto_Hipotenusa)(void *)

Lucene Search

Google Treasure Hunt 3: Busca em Profundidade (Depth-First Search)

Google Treasure Hunt 2 - MapReduce?

Doctor Dobb's Code Talk

Google Treasure Hunt 4

CCNA / WANs

Access Control Lists - ACLs

RIP Troubleshooting

Sub-redes e Roteadores

Segmentação em Sub-redes

STP - Spanning Tree Path Cost

OSPF - Open Shortest Path First

WAN com Frame-Relays no CCNA

CCNA - Cisco Certified Network Associate

Mais sobre GNU Autotools (parte IV)

GNU Autotools (parte III) - Configure.ac

GNU Autotools (parte II) - Utilitários

Iniciando com GNU Autotools

Real Case Application of Coverage Tests on Linux - Part 3

More on Coverage Tests on Linux - Generating Better Reports

Coverage Tests on Linux

Nokia launched the first UPnP enabled device

Quine: Self-reproducing programs

O Governo querendo dar armas para os bandidos???

Contando de 1 a 100 (ANSI C)

UPnP CyberLink

Primeiro Post do Garoto Hipotenusa

typedef void (Garoto_Hipotenusa)(void )