Archive for the ‘network’ 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.

Anúncios

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.

Modem 3G Sony Ericsson MD300 USB no Linux

17 de abril de 2010

Marcio Barbado Junior
(BDS Labs)

Este é um tutorial prático para instalar no GNU/Linux o modem 3G, modelo MD300, fabricado pela Sony Ericsson para operar em sistemas operacionais proprietários.

Pode-se em certa medida, aproveitar este conteúdo para qualquer combinação entre uma distro e um modem 3G USB, fazendo-se pequenas adaptações nos passos descritos, que são especificamente focados no modem MD300 e em distribuições baseadas em Fedora/Red Hat e Debian.

É possível o utilizar com HSDPA, UMTS, EDGE e GPRS mas o equipamento não oferece suporte para chamadas de voz GSM. Também pode enviar e receber mensagens SMS. Tudo isso é fácil, considerando-se Windows e Mac OS.

Essas situações contudo causam “dores de cabeça” a usuários Linux, e muitos acabam deixando de utilizar o pinguim por não terem seu hardware devidamente reconhecido. Problema recorrente.

O caso é que usuários PJ (ou pessoa jurídica, empresariais) são grandes disseminadores de paradigmas tecnológicos, e o dispositivo da Sony Ericsson representa uma grande barreira à adoção do Linux na medida em que a operadora Claro vem sugerindo a seus clientes “corporativos” a utilização do modem em questão, o que inclusive constitui uma especie de venda casada, já que ao aceitarem a “sugestão”, os clientes se vêem obrigados a possuir/adquirir uma licença paga de modo que possam usufruir do equipamento.

A questão toda se resume à constatação de uma estrategia velada, adotada por grandes players do mercado, que acaba por minar a confiabilidade do Linux.

Assim, as presentes linhas objetivam aliviar o incômodo e o desrespeito causado aos usuários do pinguim, e principalmente perseverar na batalha em prol da transparência de códigos E nessa missão, discorrem principalmente sobre udev e wvdial.

1 Introdução

Utilizou-se para redação destas linhas um sistema Fedora 10 de 64 bits, kernel “2.6.27.5”. As adaptações para Debian são citadas sempre que preciso, e com pequenas alterações, o roteiro poderá resolver problemas de outras distribuições Linux que estiverem utilizando outros modems 3G USB.

Apesar do que afirmam alguns especialistas, versões de kernel posteriores à “2.6.19” podem encontrar dificuldades para entender um modem 3G USB [1].

No Brasil, o MD300 é utilizado principalmente em sistemas operacionais Windows, e nesses, é gerenciado por um software proprietário chamado “Wireless Manager”, que se instala automaticamente, “espetando-se” o modem.

Bem, a historia é diferente no Linux. O pinguim exigirá que se escreva uma regra de udev, e que se configure o wvdial para então aceitar e entender o equipamento.

A regra de udev elimina o problema da detecção automática da memória flash presente no equipamento, e ativa o dispositivo /dev/ACM0 ou seja, o udev permitirá que o MD300 seja devidamente reconhecido pelo sistema. O wvdial é um discador dial-up inteligente que será utilizado para fazer o modem funcionar com PPP (daemon pppd) após ser reconhecido.

É dito “inteligente” pois utiliza algoritmos heurísticos para obter a conexão Algumas vezes, tais algoritmos mais atrapalham do que ajudam.
São mostrados com simplicidade e detalhes, todos os passos necessários para suplantar as barreiras impostas pela Sony Ericsson aos usuários Linux. Tais dificuldades serão combatidas, e a rede da Claro será utilizada sem a necessidade de se conhecer o PIN e/ou o PUK do equipamento. Todavia, faz-se preciso o conhecimento de algumas informações elementares da operadora como o APN e o “número” para o qual ligar por exemplo.

1.1- Medidas preliminares

Caso se esteja utilizando o SELinux — recomenda-se que sim — coloque-o provisoriamente em modo permissivo até que o modem esteja funcionando corretamente. Isso é feito no arquivo /etc/sysconfig/selinux com a linha:

SELINUX=permissive

Outro ponto a se verificar diz respeito às presenças do kppp, gnome-ppp, wvdial e minicom, ferramentas que poderão ser usadas:

$ rpm -q kppp gnome-ppp wvdial minicom

ou:

$ which kppp gnome-ppp wvdial minicom

Caso não estejam presentes, deve-se ao menos realizar a instalação do wvdial embora os comandos abaixo instalem as três, que é a recomendação deste tutorial:

# yum install kppp gnome-ppp wvdial minicom

ou:

# apt-get -y install kppp gnome-ppp wvdial minicom

Uma medida a se tomar após as instalações diz respeito à permissão de escrita que os usuários devem possuir em:

/etc/ppp/pap-secrets

e:

/etc/ppp/chap-secrets

que são arquivos utilizados pelo wvdial.
O próximo passo é permitir que contas de usuário utilizem o wvdial pois o mesmo só pode ser executado pela conta root. Isso pode ser feito com o sudo, lembrando que o wvdial fica costumeiramente em /usr/bin/wvdial.

2- udev rules! [2]

Constitui um percalço comum em distribuições Fedora / Red Hat e RHEL, a situação em que o sistema não consegue disponibilizar o modem automaticamente. Isso pode estar relacionado à memória flash contida no dispositivo, que provavelmente estará sendo detectada e montada automaticamente como uma mídia USB genérica no diretório /media/ (ou /mnt/ para distribuições baseadas em Debian).

O problema existindo, irá interferir na correta detecção do MD300. Pode-se detectar essa falha rapidamente se o sistema utilizar um ambiente gráfico, constatando-se o ícone MD300 no Desktop. E nesses casos basta dizer ao sistema operacional para não detectar a memória flash do modem como uma mídia USB.

Todavia, essa correção NÂO deve ser feita através do gerenciador gráfico de dispositivos USB ou editando-se o arquivo /etc/fstab. A questão é resolvida com o udev!

Sucessor do devfs, o versátil udev é um componente escrito em C, que opera dinamicamente sobre o diretório /dev/, local em que cria arquivos de dispositivos. É comum para dispositivos seriais, a utilização de arquivos do tipo tty*, exemplo:

/dev/ttyS3

ou:

/dev/ttyUSB0

O equipamento Sony Ericsson possui várias funções, capazes de ativar dispositivos no diretório /dev/, exemplo:

FUNÇÃO DISPOSITIVO EXEMPLO
rede /dev/eth[N] /dev/eth2
memória flash /dev/sdb[N] /dev/sdb1
modem /dev/ttyS[N] /dev/ttyS1

A função “memória flash”, quando detectada, impede o correto uncionamento do MD300 mas o mesmo NÃO pode ser dito sobre a função de rede — em geral dispositivo /dev/eth2.
Cabe destacar a existência de uma correspondência aproximada entre os padrões para portas seriais em UNIX e MS-DOS.
Enquanto o padrão de Redmond é COMn, com n iniciado em 1 — por exemplo: COM1 –, o padrão UNIX é ttySn, com n iniciado em 0. No exemplo dado, /dev/ttyS0.
A tabela abaixo apresenta essa correspondência de forma mais detalhada:

/dev/ttys0 (COM1) porta 0x3f8 IRQ 4
/dev/ttys2 (COM3) porta 0x3e8 IRQ 4
/dev/ttys3 (COM4) porta 0x2e8 IRQ 3

Qual (ou quais) dos ttySn corresponde (ou correspondem) ao MD300?

Pois é: nenhum deles. A regra a ser escrita irá inibir o reconhecimento da memória flash e mostrar que para o MD300, o sistema operacional utiliza /dev/ttyACM0.

Faz-se a regra do udev através da criação de um arquivo de texto com sufixo .rules no diretório /etc/udev/rules.d/:

# vim /etc/udev/rules.d/50-md300modem.rules

Copia-se o conteúdo a seguir neste arquivo. Cuidado com as aspas simples e duplas ao copiar e colar. Confira se elas foram transportadas corretamente depois de colar:

ACTION!="add", GOTO="3G_End"
BUS=="usb", SYSFS{idProduct}=="d0cf", SYSFS{idVendor}=="0fce", 
PROGRAM="/bin/sh -c 'echo 3 > /sys/%p/bConfigurationValue'"
LABEL="3G_End"

Os valores de SYSFS{idProduct} e SYSFS{idVendor} devem ser obtidas através do dmesg:

$ dmesg | grep usb

que apresentará em sua saída, tais informações:

usb 3-2: New USB device found, idVendor=0fce, idProduct=d0cf
usb 3-2: Product: Sony Ericsson MD300
usb 3-2: Manufacturer: Sony Ericsson

Criado o arquivo, reinicia-se o sistema operacional.

3- wvdial [3] [4]

Grosso modo, o wvdial (ou Weave Dial) é um discador escrito em C++ por Dave Coombs e Avery Pennarun, e licenciado sob a LGPL, que não é “viral” como a GPL, infelizmente.

O programa, que utiliza o protocolo PPP através do daemon pppd, deve ser utilizado pela conta root a princípio, e automatiza diversas tarefas, tornando desnecessário o conhecimento de PIN e PUK para a conexão.

Utilizado em linha de comando, caso não possua opções, o discador irá ler seu arquivo de configurações globais:

/etc/wvdial.conf

e em seguida, um dos arquivos das contas de usuário, que são:
~/.wvdial.conf

ou:

~/.wvdialrc

eventualmente presentes no diretório home do usuário
Os arquivos de configuração seguem o padrão .ini do Windows. Os nomes das seções estão entre colchetes e seus conteúdos são sequências de linhas no modelo:

variável = valor

Linhas comentadas são iniciadas pelo caractere “ponto e virgula”, ou “;“. Antes mesmo de se usar o wvdial pela primeira vez, é preciso executar como root o programa wvdialconf, que possivelmente identificará a porta serial do modem:

# wvdialconf /etc/wvdial.conf

Caso a ferramenta tenha êxito, o dispositivo referente ao MD300 será detectado e algumas informações básicas de configuração serão carregadas no arquivo global /etc/wvdial.conf, que em seguida deve ser editado com informações especificas:

# vim /etc/wvdial.conf

Utiliza-se o seguinte conteúdo no arquivo — algumas linhas já terão sido preenchidas pelo wvdialconf:

[Dialer Defaults]
Modem = /dev/ttyACM0
Modem Type = USB Modem
Baud = 460800
Init = ATZ
Init2 = AT+CFUN=1
Init3 = ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0
Init4 = AT+CGDCONT=1,"IP","bandalarga.claro.com.br"
Init5 =
Init6 =
Init7 =
Init8 =
Init9 =
Phone = *99***1#
Dial Command = ATM1L3DT
Username = claro
Password = claro
Stupid Mode = 1
Auto DNS = on
Check DNS = on
Check Def Route = on
Remote Name = *
Carrier Check = on
Auto Reconnect = on
Abort on No Dialtone = on
Dial Attempts = 3
ISDN = 0

Atenção com as aspas.

O exemplo é especifico para o MD300 e para a Claro. Valores à direita de = e algumas variáveis poderão mudar em acordo com o modem e a operadora utilizada. O comando:

$ man wvdial.conf

fornece mais informações sobre o devido preenchimento do arquivo /etc/wvdial.conf, procedimento este que após ser concluído, deve ser seguido de uma reinicialização do sistema operacional com o modem espetado, e então a conexão pode ser gerenciada pelo kppp e/ou pelo gnome-ppp; e/ou diretamente pelo wvdial:

$ sudo wvdial

e para se desconectar, caso tenha usado o wvdial, pressione Ctrl + c.

4- Soluções de problemas

Caso a conexão fique instável, é possível como root, verificar o que ocorre no sistema em tempo real com o tail, utilizando-se a opção -f (de follow) para seguir os últimos registros:

# tail -f /var/log/audit/audit.log

ou:

# tail -f /var/log/messages

Os registros do arquivo /var/log/audit/audit.log serão úteis caso o SELinux esteja ativado.

As seções a seguir cobrem os problemas mais comuns que podem aparecer com os procedimentos aqui descritos.

4.1- Arquivos de configurações do wvdial [4]

Talvez o leitor tenha optado por editar arquivos do usuário, que são o:

~/.wvdial.conf

e/ou o:

~/.wvdialrc

e o wvdial não o(s) esteja utilizando.

Isso se resolve colando todas as configurações supracitadas no arquivo global, chamado /etc/wvdial.conf.

4.2- Conecta mas o web browser não carrega conteúdo

Cabe salientar que em alguns casos a saída que o wvdial apresenta no terminal leva a crer que os servidores de nomes (DNS) foram devidamente obtidos, exemplo:

--> pppd: =
--> primary DNS address 200.169.119.221
--> pppd: =
--> secondary DNS address 200.169.119.222
--> pppd: =

O sintoma é o navegador reclamando de um endereço qualquer como http://www.google.com ou http://www.bdslabs.com.br. O conteúdo simplesmente não é exibido.
E, ao contrário do que possa parecer, talvez esteja ocorrendo um erro relacionado a DNS.

Isso pode ser verificado da seguinte forma. Caso seja possível pingar um IP (por exemplo, 200.169.119.221) mas não seja possível pingar um nome (por exemplo, http://www.google.com), então o problema é de fato a obtenção dos servidores de nomes, e a solução é adicionar as seguintes linhas no final do arquivo /etc/resolv.conf:

domain bandalarga.claro.com.br
nameserver 200.169.119.221
nameserver 200.169.119.222

Este procedimento corresponde à copia do conteúdo presente em /etc/ppp/resolv.conf no arquivo /etc/resolv.conf.
O arquivo /etc/ppp/resolv.conf possuirá os IPs mostrados na saída do wvdial.

4.3- Não é possível se descobrir a porta serial do modem

Uma opção para essa situação é utilizar o programa minicom [5].

Nativo em muitas distros, ele só pode ser configurado e testado em uma porta serial de cada vez. A configuração começa através do comando:

# minicom -s

que leva ao menu configuration no qual se escolhe a opção Serial port setup. Uma vez lá, modifique Serial Device e retorne ao menu. Escolha então Save setup as dfl e em seguida, Exit from Minicom. Execute o programa novamente:

# minicom

e digite:

AT

é esperada uma resposta OK; caso não se obtenha tal resposta, digite:

ATQ0 V1 EI

novamente, espera-se uma resposta OK. Caso ela não venha mesmo assim, refaça a configuração do minicom utilizando outro dispositivo e repita os testes.

Um programa que pode ajudar o minicom se chama setserial. Este, pode obter e modificar informações das portas seriais. O seguinte comando é um exemplo que obtem informações básicas sobre algumas delas:

# setserial -g -a /dev/ttyS0 /dev/ttyS1 /dev/ttyS2 /dev/ttyS3

Uma saída típica do setserial pode ser:

/dev/ttyS0, Line 0, UART: unknown, Port: 0x03f8, IRQ: 4
Baud_base: 115200, close_delay: 50, divisor: 0
closing_wait: 3000
Flags: spd_normal skip_test auto_irq

/dev/ttyS1, Line 1, UART: unknown, Port: 0x02f8, IRQ: 3
Baud_base: 115200, close_delay: 50, divisor: 0
closing_wait: 3000
Flags: spd_normal skip_test auto_irq

/dev/ttyS2, Line 2, UART: unknown, Port: 0x03e8, IRQ: 4
Baud_base: 115200, close_delay: 50, divisor: 0
closing_wait: 3000
Flags: spd_normal skip_test auto_irq

/dev/ttyS3, Line 3, UART: unknown, Port: 0x02e8, IRQ: 3
Baud_base: 115200, close_delay: 50, divisor: 0
closing_wait: 3000
Flags: spd_normal auto_irq

5- Conclusões

Frequentemente se verifica a fabricação de equipamentos USB que funcionam apenas em sistemas proprietários Esta é uma das razões que prejudica a disseminação do Linux.

Particularmente, alguns fabricantes de equipamentos 3G como a Huawei, preocupam-se com sistemas operacionais livres. A Sony Ericsson infelizmente não faz parte desse grupo.

É possível contudo, combater esse desrespeito a usuários Linux através da devida modificação do sistema. E na maioria dos casos, isso se resume a escrever uma regra udev, configurar e utilizar devidamente o wvdial.

Contato

Marcio Barbado Jr. é empresário e ativista do Software Livre, sendo um dos proprietários da BDS Labs, em
http://www.bdslabs.com.br

Marcio possui larga experiência em programação, projeto e integração de sistemas.

E-mail para contato: contato@bdslabs.com.br

6- Referências

[1] LINUX MAGAZINE #63 (FEVEREIRO de 2010) – Pergunte ao Klaus
http://www.linuxmagazine.com.br/article/pergunte_ao_klaus_lm63
Visitado em 16/04/2010

[2] Entendendo o udev – Carlos E. Morimoto
http://www.guiadohardware.net/tutoriais/acessando-dispositivos-usb-escrevendo-regras/entendendo-udev.html
Visitado em 16/04/2010

[3] WvDial | freshmeat.net
http://freshmeat.net/projects/wvdial/
Visitado em 16/04/2010

[4] páginas man (manuais de utilização) wvdial e wvdial.conf

[5] Modem-HOWTO — 18. Troubleshooting
http://tldp.org/HOWTO/Modem-HOWTO-18.html
Visitado em 16/04/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.

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.

Plano Nacional de Banda Larga: primeiras ideias

19 de fevereiro de 2010

Hilton Garcia Fernandes

No Brasil, o serviço de acesso à Internet com banda larga não é dos melhores do mundo. Comparado com países similares em desenvolvimento econômico, a banda larga brasileira é mais cara, mais sujeita a falhas e até mesmo tem menor capacidade média do que aquela destes países [1]. Comparações com países europeus ou asiáticos são ainda mais desfavoráveis [2].

A inferioridade brasileira se torna assombrosa à medida que aumenta a distância do eixo Rio-São Paulo [3].

Hoje é fato bem conhecido que a Internet é fator de desenvolvimento econômico e pessoal [4]. Ao ponto de que alguns pesquisadores associam muito fortemente a exclusão digital (dificuldade de usar computadores e Internet) com a exclusão social, a dificuldade de ter acesso ao mercado de trabalho e consumo [5].

Por isso, o Plano Nacional de Banda Larga, ou PNBL [6], é tão importante. Ele é uma iniciativa ampla para reduzir tanto nossa inferioridade (comparada à de outros países), como para reduzir disparidades regionais. Além de sua importância por si, o PNBL interfere em vários pontos do atual modelo de banda larga, o que gera um número infindável de polêmicas [7], sobre o modelo de negócios a ser adotado.

Diante das polêmicas e da importância para o futuro do país, o PNBL merece toda a atenção. Por esta razão, iniciamos com este uma série de entradas, ou posts, no blog Tecnologias sem Fio, para cobrir aspectos relevantes do PNBL.

Como a proposta do PNBL está sendo esperada para o início de março [6], vale aguardar sua formalização e iniciar a sequência pelo lado técnico, o que vai permitir a uniformização dos termos, uma vez que vários dos termos adotados na atual discussão têm significado pouco padronizado, havendo quem os interprete de forma diferente daquela que tem sido usada nas discussões sobre o PNBL.

Em primeiro lugar, vale a pena definir os termos backbone, backhaul e last-mile, pois são chave no desenho das propostas em discussão. Uma forma intuitiva é fazer analogia entre a distribuição de Internet e a distribuição de água tratada. Há grandes adutoras que levam a água de represas, como a Billings a pontos distantes delas. Essas adutoras são tão grandes que sua instalação tende a ser anunciada na imprensa [8].

Para distribuir água até a casa das pessoas, é feita a derivação de adutoras menores. Quem quer que tenha observado escavações nas ruas, terá visto que há adutoras de tamanhos inferiores, que levam a água a prédios. Por sua vez, nos prédios, os canos sofrem outro estreitamento, então chegam à casa das pessoas.

Em termos de terminologia de distribuição de Internet, as grandes adutoras poderiam ser chamadas de core network (ou rede principal), ou backbone [9]. As tubulações que passam pela rua são chamadas de edge network [10], ou “rede periférica”. O movimento de informações que é feito nela é chamado de backhaul [10]. E, por último, os canos mais finos que levam a água até a casa das pessoas são chamados de last mile [11].

Estes são termos muito mais práticos do que teóricos e sua definição não é unânime. Por exemplo, Há quem os defina igualando backhaul à movimentação de dados no backbone [12].

Tanto o backbone quanto as edge networks costumavam ser de uma única companhia. Estes são pontos que o PNBL está tentando mudar, em prol de uma maior concorrência na distribuição de Internet, o que, espera-se, deve diminuir os custos e aumentar a qualidade da Internet brasileira.

No próximo post, ou entrada, do blog Tecnologias sem Fio, será feito um maior detalhamento dos modelos de negócios que a discussão do PNBL está fazendo surgir. E, pari passu [13], será mais detalhado o modelo conceitual, ou a arquitetura, da rede mundial de computadores, a Internet.

Referências


[1] Banda Larga: Brasil perde vez na América Latina

Visitado em 19/02/2009


[2] Banda larga no Brasil é 35ª em ranking com 45 países

Visitado em 19/02/2009


[3] O custo da banda larga

Visitado em 19/02/2009


[4] Federal Communications Commission FCC 09-93 Before the Federal Communications Commission Washington, D.C. 20554 In the Matter of Preserving the Open Internet Broadband Industry Practices

Visitado em 19/02/2009


[5] SILVEIRA, Sérgio Amadeu da. Inclusão digital, software livre e globalização contra-hegemônica.

Visitado em 19/02/2009


[6] Telebrás, Eletronet e PNBL (162) – “Reunião do PNBL”: Análise de Clóvis Marques

Visitado em 19/02/2009


[7] Telebrás, Eletronet e PNBL (170) – Ainda a “Reunião do PNBL” + O “Anãozinho” + Resumo sobre o FUST + A Lei do FUST (íntegra)

Visitado em 19/02/2009


[8] ADUTORAS

Visitado em 19/02/2009


[9] Internet backbone

Visitado em 19/02/2009


[10] Backhaul (telecommunications)

Visitado em 19/02/2009


[11] Last mile

Visitado em 19/02/2009


[12] Appendix 7: Glossary | Report on Commerce Commission’s Local Loop and Fixed PDN Unbundling Investigation

Visitado em 19/02/2009


[13] Pari passu

Visitado em 19/02/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.

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