Archive for the ‘mesh network’ Category

Conectividade de redes mesh

26 de março de 2010

Ricardo Andrade Dalla Bernardina

Redes mesh podem ser estudadas pela teoria dos grafos [1]. Para seu correto funcionamento é necessário que qualquer AP (Acess Point) tenha comunicação com qualquer outro. Por isso, é natural a relação entre a conectividade entre um AP e todos os outros de uma rede mesh, e o fato do grafo associado a eles ser conexo ou não [2]. Com esta finalidade criou-se o programa connect.g [3] para avaliar se o grafo de uma rede mesh é conexo, utilizando a linguagem gvpr [4]. o programa é mostrado a seguir:

BEGIN {
     graph_t comp;
}
N {
     comp = compOf ($G, $);
     printf ("%s\n", $G.name);
     if (comp.n_nodes < $G.n_nodes) {
          printf("'%s' is not a connected graph.\n", $G.name);
     }
     else{
          printf("'%s' is a connected graph.\n", $G.name);
     }
     exit(0);
}

No passo BEGIN é declarado o grafo comp. Este grafo é usado no passo N para receber o valor da chamada de compOf() do grafo de que se deseja verificar a conectividade. A função compOf() verifica, dado um grafo g e um nó n deste grafo, quais nós de g estão conectados com o nó n. A resposta de uma chamada a compOf() é um subgrafo com os nós que estão ligados a n, sem as arestas em g.

No programa é feita a chamada compOf ($G, $), onde $G significa o grafo sendo atualmente processado, e $ o nó atual no passo N. Como, em um grafo conexo, qualquer nó deve estar ligado com todos os outros nós, o número de nós do resultado do compOf() deve ser igual ao número de nós do grafo original. Por isso, a comparação

if (comp.n_nodes < $G.n_nodes)

Nela é avaliado se o número de nós do resultado de compOf() é menor que o número de nós do grafo original. Se a resposta for positiva, o grafo não é conexo. Então, é exibida na tela a mensagem de não conexão do grafo. Caso a resposta seja negativa, o número de nós do resultado do compOf() é igual ao número de nós do grafo original, pois não há possibilidade de haver maior número de nós no grafo do compOf() em comparação com o grafo original. Desse modo, a tela exibirá mensagem informando que o grafo é conexo.

É feita logo a seguir uma chamada exit(0), para que o programa não exiba a mesma resposta até serem analisados todos os nós — pois se o grafo não for conexo, a chamada a compOf() para qualquer um dos nós gerará um componente conexo com menos vértices do que o grafo original.

Assim, basta testar um único nó — portanto, este é um método bastante eficiente.

Referências

[1] Redes mesh e grafos
https://tecnologiassemfio.wordpress.com/2010/01/22/redes-mesh-e-grafos/
Acessado em 25/03/2010

[2] Teoria dos grafos
https://secure.wikimedia.org/wikipedia/pt/wiki/Teoria_dos_grafos
Acessado em 25/03/2010

[3] connect.g
http://sites.google.com/site/hgfernan/arquivos/connect.g?attredirects=0
Acessado em 25/03/2010

[4] Apresentação do gvpr
https://tecnologiassemfio.wordpress.com/2010/02/05/apresentacao-do-gvpr/
Acessado em 25/03/2010

Licença Creative Commons
Esta obra foi licenciada com uma Licença Creative Commons – Atribuição – Partilha nos Mesmos Termos 3.0 Não Adaptada.

Yet Another Asterisk Tutorial

19 de março de 2010

Daniel Caraça

Atualmente, a telefonia é um meio de comunicação indispensável. Apesar de existirem muitos outros meios de comunicação, é ainda vencedora a simplicidade e eficácia da telefonia na transmissão de informações. Infelizmente, seu custo pode ser alto, principalmente levando em consideração ligações de longa distância. Uma solução que tem sido a cada dia mais usada é a de unir a telefonia com a internet, criando o VoIP [1], ou “Voz por IP”, que pode fazer ligações de longa distância a preços de ligações locais. Utilizando Softwares Livres [2], a implementação do VoIP se torna muito barata e ainda conta com a vantagem de fácil instalação e manutenção.

Uma conexão de baixa qualidade com a Internet pode trazer problemas para uma ligação VoIP. Quando se faz uma ligação normal, tem-se a sensação de estar falando com uma pessoa logo ao lado, pois a transmissão da voz é instantânea. Mas quando por algum motivo ocorre algum atraso, o usuário sente um certo desconforto e fica falando “Alô, alô?” até que a outra pessoa responda, ou seja, até que o sinal da resposta chegue. Assim para se ter uma comunicação eficaz por VoIP, deve-se dar muita importância a parâmetros como latência (ou a demora em responder) [3] e jitter (ou a irregularidade desse tempo) [4], importantes para se garantir a qualidade de serviço da ligação [5].

Em cidades digitais implementadas com redes mesh [6] há a possibilidade dos dados passarem por mais de um nó antes de chegar ao destino final — cada nó intermediário é chamado de hop. Se o número de hops for muito grande, isto aumentará a latência da comunicação.

A latência da comunicação faz uma comunicação VoIP ser um ótimo teste para uma rede. Pois apesar de números obtidos por benchmarks [7] darem bastante informação, nada melhor do que sentir “na pele”, intuitivamente, a qualidade da rede.

Este tutorial, aparentemente, mais um de tantos outros, tem como objetivo mostrar como pode ser simples fazer uma conexão VoIP entre dois computadores, o que é base até mesmo de sistemas VoIP de grande tamanho, conectando muitos computadores. A abordagem aqui têm ênfase na simplicidade, e apenas o mínimo necessário será explicado. Uma outra diferença importante deste texto é que aqui se ensina como a associar nomes aos ramais, o que não é o tipo de coisa mostrada em qualquer tutorial.

São usados 3 computadores, sendo 1 deles o servidor e os outros 2 os clientes. Nos clientes será usado um softphone; ou seja: um software que simula um telefone. Neste tutorial está sendo usado o Ekiga [8], que já vem instalado no Ubuntu [9], hoje a distribuição Linux mais popular [10]. Contudo, em qualquer outra distribuição o Ekiga funcionará da mesma forma. No servidor será usado o asterisk [11], um servidor VoIP que é Software Livre [2]. Para instalá-lo nas distribuições Debian [12], Ubuntu [9] e outras que possuam apt-get [13], basta digitar o seguinte comando:

# apt-get install asterisk

Caso a distribuição em uso não possua o comando apt-get, há vários tutoriais na internet sobre como instalar o asterisk em outras distribuições através dos comandos correspondentes a elas, como por exemplo, o comando yum [14] do Fedora [15] e o yaST [16] do openSUSE [17]

O asterisk funciona da seguinte forma: quando um usuário se loga no servidor com um programa cliente, o asterisk cria uma rota para se comunicar com o computador dele. Isso significa que o asterisk saberá para onde deve redirecionar a ligação caso alguém ligue para o ramal do usuário. Isso quer dizer também que, caso o usuário não se logue, o asterisk não saberá como chegar a seu computador. As configurações dele são feitas através de arquivos de configuração, onde se adicionam ramais, estabelecem-se as ações para as chamadas etc. Dois arquivos muito usados são o sip.conf e o extensions.conf, os quais serão modificados a seguir:

sip.conf:
– Nesse arquivo estão informações sobre os ramais que utilizarão o protocolo SIP [18] para se comunicar.

1) Há uma linha no arquivo que inicia-se com:

bindaddr=0.0.0.0

Caso se use 0.0.0.0, o asterisk escutará em todas as interfaces, mas parece aconselhável colocar apenas o IP da interface principal do servidor, pois assim não serão bloqueadas portas para VoIP de outras interfaces, como pode ver visto na descrição da chamada de sistema bind [19]

2) As linhas seguintes devem ser adicionadas ao final do arquivo:

[2000]
type=friend
secret=1234
host=dynamic        
context=teste

[2001]
type=friend
secret=4321
host=dynamic
context=teste

3)Explicando:
[] o nome entre as chaves será seu login e o seu ramal para o protocolo SIP

type é o tipo de usuário. Existem 3 tipos: friend, peer e user. Respectivamente eles podem receber e fazer ligações, apenas receber ligações e apenas fazer ligações

secret é a senha se logar no servidor

host é o IP do computador do cliente, ou dynamic caso o IP seja dinâmico

context é o contexto, ou grupo, que o usuário estará no arquivo extensions.conf. Caso ele pertença a um contexto, não poderá ligar para outro ramal pertencente a outro contexto, pelo menos sem redirecionamento de chamada.

Isto cria dois usuários SIP com o mínimo de informações possível.

extensions.conf
— Aqui estarão descritas as ações para os números discados

1) As seguintes linhas devem ser adicionada ao final do arquivo:

[ntsf]
exten => 2000,1,Dial(SIP/2000,20)      
exten => 2000,2,Hangup
exten => joao,1,Dial(SIP/2000,20)
exten => joao,2,Hangup

exten => 2001,1,Dial(SIP/2001,20)
exten => 2001,2,Hangup
exten => maria,1,Dial(SIP/2001,20)
exten => maria,2,Hangup

2) Explicando:
[] o nome entre as chaves será o nome do contexto, ou grupo, que pertencem essas extensões.

exten => 2000,x,..... significa que quando ligarem para o ramal 2000, serão executados os comandos iniciados por 2000, começando pela prioridade 1, depois 2 e assim por diante…

....,Dial(SIP/2000,20) significa que o asterisk irá chamar durante 20 segundos o computador que se logou como 2000 (ramal definido no arquivo sip.conf).

Hangup significa que irá finalizar a ligação, caso não completada.

– os nomes joao e maria não foram definidos em nenhum outro lugar, mas podemos utilizá-los. Esse é o interessante do arquivo extensions: ele diz ao asterisk o que fazer quando alguém liga para algum ramal. Assim ligar para um numero não significa que só se poderá falar com uma pessoa que usa ramal, pois é possível criar ramais de redirecionamento, ramais de secretária eletrônica, ramais de atendimento etc. Fazendo dois ramais diferentes executarem a mesma ação, é um método fácil de dar aos usuários a escolha entre utilizar números ou nomes.

Com isso já se tem o suficiente para fazer uma ligação utilizando o asterisk. A última coisa que é necessário fazer é carregar esses arquivos no asterisk. Para isso, basta digitar:

# asterisk -r

Assim a CLI [20] do asterisk será aberta. Deve-se agora digitar os dois comandos seguintes:

# sip reload
# dialplan reload

Assim os arquivos sip.conf e extensions.conf serão carregados e o asterisk está pronto para gerenciar as ligações.

Nos clientes, abre-se o Ekiga, clica-se na aba Edit e depois em Accounts. Na tela aberta, clica-se em Accounts e depois em Add a Sip account. Na outra tela que se abrirá, informa-se no registrar o IP da maquina onde esta o asterisk, no user e authentication user coloque o ramal, como por exemplo 2000, e como password a respectiva senha. Como name, coloque qualquer um, pois é um parâmetro apenass para o Ekiga, e no timeout algum valor de tempo em segundos, como por exemplo 60. Agora pressione Ok e pressione close na outra tela. Faça isso para o outro computador e com isso as configurações estão terminadas.

Para fazer a ligação digite, em algum dos clientes, ramal@ip.do.servidor no local onde está sip:. Pressione a tecla Enter ou clique no botão verde e a ligação será feita.

Essas configurações apenas possibilitam fazer ligações entre 2 computadores, mas o asterisk tem um potencial muito maior, permitindo secretária eletrônica, sons, espera, salas de conferências etc. Caso haja interesse por por mais informação, há muitos tutoriais na internet que se aprofundam mais, como o VoIP Wiki [21]

Referências

[1] VoIP
https://secure.wikimedia.org/wikipedia/pt/wiki/VoIP
Visitado em 23/03/2010

[2] Software Livre
https://secure.wikimedia.org/wikipedia/pt/wiki/Software_livre
Visitado em 23/03/2010

[3] Latência
https://secure.wikimedia.org/wikipedia/en/wiki/Latency_(engineering)
Visitado em 23/03/2010

[4] Jitter
https://secure.wikimedia.org/wikipedia/pt/wiki/Jitter
Visitado em 23/03/2010

[5] O que é Traffic shaping, afinal?
https://tecnologiassemfio.wordpress.com/2010/02/26/o-que-e-traffic-shaping-afinal/
Visitado em 23/03/2010

[6] Redes mesh e grafos
https://tecnologiassemfio.wordpress.com/2010/01/22/redes-mesh-e-grafos/
Visitado em 23/03/2010

[7] Benchmark
https://tecnologiassemfio.wordpress.com/2010/01/29/benchmark-distribuidos-para-redes-mesh/
Visitado em 23/03/2010

[8] Ekiga
https://secure.wikimedia.org/wikipedia/pt/wiki/Ekiga
Visitado em 23/03/2010

[9] Ubuntu
https://secure.wikimedia.org/wikipedia/pt/wiki/Ubuntu
Visitado em 23/03/2010

[10] DistroWatch.com
http://distrowatch.com/index.php
Visitado em 23/03/2010

[11] asterisk
https://secure.wikimedia.org/wikipedia/pt/wiki/Asterisk
Visitado em 23/03/2010

[12] Debian
https://secure.wikimedia.org/wikipedia/pt/wiki/Debian
Visitado em 23/03/2010

[13] Advanced Packaging Tool
https://secure.wikimedia.org/wikipedia/pt/wiki/Advanced_Packaging_Tool
Visitado em 23/03/2010

[14] Yum
http://fedoraproject.org/wiki/Tools/yum
Visitado em 23/03/2010

[15] Fedora
http://en.wikipedia.org/wiki/Fedora_(operating_system)
Visitado em 23/03/2010

[16] YaST
http://en.opensuse.org/YaST
Visitado em 23/03/2010

[17] openSUSE
http://en.wikipedia.org/wiki/OpenSUSE
Visitado em 23/03/2010

[18] Session Initiation Protocol
http://en.wikipedia.org/wiki/Session_Initiation_Protocol
Visitado em 23/03/2010

[19] Bind
http://publib.boulder.ibm.com/infocenter/tpfhelp/current/index.jsp?topic=/com.ibm.ztpf-ztpfdf.doc_put.cur/gtpc2/cpp_bind.html
Visitado em 23/03/2010

[20] Command Line Interface
http://en.wikipedia.org/wiki/Command-line_interface
Visitado em 23/03/2010

[21] VoIP Wiki
http://www.voip-info.org/wiki/view/Asterisk
Visitado em 23/03/2010

O que é Traffic shaping, afinal?

26 de fevereiro de 2010

Rodrigo Filipe Silva Carramate


Traffic shaping [1], ao contrário do que muitos pensam, não é apenas uma forma de os provedores comerciais limitarem taxas de transferência dos chamados heavy users, que transferem muita informação pela Internet. É bem verdade que há inúmeros relatos de usuários que dizem ter sido afetados pelo traffic shaping, sobretudo daqueles adeptos do peer-to-peer (como eMule e BitTorrent) [2], mas esta prática questionável por parte dos provedores está longe de ser a única utilidade do shaping, que, quando bem utilizado, pode tornar as redes muito mais produtivas.

Do inglês shaping (em português, formatar ou modelar), o nome já elucida bastante a finalidade do procedimento, que nada mais é do que modelar a banda da rede, ou ainda atribuir um perfil de controle de banda à rede.

O leitor pode, então, se perguntar porque deveria querer introduzir limites em sua rede, quando, na verdade, quer maximizar sua capacidade. Para responder a esta pergunta devemos nos lembrar que os diferentes tipos de tráfego na rede também têm diferentes prioridades: ninguém ficaria incomodado de enviar um e-mail e este chegar um ou dois segundos mais tarde ao seu destinatário. Por outro lado, se esta pessoa estiver em uma videoconferência com o seu chefe em Miami e tiver que esperar os mesmos dois segundos entre cada palavra que ele diz, a situação tende a ficar bastante desagradável. Os dois casos citados explicam um dos benefícios do uso do traffic shaping: a priorização de tráfego, que tem por objetivo atrasar a transmissão de pacotes menos urgentes a fim de entregar mais rapidamente outros mais prioritários, esta característica do traffic shaping constitui um dos mecanismos de QoS [3], ou a tentativa de garantir diferentes níveis de serviço da rede para diferentes aplicações dela.

Uma outra vantagem do uso do traffic shaping é a quantização de banda por tipo de tráfego. Para explicar a necessidade desta utilização vamos supor que esteja em seu escritório, a poucas horas da entrega daquele relatório essencial para a conclusão do projeto, quando misteriosamente a rede, tão necessária para o término do relatório, demora minutos para carregar uma simples página da Internet. Por outro lado, no computador ao lado seu colega faz download de músicas através de torrents a alta taxa de transferência. Há grandes chances de as conexões criadas pelo seu colega estarem utilizando toda a banda disponível para a Internet na rede do escritório. Obviamente nesta situação exagerada, poderíamos simplesmente bloquear a utilização de torrents na empresa, mas suponhamos que, por alguma razão, seu uso seja necessário.

Desta forma seria necessário limitar a taxa de transferência concedida a esse tipo de tráfego, o que se trata de uma outra utilidade do traffic shaping. Com as taxas para o download e upload de torrents limitadas, a navegação na Web certamente ficaria mais rápida.

Outra face do traffic shaping é o agendamento de perfis, no qual o gerente da rede, por meio de ferramentas adequadas ao seu sistema operacional, implementa o disparo automático de configurações pré-programadas, desta forma podendo adequar as quantidades de banda às necessidades específicas dos vários horários.

No caso de cidades digitais [4] temos uma grande variedade de usos, devido à complexidade das redes. Podemos, por exemplo, imaginar uma cidade em que tenha sido projetada uma rede para atender tanto a repartições da prefeitura quanto à população em geral. Uma regra de traffic shaping apropriada a essa estrutura seria reservar uma quantidade razoável de banda às repartições durante os seus respectivos horários de funcionamento. Esta medida preveniria o uso de todos os recursos pela população, evitando limitações na conectividade da prefeitura. Do mesmo modo, após o horário de funcionamento poderia se estabelecer uma regra onde essa banda fosse novamente disponibilizada à população, promovendo melhora na conexão a ela oferecida.

Podemos, então, entender o traffic shaping como um conjunto de regras planejado a fim de otimizar a rede e moldá-la a necessidades específicas. Infelizmente há quem o utilize para lesar consumidores. Por exemplo, proibindo tráfegos como Peer-to-Peer, ou a telefonia pela Internet, chamada VoIP [5].

Referências


[1] Traffic shaping
Visitado em 26/02/2010

[2] Quality of Service
Visitado em 26/02/2010

[3] Peer_to_peer
Visitado em 26/02/2010


[4] O que é Cidade Digital?
Visitado em 26/02/2010


[5] VoIP

Visitado em 26/02/2010

Saiba Mais

Controle de tráfego

QoS

Licença Creative Commons
Esta obra foi licenciada com uma Licença Creative Commons – Atribuição – Partilha nos Mesmos Termos 3.0 Não Adaptada.

Trânsito e redes mesh

12 de fevereiro de 2010

Fábio Damião Barbosa Ricci

Em São Paulo, uma pesquisa do Instituto Datafolha [1] revelou que o paulistano perde, em média, 109 minutos por dia no trânsito. Ao todo, 23% dos paulistanos perdem mais de duas horas por dia no trânsito.

Muitos fatores podem contribuir para os congestionamentos, que ocorrem principalmente quando o número de automóveis ultrapassa a capacidade de uma via. O principal fator de  origem deste problema é o tempo ocioso que um veículo permanece nas ruas, quando encontra um semáforo sinalizando parada enquanto não há veículos trafegando na via em que se deseja atravessar. Através do controle adaptativo de tempo de sinalização semafórica, é possível otimizar o fluxo de trânsito sem a necessidade de acompanhamento do ritmo de mudanças de condições de tráfego nas vias, promovendo um menor acúmulo de carros com a evolução do tempo.

O projeto SAWIM, desenvolvido pelo autor durante trabalho de conclusão de curso [2] é uma tentativa de resolver esses problemas através de comunicação através por redes sem fio em malha [3], ou Wi-Mesh.

Semáforos têm vantagens enormes como torres para comunicação sem fio: são da prefeitura, o que minimiza custos de aluguel e têm acesso livre uns aos outros. Afinal, os motoristas têm que poder ver os semáforos que, por isso são altos e têm visão desimpedida por obstáculos ao longo das pistas.

Por esta razão, semáforos tem sido usados em cidades digitais como torres para instalação de APs [4] para a rede mesh.

Em poucas palavras, o hardware desenvolvido para o projeto para controlar um semáforo pode ser descrito como:

  • um AP que vai fazer comunicação com outros APs da rede mesh, além de conter software específico para sincronização de APs. O software original do AP (seu firmware) é trocado por um Software Livre que o controla, chamado Freifunk [5]. Sobre este sistema, uma variação do GNU/Linux é que são desenvolvidos softwares específicos para controle de APs;
  • um módulo para controlar o semáforo, ligado ao AP através de de TCP/IP, o que lhe permite passar ao semáforo comandos do AP. Também é capaz de interagir com o sensor de presença e repassar informações dele ao AP;
  • um módulo adicional de presença, que comunica ao módulo de controle o número de carros passando — normalmente implementado através de sensores no solo. É possível que nem todos módulos do SAWIM possam contar com esse recurso. Neste caso, os módulos do sistema que contam com esse recurso o repassam aos outros.

Tanto AP quanto o módulo de controle estão protegidos das intempéries por uma caixa hermética.

Um ponto importante no projeto é que a tolerância a falhas das redes mesh [3] favorece o projeto, uma vez que semáforos são aplicação de missão crítica.

Uma visita à Transpoquip [6] feira específica sobre trânsito, mostrou que os fabricantes se interessariam muito por uma solução similar àquela do SAWIM. Apesar de questionamentos sobre a maturidade do software para controle dos semáforos — o SAWIM estaria sendo comparado com sistemas com dezenas de anos de desenvolvimento –, os técnicos das empresas se mostraram interessados na tolerância à falhas da rede mesh.

Uma das razões para isso foi observada recentemente: devido às chuvas, os semáforos da região de Pinheiros deixaram de funcionar. Aparentemente, a água entrou nos fios de comunicação e controle de semáforos.

Edição: Hilton Garcia Fernandes, a partir de texto em [2]

Referências

[1] Paulistanos apóiam transporte público, segundo o Datafolha
Visitado em 12/02/2010

[2] Fabio Damião Barbosa Ricci, Sistema integrado WiMesh para controle, automação semafórica e comunicação com Internet (Sigla: SAWIM) Trabalho de conclusão de curso apresentado na Escola Politécnica da Universidade São Paulo, em 9 de Outubro de 2009. São Paulo, SP, Brasil

[3] Redes mesh e grafos
Visitado em 12/02/2010

[4] Municipal Wireless Broadband and the Digital Community Report — City of Boulder, Colorado October 12, 2006
Visitado em 12/02/2010

[5] Freifunk
Visitado em 12/02/2010

[6] TranspoQuip Latin America 2009
Visitado em 12/02/2010

Licença Creative Commons
Esta obra foi licenciada com uma Licença Creative Commons – Atribuição – Uso Não-Comercial – Obras Derivadas Proibidas 3.0 Não Adaptada

Benchmarks distribuídos para redes mesh

29 de janeiro de 2010

Daniel Caraça

Em aplicações de redes mesh [1] com muitos usuários, quando um AP [2] possui tráfego muito grande é interessante criar uma rota alternativa ou aumentar a capacidade do mesmo para o melhor aproveitamento da rede pelos usuários. Saber a quantidade de dados e sua rota em uma rede mesh possibilita ao projetista descobrir onde estão seus gargalos e eventualmente diminui-los. Para obtermos esta informação, podemos utilizar o Benchmark [3] distribuído, um método eficaz de obter a banda real, latência e outras informações de uma rede em várias condições de operação.

Na criação de Cidades Digitais [4] é interessante a utilização de redes mesh pelo menor custo de sua implantação. Se compararmos com redes Wi-Fi convencionais [5], seria possível economizar devido a não necessidade de todos os pontos terem acesso à Internet por cabo, ou seja, não é necessário levar cabos para cada AP. Mas por outro lado, como a internet cabeada não está em todos os pontos, é necessário passar por mais de um AP até chegar a internet. Isso pode criar um fluxo muito grande em um dado AP, caso este esteja em um ponto intermediário a vários caminhos para a Internet. Por isso é muito importante fazer uma análise para prever o que poderá acontecer em situações críticas.

Benckmark distribuído seria a utilização de um benchmark sendo executado em vários computadores para obter dados do funcionamento da rede, mas não apenas de um computador para outro, mas sim de vários para um ou de vários para vários, simulando assim o fluxo de dados em uma rede com muitos usuários. Como resultado deste método, obtemos, por exemplo, a taxa de tranferência de uma certa operação em uma dada máquina. Esse valor pode nos mostrar a relação entre a banda teórica e a banda real, o que nos leva ao quanto que a rede está saturada. Se compararmos os valores encontrados para vários computadores clientes, poderemos ver quais clientes estão tendo uma banda menor e assim encontrar quais pontos da rede estão com tráfego muito grande.

Os programas que fazem benchmark possuem opções para definir vários parâmetros, possibilitando criar vários cenários. Pode-se definir por quanto tempo será feita a transferência de dados, a quantidade deles que será transferida, o número de clientes, se será TCP [6] ou UDP [7], se será utilizado delays, tamanho da buffer, etc. Assim pode-se ter elementos para uma análise bastante esclarecedora sobre a situação da rede monitorada, o que possibilitará melhorá-la em muito.

Referências

[1] Redes mesh e grafos
Acessado em 28/01/2010

[2] Wireless access point
Acessado em 28/01/2010

[3] – Benchmark (computing)
Acessado em 07/01/2010

[4] – Guia das Cidades Digitais
Acessado em 15/01/2010

[5] Wi-Fi
Acessado em 28/01/2010

[6] Transmission Control Protocol
Acessado em 28/01/2010

[7] User Datagram Protocol
Acessado em 28/01/2010

Redes mesh e grafos

22 de janeiro de 2010

Hilton Garcia Fernandes

As redes sem fio do tipo mesh (a expressão em português “redes sem fio em malha” não tem sido usada no Brasil) [1] conectam entre si pontos de acesso (AP) [2] diretamente por rádio, evitando assim a necessidade de conexões cabeadas e ampliando a cobertura da rede sem fio para não apenas um AP, mas vários.

O conceito é muito amplo, mas normalmente é aplicado apenas a redes sem fio locais, as chamadas WLAN, principalmente do tipo Wi-Fi [3].

Os computadores clientes de um AP sem conexão direta à Internet podem obter essa conexão através de um outro AP que a possua, pelo processo chamado de hopping, ou pulo: o AP sem conexão com a Internet repassa os pacotes de informação para aquele que a possui. Depois, o AP conectado repassa os pacotes da resposta da Internet para aquele AP que sem conexão direta, que por sua vez, repassa ao cliente que solicitou a conexão.

As redes sem fio em malha podem ser estudadas de várias formas. Uma das mais interessantes, com certeza é a via dos grafos [4].

A teoria dos grafos é baseada em conceitos simples e poderosos. Um grafo pode ser simplesmente descrito como um conjunto de objetos que se conecta em pares. Os objetos são chamados vértices (ou nós) e as conexões entre eles são chamadas arestas.

Em termos das redes mesh, cada AP seria um nó e cada conexão entre eles seria uma aresta. Grafos que modelam redes mesh podem ser considerados não dirigidos, pois se há conexão de um primeiro AP para um segundo, com certeza há do segundo para o primeiro.

Grafos podem ser conexos, quando de um nó é possível chegar a qualquer outro, mesmo que seja necessário passar por mais de uma aresta. Grafos com o mínimo de arestas necessário para serem conexos são chamados árvores [5]. Em termos matemáticos, se n é o número de nós de uma árvore, o número de arestas dela será n – 1.

Ora, redes mesh têm como propriedade interessante a tolerância a falhas. Em outras palavras, isto significa que há vários caminhos entre um AP e outro. Por exemplo, entre um AP sem conexão com a Internet e outro conectado. Se um dos caminhos não for mais possível, haverá outra alternativa, eventualmente menos rápida, mas ainda assim capaz de permitir o acesso à Internet.

Por isso, uma rede mesh tem que ter mais do que o mínimo de conexões possível, para que haja redundância em pelo menos uma conexão. Ou seja: nestes termos, a rede mesh do grafo mencionado teria que ter pelo menos n arestas. Uma rede totalmente conectada [6] é uma rede com
n*(n – 1)/2
conexões, o que não é viável para redes maiores.

Outro ponto que favorece a qualidade de uma rede mesh é que a quantidade de conexões seja o melhor distribuída possível, sem que um único nó contenha todas conexões redundantes — pois este nó será um ponto de falha da rede; se ele cair, cairá parte importante da rede. O número de conexões de um dado nó é chamado grau desse nó.

O programa descstat.g [7] calcula estatísticas básicas dos nós de um dado grafo — uma das mais importantes é chamada coeficiente de variação [8], e mede a disparidade dos graus dos vértices de um grafo. Idealmente, o coeficiente de variação seria zero para uma rede onde todos nós tivessem o mesmo número de conexões.

O programa connect.g [9] avalia se um dado grafo é ou não conexo. No caso de redes mesh, identifica se todos pontos da rede se vêem ou não.

Tanto descstat.g [7] quanto connect.g [9] foram escritos usando-se o ambiente de programação gvpr, desenvolvido por Emden R. Gansner, disponível no pacote graphviz [10], um Software Livre poderoso, flexível e muito usado para visualização de grafos.

Referências

[1] Wireless mesh network

[2] Wireless access point

[3] Wi-Fi

[4] Teoria dos grafos

[5] Árvore (teoria dos grafos)

[6] Fully-connected network

[7] descstat.g

[8] Coeficiente de variação

[9] connect.g

[10] graphviz

Licença Creative Commons
Esta obra foi licenciada com uma Licença Creative Commons – Atribuição – Partilha nos Mesmos Termos 3.0 Não Adaptada.