Archive for the ‘redes’ Category

Como estimar latência e largura de banda ?

29 de julho de 2010

Hilton Garcia Fernandes

Este é mais um texto sobre latência e largura de banda de redes de computadores do blog Tecnologias sem Fio [1], iniciado com o texto Latência e largura de banda [2], que apresentou os conceitos de acordo com o modelo matemático linear, que é relativamente simples.

Em De onde vem a latência da rede ? [3], também neste blog, foram listados os fenômenos da rede que dão origem a uma demora constante em sua resposta.

Neste texto vão ser comentadas as formas de se estimar os parâmetros latência e largura de banda. Estimar significa que os parâmetros são oscilantes, devido a variações de capacidade da rede.

Além disso, é preciso escolher forma de medir os tempos de passagens de mensagem rede — pois existem muitas formas de usar a rede: leitura e escrita de e-mail, navegação pela Web etc.

Formulação do problema

Qualquer usuário de uma rede, como a Internet [4], sabe que a disponibilidade da rede pode variar. Sendo assim, os valores que se calcula são estimativas; similares às médias, por exemplo.

Além disso, também há o problema de como obter a medida: apesar de ser intuitivo falar nos conceitos, existem muitas formas de se usar uma rede, sendo a Internet apenas uma delas. Por isto, escolhe-se um conjunto limitado de atividades que permita calcular medida; em termos usuais em computação, escolhe-se um benchmark [5].

Apresentação conceitual do benchmark usado

Para medir o tempo de passagem de uma mensagem de um computador A para um outro B, seria preciso que o B informasse em que momento recebeu a mensagem. Para isso teria que enviar uma outra mensagem. Infelizmente, há um problema de sincronização dos relógios dos computadores A e B: como as redes são rápidas, uma mensagem leva pouquíssimo tempo e, os relógios teriam que estar ajustados com muita precisão, o que pode não ser fácil fazer.

Outra solução é que A envie uma mensagem e aguarde a resposta de B a ela. Assim, terá toda temporização do processo é feita em um único computador. Este é o objetivo do benchmark chamado ping-pong [6].

Ele pode ser representado pelo diagrama a seguir, sugerido por [7]

Diagrama conceitual do benchmark ping-pong

Diagrama conceitual do benchmark ping-pong

Para que o computador A envie a mensagem para B, será necessário que a mensagem atravesse camadas de rede, como comentado em [3]. Isto é simbolizado pelo declive d1. A mensagem passa então pela rede durante o tempo t1, quando é recebida por B.

As informações da mensagem então atravessam as camadas de rede, agora no sentido inverso, da camada física para aquela de aplicação, durante o tempo s1. Recebida a mensagem por B, ela é imediatamente enviada de volta para A. Precisa então atravessar camadas de rede, agora daquela de aplicação para a física, o que é feito durante o tempo d2.

E agora a mensagem é transmitida de B para A durante um tempo t2. Quando chega em A, atravessa novamente camadas de rede, durante tempo s2, quando é finalmente recebida pelo programa de benchmark.

O tempo que A mede do envio à recepção da mensagem é a somatória de todos os tempos:

Se condições de rede forem as mesmas, e os computadores A e B forem razoavelmente similares, t1 = t2 = t. E, do mesmo modo, é razoável supor que os tempos de descida à rede são iguais: d1 = d2 = d. E, ainda, que os tempos de subida da camada física até a de aplicação são iguais também: s1 = s2 = s.

Assim, o tempo total se torna:

Considera-se agora os tempos de descida d e subida s de camadas da rede como sendo um único tempo p de percorrer camadas de rede; ou seja: p = d + s. Assim, tem-se a fórmula

Esta fórmula faz lembrar que o tempo medido em A é realmente o dobro do tempo de transmissão de uma mensagem de A para B apenas, sem o retorno: apenas o ping, sem o pong.

É claro que o tempo T vai ser maior quanto maior for o número de bytes transmitidos; exatamente o que ocorre com t. Contudo, p vai ser o mesmo, independente do tamanho da mensagem. Assim, voltando ao modelo linear

É fácil ver que:

  1. α, a constante de custo, é equivalente a p, o tempo em que mensagem “sobe” e “desce” a hierarquia de camadas de rede, da camada física àquela de aplicação e vice-versa;
  2. t, o tempo em que a mensagem foi transmitida, é função do número de bytes a ser transmitidos — equivale no caso a βn;
  3. o tempo total de transmissão T de uma mensagem com n bytes é mesmo função apenas de n e, por isso, é representado como T(n).

De fato, usando métodos estatísticos é possível estimar α e β. A estatística mostra que é praticamente total o ajuste do modelo linear às medidas de rede obtidas por benchmarks como o ping-pong.

Estas conclusões são discutidas a seguir.

Calculando parâmetros através de estatística

A estimativa dos parâmetros α é β é feita através de regressão linear [8]. Em poucas palavras, isto implica em minimizar o erro da aproximação do modelo linear aos tempos medidos de T. São feitas muitas medidas de tempos, para mensagens de diferentes tamanhos: Em notação mais formal, são feitas m medidas de tempos para vários tamanhos de mensagem, que serão chamadas Ti e ni.

(Uma das técnicas para minimizar a variabilidade minimizar os erros de medida é fazer várias medidas de tempo para um mesmo tamanho de mensagem.)

A técnica básica para essa estimativa se chama método dos mínimos quadrados (MMQ) [9]. Trata-se de minimizar o erro quadrático, o somatório de cada diferença entre o medido e o calculado. Isto é expresso pela fórmula:

onde Ti são os tempos medidos; para cada cada um deles um correspondente tamanho de mensagem ni. Assim, o tempo T1 foi obtido quando se usou mensagem de tamanho n1 etc.

A estatística fornece ferramentas para validar, ou não, a aproximação — principalmente se os ajustes não foram muito bons, por exemplo devido a oscilações de tráfego na rede. A ferramenta chamada ANOVA [10] permite avaliar se a aproximação foi tão ruim que o parâmetros β pode ser considerado nulos. Ou seja: não há nenhuma relação entre o tempo T de transmissão da mensagem e n, o tamanho dela em bytes.

O teste t de Student [11] permite avaliar individualmente a qualidade dos parâmetros. Isto é: o quanto α e β ajudam a explicar o comportamento de T em função de valores de n.

R [12] é um Software Livre [13] para estatística muito completo, de excelente qualidade, que tem esses recursos já implementados.

Referências

[1] Tecnologias sem fio
https://tecnologiassemfio.wordpress.com/
Visitado em 28/07/2010

[2] Latência e largura de banda
https://tecnologiassemfio.wordpress.com/2010/07/07/latencia-e-largura-de-banda/
Visitado em 28/07/2010

[3] De onde vem a latência da rede ?
https://tecnologiassemfio.wordpress.com/2010/07/21/de-onde-vem-a-latencia-da-rede-2/
Visitado em 28/07/2010

[4] Internet
https://secure.wikimedia.org/wikipedia/pt/wiki/Internet
Visitado em 28/07/2010

[5] Benchmark (computação)
https://secure.wikimedia.org/wikipedia/pt/wiki/Benchmark_%28computa%C3%A7%C3%A3o%29
Visitado em 28/07/2010

[6] What does ping pong benchmark mean?
http://icl.cs.utk.edu/hpcc/faq/index.html#132
Visitado em 28/07/2010

[7] Benchmarking of Multicast Communication Services
ftp://ftp.cse.msu.edu/pub/acs/reports/msu-cps-acs-103.ps.gz
Visitado em 28/07/2010

[8] Regressão linear
https://secure.wikimedia.org/wikipedia/pt/wiki/Regress%C3%A3o_linear
Visitado em 28/07/2010

[9] Método dos mínimos quadrados
https://secure.wikimedia.org/wikipedia/pt/wiki/Mmq
Visitado em 28/07/2010

[10] Regressão e ANOVA
http://www.fm.usp.br/dim/regressao/rquadrado.php
Visitado em 29/07/2010

[11] Teste t de Student
http://www.exatec.unisinos.br/~gonzalez/valor/inferenc/testes/testet.html
Visitado em 29/07/2010

[12] The R Project for Statistical Computing
http://www.r-project.org/
Visitado em 29/07/2010

[13] Software livre
https://secure.wikimedia.org/wikipedia/pt/wiki/Software_livre
Visitado em 29/07/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.

De onde vem a latência da rede ?

21 de julho de 2010

Hilton Garcia Fernandes

No texto Latência e largura de banda [1], neste blog Tecnologias sem Fio [2], foi discutido o modelo linear

no qual a latência α é um custo constante em tempo da transmissão de n bytes. O fator β multiplicado pelo número de bytes, é associado à máxima banda disponível na rede. Isto é: 1/β é a banda máxima disponível.

Entendidos os conceitos no modelo linear, falta tentar entender o que causa os custos.

A latência pode ser associada a vários fatores

  • em uma rede cabeada do tipo Ethernet [3], é necessário evitar colisões [4]. Ou seja: dois pacotes serem enviados ao mesmo tempo na mesma rede. Há um algoritmo chamado CSMA/CD [5], que permite detectar colisões.
    Seu custo é aproximadamente fixo para um único pacote;
  • em uma rede sem fio do tipo Wi-Fi [6], há um problema semelhante. Neste caso, devido a características do meio físico das ondas eletromagnéticas, o algoritmo é chamado de CSMA/CA [7], e busca evitar colisões (ou collision avoidance), em vez de detectá-las.
    Aqui, o custo também é relativamente fixo para um único pacote;
  • outro problema, a cada dia mais relevante no mundo de internets [8], ou redes interconectadas — e da Internet [9], ou grande rede mundial — é a transferência entre redes, ou roteamento [10]. Neste caso, os pacotes de informação são reescritos, para levar em conta a entrada em outras rede. E isto tem um custo, de novo a cada pacote;
  • ainda há um outro componente dos custos fixos: o chamado encapsulamento e desencapsulamento de pacotes de dados — tanto do ponto de vista teórico da arquitetura OSI [11], ou daquele em geral implementado, a arquitetura TCP/IP [12].
    Em um caso ou outro, a rede é dividida em diversos níveis (ou camadas), o que permite, por exemplo, a independência de tecnologias — redes usando diferentes suportes físicos conseguem comunicar entre si: computadores ligados em redes 3G [13] podem se falar com outros em redes DSL [14]
    O custo de de transferir pacotes entre diferentes camadas da rede também ocorre pacote a pacote.
  • fragmentação de pacotes [15]: pacotes muito grandes podem ter que ser quebrados em pedaços menores, se forem maiores que o tamanho máximo de pacotes naquele segmento de rede, o MTU [16].

Todos estes custos ocorrem pacote a pacote. Sendo assim, se uma mensagem for suficientemente longa para ser quebrada em vários pacotes na rede, sofrerá várias vezes as mesmas negociações de colisão, de roteamento etc. ?

De fato, isto ocorrerá. Mas há efeitos que minoram este poder multiplicativo:

  • aquisição do meio: quando um computador começa a transmitir pela rede, mantém durante algum tempo o direito de transmitir. Isto está incorporado aos algoritmos de tratamento de colisões justamente para minimizar os custos de seguidas negociações;
  • pipelining [17], ou efeito “linha de montagem”: em uma linha de montagem [18], o fato de haver várias unidades trabalhando em paralelo em diferentes partes de um bem a ser montado garante que o intervalo entre o término de diferentes produtos seja menor do que o tempo total de produção de um produto.
    Um velho professor explicava pipelines dizendo que o tempo total para produzir um Volkswagen Sedan (o popular fusca) era de 48 horas. Contudo, o tempo entre um Sedan e outro era de apenas 40 minutos.
    No caso de uma transmissão de rede, há pelo menos dois níveis de paralelismo: a CPU, que processa o encapsulamento dos pacotes e a placa de rede, que faz as negociações de nível mais baixo, necessárias para encaminhar a mensagem pela rede, fazendo negociações CSMA/CA, por exemplo.

Em próximas postagens em Tecnologias sem Fio serão apresentados mais detalhes da estimativa dos importantes parâmetros latência e largura de banda, bem como parâmetros complementares — que podem melhorar a compreensão das redes.

Referências

[1] Latência e largura de banda
https://tecnologiassemfio.wordpress.com/2010/07/07/latencia-e-largura-de-banda/
Visitado em 16/07/2010

[2] Tecnologias sem Fio
https://tecnologiassemfio.wordpress.com/
Visitado em 16/07/2010

[3] Ethernet
https://secure.wikimedia.org/wikipedia/pt/wiki/Ethernet
Visitado em 16/07/2010

[4] Colision domain
https://secure.wikimedia.org/wikipedia/en/wiki/Collision_domain
Visitado em 16/07/2010

[5] CSMA/CD
https://secure.wikimedia.org/wikipedia/en/wiki/CSMA/CD
Visitado em 16/07/2010

[6] Wi-Fi
https://secure.wikimedia.org/wikipedia/pt/wiki/Wi-fi
Visitado em 16/07/2010

[7] CSMA/CA
https://secure.wikimedia.org/wikipedia/en/wiki/CSMA/CA
Visitado em 16/07/2010

[8] Internetworking
https://secure.wikimedia.org/wikipedia/en/wiki/Internetworking
Visitado em 16/07/2010

[9] Internet
https://secure.wikimedia.org/wikipedia/en/wiki/Internet
Visitado em 16/07/2010

[10] Roteamento
https://secure.wikimedia.org/wikipedia/pt/wiki/Roteamento
Visitado em 16/07/2010

[11] OSI model
https://secure.wikimedia.org/wikipedia/en/wiki/OSI_model

Visitado em 16/07/2010

[12] TCP/IP model
https://secure.wikimedia.org/wikipedia/en/wiki/TCP/IP_model
Visitado em 16/07/2010

[13] 3G
https://secure.wikimedia.org/wikipedia/pt/wiki/3G
Visitado em 16/07/2010

[14] DSL
https://secure.wikimedia.org/wikipedia/pt/wiki/
Visitado em 16/07/2010

[15] IP fragmentation
https://secure.wikimedia.org/wikipedia/en/wiki/IP_fragmentation
Visitado em 16/07/2010

[16] Maximum transfer unit
https://secure.wikimedia.org/wikipedia/en/wiki/Maximum_transmission_unit
Visitado em 16/07/2010

[17] Pipelining
https://secure.wikimedia.org/wikipedia/en/wiki/Pipelining
Visitado em 16/07/2010

[18] Assembly line
https://secure.wikimedia.org/wikipedia/en/wiki/Assembly_line
Visitado em 16/07/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.

Latência e largura de banda

7 de julho de 2010

Hilton Garcia Fernandes

Muito já foi dito e continua a ser falado sobre latência e largura de banda, dois conceitos fundamentais para a compreensão e caracterização das redes de computadores. É uma pena que, mesmo que sob os nomes equivalentes em inglês, latency e bandwidth, não é fácil encontrar na Web, a teia mundial dos computadores, definições claras e precisas dos termos. Talvez estes pertençam àquele tipo de termo que é reservado apenas a estudiosos práticos e estudantes acadêmicos de redes de computadores.

Um dos melhores textos sobre o assunto é [1], que define latência e largura de banda com bom humor e clareza. Aqui se usará a matemática, que pode apresentar esses conceitos com precisão e também clareza — apesar de que com menos humor.

É costumeiro descrever o tempo [2] — digamos em segundos — que é gasto em uma dada rede para transmitir uma mensagem de de n bytes como sendo

Usando termos matemáticos, esta é a equação de uma reta, onde α é a constante, ou coeficiente linear. E β é o gradiente da reta, ou coeficiente angular.

Se fosse possível transmitir uma mensagem de 0 bytes, o tempo T(0) seria α segundos. O parâmetro α é chamado de latência, ou até mesmo “latência da mensagem de zero bytes”. Para entender o significado de β na fórmula para T(n), vale a pena considerar a taxa de transferência B(n) conseguida para n bytes. Ela é

A taxa de transferência é calculada dividindo-se o número de bytes transferidos pelo tempo que a transferência ocorreu.

Para poder analisar melhor a fórmula, vale a pena considerar o inverso de B(n), ou

Voltando a B(n), tem-se

Quando n é muito grande, a divisão α/n fica muito pequena e tem-se:

Este é a máxima taxa de transmissão desta rede. Por isso, é costumeiro chamar o parâmetro 1/β de largura de banda da rede. Para evitar a divisão é que Hockney [2] apresenta a mesma fórmula para T(n) com o coeficiente angular na forma inversa, ou seja:

Deste modo, Hockney [2] pode falar na largura de banda como sendo ρ apenas, não como a divisão 1/β. Mas esta é apenas uma conveniência: os conceitos são os mesmos.

Conclusão

Resumindo:

  • latência (ou latency) é um custo inicial da rede, pago em toda transmissão de mensagem que nela seja feita — até mesmo na mensagem teórica de comprimento zero bytes.
  • largura de banda (ou bandwidth) é o desempenho máximo de uma rede, só atingido teoricamente em mensagens de tamanho infinito — do qual a rede se aproxima para mensagens muito grandes.

De qualquer modo, considera-se que latência e largura de banda como parâmetros capazes de descrever uma rede quase completamente.

Em próximas postagens em Tecnologias sem Fio serão apresentados mais detalhes destes dois importantes parâmetros, bem como parâmetros complementares — que podem melhorar a compreensão das redes.

Referências

[1] It’s the Latency, Stupid
http://rescomp.stanford.edu/~cheshire/rants/Latency.html
Visitado em 02/06/2010

[2] R. Hockney, “The communication challenge for MPP: Intel Paragon and Meiko CS-2,” Parallel Computing, vol. 20, no. 3, pp. 389-398, March 1994.

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.

Web caching para uma Internet mais rápida

5 de junho de 2010

Rodrigo Filipe Silva Carramate


Web caching nada mais é do que um processo pelo qual se armazena localmente conteúdo disponível na internet, a fim de minimizar o tráfego de rede e sua latência [1]. Apesar de parecer um conceito simples e de fácil compreensão, temos no web caching uma grande ajuda em dois fatores críticos nas redes atuais: a largura de banda [2] e a latência.

Devido à queda no custo da Internet de banda larga para o usuário final doméstico e empresarial nos últimos anos, temos muitas vezes a falsa impressão de que largura de banda se tornou algo economicamente acessível. Na verdade isto é um equívoco, uma vez que esse tipo de usuário paga, na verdade, por uma concessão que, segundo o SLA [3] (em português “Acordo do nível de serviço”), lhe garante apenas 10% do que contrata nominalmente. Temos porém exemplos em que a situação é bastante diferente, como no caso de pequenos provedores, em que há necessidade de um SLA que garanta algo próximo dos 100% da banda; nestes casos temos preços bastante elevados para o total de banda contratado. Desta forma, quanto menor for a demanda de banda nessas redes, menor será o custo com contratação de banda.

Outro grande problema que frequentemente encontramos é a baixa latência. Este costuma ser mais notado quando utilizamos algum serviço de streaming [4] diretamente da Internet, seja ao realizar uma video-conferência ou ao assistir a algum vídeo diretamente da Internet. Geralmente o sintoma mais comum em uma rede com baixa latência são travamentos frequentes durante a execução dessas tarefas.

Infelizmente, o web caching é limitado apenas ao caso da execução de conteúdo arquivado, porém, nesse contexto o web caching se torna um excelente aliado: ao manter em servidores locais o conteúdo da Internet mais acessado, evitam-se acessos externos desnecessários, sendo o mesmo conteúdo repassado diretamente pelos servidores ao usuário. Assim, além de o usuário receber a informação muito mais rapidamente, permitindo uma navegação muito mais proveitosa, há uma economia considerável de recursos, já que a necessidade de banda diminui consideravelmente.

Além de beneficiar a velocidade do acesso dos usuários da sua rede à Internet, o web caching ainda tem outro grande atrativo: o Squid [5], que é o software de web caching mais utilizado mundialmente tem seu código aberto, o que significa que todos podem estudá-lo e o melhorar. Além disso, felizmente alguns dos programadores do Squid têm permitido que seus usuários o possam usar gratuitamente.

Devemos entender também que há vários tipos de caching, entre eles o caching feito na própria máquina e aquele feito na rede local. O primeiro é mais comumente feito pelo próprio navegador, possibilitando que se volte de maneira praticamente instantânea a páginas visitadas recentemente. O segundo, foco deste artigo, objetiva criar um cache compartilhado entre os usuários de uma mesma rede, de tal modo que se um usuário acessar uma determinada página, o servidor grava todo seu conteúdo automaticamente e distribui a cópia a cada uma das próximas tentativas de acesso.

A aquisição de uma página por um navegador sem uso de web caching se dá pelo contato direto entre o cliente e o servidor que hospeda a página, havendo transferência direta dos dados. Quando se utiliza o web caching, o navegador faz a requisição da mesma forma, porém quem recebe e interpreta o pedido é o servidor de web cache. Este procura pela página em seu cache e, caso a possua, avalia sua idade e a compara com a sua data de validade estipulada pelo criador da página ou segundo um conjunto de regras estipuladas pelo próprio servidor de web cache. Caso a página ainda seja válida, a envia ao cliente; caso contrário, redireciona o cliente à página original e cria em seu cache uma cópia da mesma.

Um problema que pode ocorrer é dado pelo chamado balanço de carga: para dividir o trabalho entre servidores distintos, um mesmo conteúdo é reescrito em URLs semelhantes, mas não iguais. Por exemplo, em [6] é dado o exemplo de uma mesma imagem armazenada em 3 diferentes servidores do Orkut:

http://img1.orkut.com/imagem1.jpg (1)
http://img2.orkut.com/imagem1.jpg (2)
http://img3.orkut.com/imagem1.jpg (3)

Como o Squid trabalha através de URLs, ele entenderia que são 3 arquivos diferentes, o que causaria muito mais transferências do que necessário. Sendo assim, há softwares como o InComum [7], que podem ser programados para dar ao Squid a habilidade de reconhecer essa similaridade.

O processamento da URL para detectar a uniformidade pode ser bastante complexo, uma vez que a URL pode conter muito mais informações do que aquela do nome do servidor e do arquivo. Podem haver, por exemplo, informações para controle da sessão.

Conclusão

A arquitetura complexa e gigantesca de sistemas como o da Wikimedia[8], fundação que atende os projetos Wikipedia, Wikidictionary, entre outros, só é realizável devido à existência de formas para minimizar o tráfego interno e externo, através do Squid.

A imagem mostra um grupo muito grande de servidores formando um cluster, no qual há vários servidores squid.

Servidores da Wikimedia

Arquitetura de servidores da Wikimedia

Referências

[1] It’s the Latency, Stupid
http://www.stuartcheshire.org/rants/Latency.html
Visitado em 31/05/2010

[2] Largura de banda
http://pt.wikipedia.org/wiki/Largura_de_banda_%28telecomunica%C3%A7%C3%B5es%29
Visitado em 31/05/2010

[3] Acordo de nível de serviço
http://pt.wikipedia.org/wiki/Acordo_de_N%C3%ADvel_de_Servi%C3%A7o
Visitado em 31/05/2010

[4] Streaming Definition
http://www.techterms.com/definition/streaming
Visitado em 31/05/2010

[5] Squid: Optimising Web Delivery
http://www.squid-cache.org/
Visitado em 31/05/2010

[6] Cache efetivo de vídeos do Youtube com Squid
http://www.lucianopinheiro.net/portal/?q=node/130
Visitado em 31/05/2010

[7] inComum
http://sourceforge.net/projects/incomum/
Visitado em 31/05/2010

[8] Wikimedia servers
http://meta.wikimedia.org/wiki/Wikimedia_servers
Visitado em 31/05/2010

Saiba mais

Abordagens mais aprofundadas sobre web caching

[9] Web caching
http://www.ccda.biz/web/about/ac123/ac147/ac174/ac199/about_cisco_ipj_archive_article09186a00800c8903.html
Visitado em 31/05/2010

[10] Introdução ao Cache de Web
http://www.rnp.br/newsgen/0003/cache.html
Visitado em 31/05/2010

[11] Making the Most of Your Internet Connection
http://www.web-cache.com/
Visitado em 31/05/2010

Relação entre web caching e QoS

[12] ENHANCING QoS IN WEB CACHING USING DIFFERENTIATED SERVICES
http://www.tmrfindia.org/ijcsa/V3I17.pdf
Visitado em 31/05/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.

Confiabilidade do projeto SAWiM (parte 1 de 2)

9 de abril de 2010

Fábio Damião Barbosa Ricci

Redes Mesh sem fio possuem grandes vantagens comparadas às redes cabeadas, destacando-se principalmente pelo baixo custo, implementação gradual e tolerância a falhas [1]. Elas podem ser tão confiáveis quanto redes cabeadas através do uso adequado de protocolos de comunicação, encriptação, modulação de sinal, uso adequado de antenas, topologia de rede etc. Tais ferramentas foram desenvolvidas e aperfeiçoadas justamente para garantir à comunicação sem-fio as características já inerentes de uma comunicação cabeada.

Baseada nestas premissas o projeto SAWiM [2] busca conciliar esta confiabilidade de comunicação com o desenvolvimento de um novo tipo de controlador semafórico.

Em visita realizada ao estande de empresas fabricantes de controladores semafóricos na feira de infraestrutura de transportes TranspoQuip [3] em 2009, houve certa resistência a um novo conceito de controlador semafórico, já que este é um produto desenvolvido há muito tempo e com muito cuidado para garantir confiabilidade de operação. Com isso, sua tecnologia pouco evoluiu no decorrer de décadas. Devido a esta lenta evolução, pôde-se perceber grande interesse por parte de engenheiros da empresa sobre a nova tecnologia de Rede Mesh, que poderia ser utilizada na interligação dos controladores de tráfego com a central de controle e, com isso, além de garantir a tão consagrada confiabilidade dos controladores eletrônicos de tráfego, garantir também sua controlabilidade a partir de um centro de gerência.

O desenvolvimento do projeto SAWiM deve gerar um produto capaz  de se adequar às especificações das companhias de engenharia de tráfego metropolitanas, que estabelecem as mínimas condições técnicas e funcionais. Tais exigências especificam características técnicas básicas, características funcionais, modos de operação, características gerais de projeto e construção, documentação técnica, ensaios, inspeção e aceitação.

Apesar dos semáforos aparentarem para o usuário serem apenas dispositivos simples que acionam lâmpadas, todas as suas especificações são complexas com parâmetros técnicos e funcionais detalhados, como por exemplo os que especificam sequência de cores, períodos de entreverdes e tempos de segurança, tipos de estágios quanto ao tempo de duração (fixa ou variável) e quanto a ocorrência dentro do ciclo de duração (dispensáveis ou indispensáveis).

Esta e outras normas devem ser seguidas por se tratar de um dispositivo que deve lidar com a vida humana. Sua padronização elétrica e funcional garante a homogeneidade e confiabilidade do sistema semafórico como um todo.

O projeto do controlador SAWiM é composto por 2 módulos interligados por um cabo: um módulo Mesh que possui um sistema Linux embarcado responsável pela programação e comunicação,  e um módulo Atuador. Sua principal diferença com um controlador convencional é o fato de haver um controlador por semáforo e sua comunicação adjacente e programação de ações são feitas pelo software rodando em Linux no módulo Mesh, permitindo, com isso, uma grande maleabilidade de ações e processamento devido à grande flexibilidade operacional de um sistema Linux.  O módulo Atuador se responsabiliza pela realização das ações, medições e sensoriamento, comunicando-se intermitentemente com o módulo Mesh.

A comunicação em Rede Mesh é feita com  semáforos intra-grupo quando é necessária a alteração de sinalização em apenas um grupo semafórico e também pode ser feita inter-grupos,  quando é necessária uma sincronização entre grupos semafóricos, de cruzamentos diferentes.

A ilustração abaixo descreve um exemplo simplificado de comunicação:

Exemplo de comunicação entre controladores SAWiM.

Neste exemplo, temos a comunicação intra-grupo entre o controlador mestre, seu adjacente e seu opositor.  Também há comunicação inter-grupos entre 2 controladores SAWiM mestres. Neste exemplo de comunicação inter-grupos, o controlador mestre A envia uma mensagem de comando ao controlador mestre B para alterar sua sinalização após um período de t segundos, realizando, com isso, a  sincronização sequencial de tempos de verde (onda verde [4]).

Por tudo isso, o projeto SAWiM tem como objetivo quebrar paradigmas de sistemas de controladores semafóricos, desenvolvendo uma nova tecnologia passível de grande confiabilidade, maleabilidade funcional e baixo custo. Apesar disso, por se tratar de um novo produto em desenvolvimento, ainda é impossível compararmos sua confiabilidade com os consagrados controladores atuais.

Referências

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

Visitado em 08/04/2010

[2] Trânsito e Redes Mesh
https://tecnologiassemfio.wordpress.com/2010/02/12/transito-e-redes-mesh/

Visitado em 09/04/2010

[3] TranspoQuip.
http://www.transpoquip.com.br/br/index.html

Visitado em 09/04/2010

[4] Onda verde – Instituto Trânsito Brasil.
http://www.transitobrasil.org/anexos/artigos/145.pdf

Visitado em 09/04/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

Banda larga, 3G e contas

2 de abril de 2010

Hilton Garcia Fernandes

Em 16 de outubro de 2009, durante a Futurecom 2009 [1], o presidente da Oi [2], Luiz Eduardo Falco deu uma entrevista à Convergência Digital TV [3], que foi publicada no Youtube [4].

Nesta entrevista, Falco faz várias afirmações que valem a pena ser discutidas; algumas bastante polêmicas. Contudo, uma das mais importantes, título do video e apresentada no resumo do video no Youtube, não está contida no video. Pode ser localizada em matérias relacionadas, como [5], de Ethevaldo Siqueira [6]. Seria a afirmativa de que as teles já investiram cerca de R$ 11 bilhões e têm cerca de 200.000 km de rede construída. Muitos a discutem, mas isto não será feito aqui, pois outro é o foco deste texto.

O que será discutido são duas afirmações de Falco, a respeito da possibilidade e oportunidade de banda larga no 3G [7], e uma estimativa de custos apresentada por ele para uma rede desse tipo.

Web 2.0 e transparência

Por uma questão de justiça, deve-se louvar a transparência permitida pela Web 2.0 [8], que permite que conteúdos como o deste vídeo possam ser oferecidos para a população. Antes dela, seria difícil conhecer o pensamento vivo do presidente de uma operadora como a Oi.

Também foi possível que a população se manifestasse a respeito das opiniões do presidente da Oi expressas na entrevista [4]. Em geral de forma bastante agressiva, com palavrões e, num primeiro momento, até mesmo com racismo. Felizmente, a Web 2.0 tem seus mecanismos de ajuste e os ataques racistas foram retirados.

De qualquer modo, o que resta é que a população — e os brasileiros usuários do Youtube são parte importante dela –, está bastante insatisfeita com o padrão de serviços oferecidos pelas teles.

Banda larga 3G

A afirmação de Falco que causou polêmica em [4] foi a que não é possível, e nem desejável que os usuários tenham direito a 3G com banda maior do que 300 kbps.

Segundo o raciocínio de Falco, seria muito caro desenvolver redes para oferecer 30 Mbps, ou megabits por segundo, para a população. E, afinal de contas, com 300 kbps se tem navegação satisfatória, para usuários individuais, segundo ele.

Um ponto muito triste é que as operadoras venderam planos de capacidades muito maiores do que os 300 kbps — na faixa de 1 Mbps. Com certeza elas se resguardaram em cláusulas contratuais de fornecimento garantido, possivelmente de apenas 10% do valor nominal: assim 1 Mbps nominal vira apenas 100 kbps garantidos.

Não é de se surpreender que usuários tenham se manifestado de modo tão agressivo quanto aquele visto nos comentários da entrevista [4].

Sem querer colocar as teles como empresas malévolas, é necessário admitir que, mundialmente, toda comunidade de telecomunicações se surpreendeu com o crescimento, no último ano, do consumo da banda larga móvel. Em termos mundiais, ele foi de cerca de 72% [9]. No Brasil, chegou a ser de incríveis 327% [10].

Duas conclusões:

  1. há uma demanda incrivelmente reprimida no atendimento da Internet, que que leva usuários a procurarem alternativas de atendimento.Claro que o brasileiro é um povo fascinado por novidades, e é claro que há conveniências na banda larga móvel. Mas 327% são 327%;
  2. o modelo concorrencial brasileiro, que analistas ponderados como Cláudio Dascal não hesitam em chamar de “cartel” [11], tem sido muito tolerante com as empresas também quanto à exigência de serviços e planos de investimento.Afinal, mesmo que o erro, humana ou tecnicamente seja inevitável, a correção também deveria sê-lo: se o consumo de banda larga 3G excedeu as expectativas, as agência reguladoras deveriam pressionar as empresas para uma solução que garantisse melhor qualidade de serviço. Mesmo que os contratos, juridicamente, ainda sejam válidos, garantir apenas 10 % do valor nominal é extremamente insatisfatório para empresas e usuários.

Contas para infra-estrutura

Um outro ponto muito interessante na entrevista de Falco [4] é sua afirmativa de que, em uma rede de operadora típica, valem as seguintes proporções aproximadas de custo:

  • o backbone [12] corresponde a 15% do custo global da rede;
  • o backhaul, ou a parte da rede por onde ele trafega [12], custa entre 35 e 50%;
  • o last mile, ou rede de atendimento ao cliente [12], custa cerca de 50%

Em uma entrevista, alguma imprecisão entre valores deve ser tolerada. Sendo assim, se o custo da rede do backhaul varia entre 35% e 50%, é provável que, nesta estimativa, o custo do last-mile (outro grande custo) também deva variar entre estas faixas visando chegar a 100%. Como o custo do backbone é o menor dos três componentes, sua variabilidade aparentemente tem de ser menor.

Seria interessante aplicar as contas ao projeto de rede nacional de banda larga, aventada pelo governo federal [12]. Em primeiro lugar, segue a imagem do mapa de fibra óptica disponível.

Backbone da Eletronet

Pode-se ver que é uma rede muito ampla que cobre mais do que o litoral, chegando ao Tocantins e ao interior do Maranhão. Alguns [13] estimaram a rede da Eletronet em cerca de R$ 600 milhões. Portanto, o total da rede, segundo esses cálculos estaria em em cerca de R$ 4 bilhões. Estes recursos seriam suficientes para cobrir grande parte do território nacional — ou pelo menos a parte onde está grande parte da população.

Simetricamente, as teles têm comentado [5] que seus investimentos chegam a R$ 11 bilhões. Refazendo as contas, tem-se que, destes cerca de R$ 1,6 bilhões seriam o custo de seu backbone. Dividindo esse valor por 4 — pois parece ser este o número das maiores operadoras — ter-se-iam backbones de R$ 400 milhões. Ou cerca de 67% inferiores àqueles da Eletronet, já bastante impressionantes. Seria interessante ver mapas dos backbones das teles para fazer essa comparação de modo justo.

Estas são contas muito simplificadas, que não levam em conta a história de cada companhia: algumas teles receberam parte de seu backbone das estatais que compraram; outras têm grande parte de sua clientela em área relativamente reduzida.

Mas fazem pensar que números da casa de bilhões ou milhões de reais devem ser apresentados com bastante cuidado, maior do que aquele que está sendo praticado no debate do PNBL.

Referências

[1] Futurecom 2009
http://www.futurecom2009.com.br/
Visitado em 25 de março de 2009

[2] Oi (telecomunicações)
https://secure.wikimedia.org/wikipedia/pt/wiki/Oi_(telecomunica%C3%A7%C3%B5es)
Visitado em 25 de março de 2009

[3] Convergência Digital TV
http://www.convergenciadigital.com.br/cgi/cgilua.exe/sys/start.htm?sid=84
Visitado em 25 de março de 2009

[4] Banda Larga: Brasil não pode se dar ao luxo de duplicar infraestrutura
http://www.youtube.com/watch?v=0tMRE1t93NU&feature=related
Visitado em 25 de março de 2009

[5] Teles e especialistas rejeitam estatização – Ethevaldo Siqueira
http://www.ethevaldo.com.br/Generic.aspx?pid=1555
Visitado em 25 de março de 2009

[6] Ethevaldo Siqueira
https://secure.wikimedia.org/wikipedia/pt/wiki/Ethevaldo_siqueira
Visitado em 25 de março de 2009

[7] 3G
https://secure.wikimedia.org/wikipedia/pt/wiki/3g
Visitado em 25 de março de 2009

[8] Web 2.0
https://secure.wikimedia.org/wikipedia/pt/wiki/Web_2.0
Visitado em 25 de março de 2009

[9] Allot MobileTrends: Global Mobile Broadband Traffic Report Shows Significant 72% Growth in Worldwide Mobile Data Bandwidth Usage in H2, 2009
http://bit.ly/boQr46
Visitado em 25 de março de 2009

[10] Banda larga móvel cresce 227%
http://bit.ly/bw5JiY
Visitado em 25 de março de 2009

[11] Mais um competidor em telefonia celular?
Teletime, Ano 13, no. 130, Março 2010

[12] Plano Nacional de Banda Larga: primeiras ideias
https://tecnologiassemfio.wordpress.com/2010/02/19/plano-nacional-de-banda-larga-primeiras-ideias/
Visitado em 25 de março de 2009

[13] Oi negocia compra de dívida da Eletronet por R$ 140 mi
http://insight-laboratoriodeideias.blogspot.com/2010/02/oi-negocia-compra-de-divida-da.html
Visitado em 25 de março de 2009

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.

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