Processing?

Processing é uma linguagem de programação de código aberto e um ambiente de desenvolvimento integrado (IDE), construído para as artes eletrônicas e comunidades de design visual com o objetivo de ensinar noções básicas de programação de computador em um contexto visual e para servir como base para protótipos eletrônicos. O projeto foi iniciado em 2001 por Casey Reas e Ben Fry, ambos ex-membros do Grupo de Computação do MIT Media Lab. Um dos objetivos declarados do Processing é atuar como uma ferramenta para não-programadores, através da satisfação imediata de um retorno visual. Processing baseia-se na linguagem de programação Java, mas utiliza uma sintaxe simplificada e um padrão de programação baseado em gráficos.

Ambiente

O ambiente utilizado neste tutorial é Windows 7, NetBeans 7.1, JDK 1.6.0_30 e Processing 1.5.1.

Iniciando

Considerando que o NetBeans e o JDK já estejam instalados, é necessário ir no site do Processing e realizar o download da versão sem o JDK –  http://processing.org/download/. Após baixar o arquivo processing-1.5.1-windows-expert.zip, descompacte-o e mova a pasta processing-1.5.1 para dentro de C:\Arquivos de Programas.

Neste primeiro contato o Processing já está pronto para trabalhar, agora é só configurar o NetBeans.

Agora no Netbeans

Para continuar abra o NetBeans e clique em Projetos -> Bibliotecas.

Na tela de Bibliotecas, clique em Nova Biblioteca…

Em Nova Biblioteca, digite Processing 1.5.1 em Nome da biblioteca e clique em OK.

Após confirmar, clique em Adicionar JAR/pasta… Será exibida uma tela para localização dos arquivos. Procure C:\Arquivos de Programas\processing-1.5.1\lib, selecione os arquivos e clique em Adicionar JAR/pasta.

Será exibida a tela com as informações da nova biblioteca.

Neste momento a biblioteca está configurada e pronta para ser adicionada ao projeto.

Novo Projeto

Agora será necessário iniciar um novo projeto. Clique em Arquivo -> Novo Projeto. Na tela de Novo Projeto, selecione em Categorias: Java e Projetos: Aplicativo Java.

Na tela de Novo Aplicativo Java, insira o nome do projeto: TestProcessing, verifique as demais opções selecionadas e clique em Finalizar.

Após o novo projeto carregado, abra a árvore do projeto, clique em Bibliotecas, depois em Adicionar biblioteca…

Na tela de adicionar biblioteca, clique em Importar.

Selecione a biblioteca que foi criada (Processing 1.5.1) e clique em Importar biblioteca.

Novamente de volta a de Adicionar biblioteca selecione Processing 1.5.1 e clique em Adicionar biblioteca.

Os arquivos JAR do Processing serão adicionados ao projeto, assim será possível realizar a importação das bibliotecas.

Foi testado o seguinte código:

package testprocessing;
 
import processing.core.PApplet;
 
/**
*
* @author Eduardo Folly
*/
public class TestProcessing extends PApplet {
 
    /*
     *
     */
    @Override
    public void setup() {
        size(640, 480);
    }
 
   /*
    *
    */
    @Override
    public void draw() {
        background(0);
        rectMode(CENTER);
        fill(0xFFFFAA99);
        rect(mouseX, mouseY, 100, 100);
    }
 
    /**
     * @param args the command line arguments
     */
    public static void main(String[] args) {
        PApplet.main(new String[] { "testprocessing.TestProcessing" });
    }
}

E o resultado obtido foi a aplicação rodando perfeitamente.

Melhorias futuras e possíveis questões

• Somente o código fonte do exemplo foi testado, é necessário testar com outros exemplos que utilizem bibliotecas específicas.
  
• Devido ao Processing ser multi-plataforma, assim como o NetBeans, testar esta configuração em outros sistemas operacionais é imprescindível.

De acordo com a W3C, web service é um software projetado para suportar interação máquina-máquina de forma interoperável através de uma rede. Ele tem uma interface descrita em um formato máquina-processável (especificamente WSDL). Sistemas que interagem com o web service de uma maneira prescrita por sua descrição, utilizam mensagens SOAP, normalmente transmitidas através de HTTP com uma serialização XML em conjunto com outros padrões web.

O caminho.

Para a integração com outros sistemas, o ERP Protheus da Totvs provê uma série de web services e ainda existe a possibilidade de desenvolver e publicar serviços customizados dentro da plataforma.

Figura 1 – Página com a descrição dos serviços disponíveis do Protheus.

O problema.

Ao iniciar o desenvolvimento de uma aplicação em Java 6, utilizando o Netbeans 7.0 como IDE e a biblioteca JAX-WS para o consumo dos serviços, foi exibida a mensagem “WEBSERVICE ERROR : Soap Prefix Missing : USERPORTAL : PRTLOGIN : Formato do Pacote Soap DESCONHECIDO.” ao tentar executar uma chamada simples ao serviço USERPORTAL, método PRTLOGIN.

 

A solução.

Será demostrado um passo-a-passo de como iniciar um projeto até o consumo com sucesso do web service especificado.

No Netbeans, clique no menu Arquivo, seguido por Novo Projeto. Na tela que irá abrir, selecione em Categorias: “Java” e em Projetos: “Aplicativo Java”. Clique em Próximo.

Figura 2 – Novo projeto.

Informe o nome do projeto (neste caso SigaWS), faça modificações caso ache necessário e clique em Finalizar.

Figura 3 – Novo Aplicativo Java

Com o projeto criado, deverá ser criada a classe para consumo do serviço USERPORTAL, para isto clique em Arquivo, seguido por Novo Arquivo.

Figura 4 – Arquivo, Novo Arquivo.

Na tela de Novo Arquivo selecione em Categorias: “Serviços Web” e em Tipos de arquivos: “Cliente para serviço Web”, clicando em Próximo.

Figura 5 – Novo arquivo.

Na próxima tela deverá ser selecionada a opção WSDL URL e informado o caminho do arquivo de definição do serviço de acordo com o publicado no Protheus. Clique em Finalizar.

Figura 6 – Novo cliente para serviço Web.

Voltando para a tela principal do Netbeans, vá na aba Projetos e abra os nós de Referência de serviços Web até localizar o método PRTLOGIN.

Selecione o nó PRTLOGIN, arraste-o e solte dentro da classe SigaWS, isto fará com que o código de chamada ao método seja gerado automaticamente. Em seguida defina os parâmetros para execução da chamada do serviço.

Figura 7 – Definição da classe de execução do Web Service.

Executando o projeto neste momento, será verificado o erro citado no início do artigo.

Figura 8 – Erro na execução.

Para solucionar o problema, o proposto é adicionar um manipulador de mensagem SOAP e realizar algumas modificações nos dados retornados pelo serviço, assim possibilitando a serialização.

Clique em Arquivo, seguido por Novo Arquivo. Na tela seguinte, selecione em Categorias: “Serviços Web” e em Tipos de arquivos: “Manipulador de mensagens”, clique em Próximo.

Figura 9 – Novo arquivo – Manipulador de mensagens.

Informe o nome para o arquivo, neste caso SigaHandler, clique em Finalizar.

Figura 10 – Novo manipulador de mensagens.

Com o arquivo gerado o código deverá ficar desta forma:

package sigaws.ws;
 
import java.io.ByteArrayOutputStream;
import java.util.Collections;
import java.util.Set;
import javax.xml.namespace.QName;
import javax.xml.soap.SOAPException;
import javax.xml.soap.SOAPMessage;
import javax.xml.transform.Source;
import javax.xml.transform.stream.StreamSource;
import javax.xml.ws.handler.MessageContext;
import javax.xml.ws.handler.soap.SOAPHandler;
import javax.xml.ws.handler.soap.SOAPMessageContext;
 
/**
 *
 * @author Eduardo Folly
 */
public class SigaHandler implements SOAPHandler {
 
    @Override
    public boolean handleMessage(SOAPMessageContext messageContext) {
        boolean outbound = (Boolean) messageContext.get(MessageContext.MESSAGE_OUTBOUND_PROPERTY);
 
        if (outbound) {
            try {
                SOAPMessage msg = messageContext.getMessage();
 
                ByteArrayOutputStream baos = new ByteArrayOutputStream();
                msg.writeTo(baos);
                String teste = baos.toString(getMessageEncoding(msg));
                teste = teste.replaceAll("S:", "soap:");
                teste = teste.replaceAll("S=", "soap=");
 
                Source src = new StreamSource(new java.io.StringReader(teste));
                msg.getSOAPPart().setContent(src);
            } catch (Exception e) {
                e.printStackTrace();
            }
        }
        return true;
    }
 
    @Override
    public Set getHeaders() {
        return Collections.EMPTY_SET;
    }
 
    @Override
    public boolean handleFault(SOAPMessageContext messageContext) {
        return true;
    }
 
    @Override
    public void close(MessageContext context) {
    }
 
    private String getMessageEncoding(SOAPMessage msg) throws SOAPException {
        String encoding = "utf-8";
        if (msg.getProperty(SOAPMessage.CHARACTER_SET_ENCODING) != null) {
            encoding = msg.getProperty(SOAPMessage.CHARACTER_SET_ENCODING).toString();
        }
        return encoding;
    }
}

Assim o resultado final da classe é apresentado.

Figura 11 – Classe SigaHandler.

Agora é necessário relacionar o manipulador de mensagens com o serviço USERPORTAL. Para isto na aba Projetos clique com o botão direito do mouse no serviço USERPORTAL, seguido por Configurar manipuladores…

Figura 12 – Configurar manipuladores…

Na próxima tela, clique em Adicionar.

Figura 13 – Configurar os manipuladores de mensagens.

Selecione o arquivo manipulador, neste caso o arquivo SigaHandler.java, e clique em OK.

Figura 14 – Selecionar classe de manipuladores de mensagens.

Após a confirmação será exibido o manipulador de mensagens associado ao serviço. Clique em OK.

Figura 15 – Associação do manipulador de mensagens.

Desta forma a execução do programa funciona perfeitamente.

Figura 16 – Execução do programa.

Considerações finais.

Até o presente momento a Totvs não disponibilizou uma modificação no padrão do retorno da mensagem do serviço Web para o Protheus 10.

Gostaria de agradecer a Vicente de Paula (vicenterecife@gmail.com) por ter originado os questionamentos que deram origem a este artigo.

Desta forma surge o primeiro inimigo da formatação: o DISPOSITIVO DESCONHECIDO.

Mesmo depois do advento do plug and play e Windows Update alguns dispositivos acabam sendo esquecidos e quando vamos atualizar o sistema operacional eles aparecem de forma alienígena.

Exemplificando, podemos ver na imagem abaixo um dispositivo denominado Co-processador não sendo reconhecido pelo Windows 7 64-bit, então o que fazer?

Co-processador desconhecido.

Selecionando o Co-processador, em Outros dispositivos, podemos ver que o sistema não conseguiu instalar os drivers para o dispositivo.

Iniciando o processo de descoberta do software é necessário acessar as propriedades do dispositivo.

Driver não instalado.

Após abrir a tela de propriedades, clica-se na aba de Detalhes e seleciona a Propriedade IDs de Hardware.

Detalhes do dispositivo.

Nesta janela é apresentada toda a solução do problema na linha selecionada.

PCI\VEN_10DE&DEV_0543&SUBSYS_01271025&REV_A2

A partir desta string podemos identificar o código do fabricante (VEN_10DE) e do dispositivo (DEV_0543).

De posse destas informações o Google nos ajuda a resolver o problema. Então é só localizar um driver escrito para o seu sistema operacional, neste caso, Windows 7 64-bit.

Resultado da busca no Google

Após a localização do driver, basta voltar até a aba geral da tela de propriedades do dispositivo e clicar no botão Atualizar Driver.

Na tela de atualização do driver deve-se selecionar Procurar software de driver no computador, como mostrado na imagem abaixo.

Modo de instalação do driver.

Informe a localização dos arquivos baixados na caixa de texto referente a Procurar software de driver neste local.

Selecionar localização do driver.

Estando o driver correto, o Windows consegue instalar o Co-processador sem problemas, agora conhecido como NVIDIA nForce System Management Controller.

Dispositivo reconhecido e instalado.

Concluido o processo de instalção retorna-se para a janela de propriedades do dispositivo e nela já é exibida a mensagem que “Este dispositivos está funcionando corretamente.”.

Dispositivo funcionando corretamente.

No Gerenciador de Dispositivos é verificado que não existe mais dispositivos desconhecidos.

Nenhum dispositivo desconhecido.

Assim termina a saga da instalação dos Co-processador desconhecido no Windows 7 64-bit, mas fica uma excelente dica de como identificar e instalar dispositivos que não possuem drivers listados nos sites dos seus fabricantes.

Este post tem como objetivo principal realizar a apresentação do padrão para redes sem fio com múltiplos saltos proposto pelo IEEE 802.11s. Este padrão propõe uma solução de encaminhamento através de múltiplos saltos no nível de enlace, assim diferenciando-o das soluções tradicionais que operam no nível de rede. Inicialmente serão abordados os principais conceitos de redes locais IEEE 802.3, redes locais sem fio que seguem o padrão IEEE 802.11 e a junção destes padrões na infraestrutura. Apresentar brevemente a solução para comunicação em múltiplos saltos no nível MAC e projetos piloto que implementam este tipo de comunicação.

Apresentação

Redes locais sem fio (WLANs – Wireless Local Area Networks) que seguem o padrão IEEE 80211, estão bem difundidas devido a fatores como a facilidade de instalação e suporte a mobilidade. Mesmo assim, apesar dos padrões IEEE 80211a, b e g serem populares e encontrados na maioria dos notebooks e em grande parte de PDAs, telefones e outros equipamentos sem fio, ainda existe um grande campo de pesquisa e vários desafios em diversas áreas que demandam novas soluções.

Roteadores sem fio de baixo custo também tem sido utilizados na instalação de backbones sem fio. Redes, onde o posicionamento dos roteadores que formam-o é planejado para oferecer uma cobertura de acesso em certas áreas, ou para interconectar redes cabeadas (IEEE 802.3)  distantes, assim são chamadas de redes em malha sem fio (WMNs – Wireless Mesh Networks). Por esta definição, redes em malha sem fio na verdade não são redes sem fio ad-hoc, pois são planejadas e/ou projetadas, mas também podem se beneficiar das vantagens da tecnologia sem fio adjunta a infraestrutura.

Redes móveis ad-hoc (MANETs – Mobile Ad Hoc Networks) são redes auto-configuráveis, compostas por nós móveis sem fio. Em uma MANET, os roteadores podem se mover e a topologia pode mudar rápida e drasticamente. Funções de roteamento são realizadas por alguns ou todos os nós sem fio. Redes em malha e redes ad-hoc sem fio utilizam comunicação em múltiplos saltos e, por isso, compartilham de um mesmo desafio: desenvolver protocolos de roteamento capazes de lidar com características de redes sem fio, tal como mobilidade, mudanças frequentes na qualidade dos enlaces sem fio e contenção no acesso ao meio.

As soluções tradicionais para construção de redes sem fio com múltiplos saltos realizam a decisão de roteamento e encaminhamento das informações transmitidas no nível de rede, possuindo desta forma a vantagem de ser independente da tecnologia de enlace e seguindo o modelo tradicional de arquitetura de rede que coloca a comunicação entre redes como responsabilidade na camada três.Uma outra proposta para esta comunicação é abordada na implementação de técnicas de encaminhamento através de múltiplos saltos no nível de enlace, como uma extensão das funcionalidades das redes locais sem fio e estas implementações estarão disponíveis nos equipamentos dos usuários finais. Além disso, métricas que determinam a qualidade dos enlaces podem ser facilmente controladas pela camada MAC, permitindo uma melhor utilização das redes sem fio.

O grupo de trabalho do IEEE 802.11s [IEEE, 2007] está desenvolvendo um padrão para comunicação através de múltiplos saltos no nível dois. Esta proposta para a construção de redes sem fio faz com que a rede de múltiplos saltos pareça uma única rede local para a terceira camada. O padrão IEEE 802.11s especifica funções de encaminhamento através de múltiplos saltos na camada MAC, utilizando um mecanismo de seleção de caminhos obrigatórios chamado HWMP (Hybrid Wireless Mesh Protocol) e fornece um framework para seleção de caminhos que permite a utilização de caminhos alternativos e futuras extensões. O padrão IEEE 802.11s amplia a definição do sistema de distribuição sem fio original do padrão IEEE 802.11, permitindo que a rede sem fio tenha uma área de cobertura que pode crescer à medida que novos nós se integram à rede adicionando um novo salto.

O Padrão IEEE 802.11

O padrão IEEE 802.11 é parte da família IEEE 802 que abrange padrões aplicados à construção de redes locais (LANs) e redes metropolitanas (MANs) da primeira e segunda. Alguns dos membros desta família são: 802.1 (Gerência de rede), 802.2 (LLC – Logical Link Control), 802.3 (Ethernet), 802.11 (LANs sem fio), 802.15 (Wireless Personal Area Network – onde 802.15.1 define Bluetooth), 802.16 (Boardband Wireless Access – Certificação WiMAX), 802.17 (Resilient Package Ring), 802.20 (Mobile Wireless Access – GSM), 802.21 (Media Independent Handover Services), 802.22 (Wireless Regional Area Network), 802.23 (Emergency Services Working Group – Novo, iniciado em março de 2010).

O IEEE 802.11 é o padrão para montagem de redes sem fio locais (WLANs) e especifica as funções das camadas física (PHY) e de acesso ao meio (MAC – Medium Access Control), contendo uma série de emendas que ampliam ou aperfeiçoam suas capacidades. A Tabela 1.1 sumariza as principais emendas ao padrão existente atualmente.

Um dos objetivos principais do IEEE ao criar o padrão 802.11 foi permitir a interligação da rede sem fio com redes cabeadas que seguem o padrão Ethernet (802.3). A rede sem fio é vista como uma extensão de uma rede cabeada. Esta decisão resulta na necessidade de uma série de mecanismos apropriados para a compatibilização da parte com fio e sem fio de uma rede local. Ao mesmo tempo, com a popularização das redes sem fio, e seu uso cada vez mais intenso, a padronização segue na direção de propostas que aumentem a banda disponível (como as emendas “b”, “a”, “g”, e “n”), tornem a rede mais segura (802.11i), auxiliem a mobilidade (802.11r) e ofereçam qualidade de serviço (802.11e).

IEEE 802.11s

Em meados de Março de 2005 a foi proposto um novo padrão denominado 802.11s para as redes em malha (mesh). Esse padrão estava previsto para ser concluído em setembro de 2010, mas ainda está em ampla discussão. Entretanto a idéia é definir camadas físicas e de acesso ao meio para redes em malha de maneira a aumentar o alcance sem pontos de falha através da técnica de múltiplos saltos.

Inicialmente existiam duas propostas que se destacavam pelo peso de seus integrantes: A Wi-Mesh Alliance, liderada pela Nortel inclui Philips, Thomson e Swisscom Innovations; e a SEEMesh (Simple, Efficient and Extensible Mesh) que inclui Intel, Nokia, Motorola, Cisco, e Texas Instruments, mas que no decorrer do processo se associaram para discutir o padrão.

O Grupo de Trabalho “s” (TGs) tem como objetivo ampliar o padrão para permitir a criação de redes em malha de múltiplos saltos formados por dispositivos 802.11. Este grupo tem como líder Dee Denteneer (Philips), vice-líder Guido Hiertz (Philips), editor técnico Kazuyuki Sakoda (Sony) e secretário: Guenael Strutt (Motorola). Podemos observar o interesse das grandes corporações no desenvolvimento das redes em malha.

Em 12 de setembro de 2010 foi realizado um encontro em Waikoloa, Hawaii, EUA e o status de conclusão do projeto foi atualizado para 95%, mostrando assim que algumas informações precisam ser definidas e ainda não existindo uma data exata para conclusão da padronização.

Dentre as características principais do 802.11s podem ser citados os mecanismos para fornecer acesso determinístico a rede, quadro para controle de congestionamento, economia de energia e baixo custo dos equipamentos para usuários finais.

Protocolos de Roteamento

Formatos dos quadros IEEE 802.11

Uma das características mais impostantes do formato dos quadros do padrão 802.11 é a presença de quatro endereços físicos (ADDR1-4). A rede sem fio foi projetada para ser uma extensão da Ethernet cabeada. Numa rede Ethernet, só são necessários dois endereços de 48 bits para enviar um pacote da origem para o destino. Numa rede sem fio, no entanto, um pacote indo para um destino pode ter que passar por intermediários (como pontos de acesso). Estes intermediários são o destino imediato do pacote, mas não seu destino final. Assim, é necessário identificá-los, bem como identificar o destino final para que o pacote chegue ao mesmo.

Os endereços são numerados em vez de terem um nome porque sua função varia de acordo com tipo do quadro. Geralmente, o endereço 1 (ADDR1) é o destino imediato do pacote (isto é, identifica o receptor), o endereço 2 (ADDR2) identifica o transmissor e o endereço 3 é usado para filtragem no receptor.

Seguindo a convenção dos endereços MAC IEEE 802, se o primeiro bit de um endereço é zero, este é um endereço unicast. Se o bit for um, o endereço é multicast. Se todos os bits do endereço forem iguais a um, é um quadro de broadcast. Cada endereço pode representar o destino, origem, receptor (qual estação deve processar o quadro), transmissor (qual estação enviou aquele quadro) e identifiação do Basic Service Set (BSSID). No caso do BSSID como várias redes locais podem compartilhar a mesma área, este endereço permite identificar em que rede sem fio o quadro é transmitido.

O interior do IEEE 802.11s

A proposta de padrão introduz novos formatos de quadros, trata de questões como segurança e gerenciamento, assim como uma série de otimizações necessárias para a montagem de redes em malha de múltiplos saltos no nível de enlace. Além disso, boa parte de seu conteúdo é dedicada à descrição de protocolos para encaminhamento de quadros na rede em malha.

Originalmente, dois mecanismos de seleção de caminho foram propostos em versões anteriores do draft. RA-OLSR (Radio-Aware Optimized Link State Routing), que é um protocolo pró-ativo com um mecanismo de controle de inundação baseado no OLSR, porém adaptado para trabalhar em nível dois ao invés do três. E um protocolo híbrido, chamado HWMP (Hybrid Wireless Mesh Protocol), baseado no AODV e na sua extensão AODV-ST. O HWMP é atualmente o protocolo obrigatório e o único restante na proposta atual. RA-OLSR foi removido em favor de um framework de seleção de caminhos extensível que possibilita implementações alternativas de protocolos e métricas para seleção de caminhos.

O HWMP pode, portanto, ser configurado para operar em dois modos: modo reativo sob demanda (on-demand reactive mode) ou modo pró-ativo baseado em árvore (tree-based proactive mode). O primeiro, modo de operação sob demanda, é apropriado para estabelecimento de caminhos entre nós mesh (MPs) em um esquema peer-to-peer, ao passo que no segundo, modelo pró-ativo, cada nó calcula antecipadamente uma topologia em árvore onde a raiz é um determinado nó que se anuncia com tal (MP raiz). Esta abordagem pode ser implementada através de dois mecanismos distintos, pode aumentar a eficiência no encaminhamento de quadros quando existe uma tendência de concentração de tráfego no nó raiz, que pode, por exemplo, estar atuando como portal mesh (MPP).

O que faz o HWMP realmente híbrido é o fato de que ambos os modos (pró-ativo e reativo) podem ser usados concomitantemente. A principal vantagem desta abordagem é que, em certas circunstâncias, apesar de disponível de antemão, o caminho entre dois nós em uma topologia em árvore pode não ser o caminho ótimo e, neste momento, a descoberta sob demanda pode ser empregada, fornecendo um caminho alternativo mais apropriado. Um exemplo de tal circunstância é o caso onde dois nós, que não são MP raiz, são capazes de trocar dados através de um caminho de custo mínimo (diretamente por um simples enlace mesh), mas são forçados a fazer com que seus quadros subam e desçam a árvore para alcançar um nó raiz.

Na especificação atual do IEEE 802.11s, a métrica obrigatória para definir a qualidade de um enlace sem fio é a chamada Airtime Link Metric. Ela representa a quantidade de tempo necessária para a transmissão de um quadro levando em consideração a taxa de transmissão, o overhead imposto pela camada física e a probabilidade de retransmissão do quadro (inferida da taxa de erros do enlace em questão). A forma de cálculo desta taxa de erros, no entanto é deixada a cargo da implementação, ou seja, não é descrita pela norma. Nós transmitindo em uma taxa baixa podem usar toda a banda do canal com suas longas transmissões da mesma maneira que um enlace com alta probabilidade de erro pode ocupar o meio por um longo tempo devido às retransmissões.

Durante o processo de descoberta de um caminho (path discovery), cada nó participante irá contribuir com seus cálculos de métrica acrescentando ou atualizando dados nos quadros de gerenciamento dedicados à troca de informações de encaminhamento. Independente do modo de operação (pró-ativo ou reativo) as funções do HWMP são implementadas pelos seguintes quadros de gerenciamento:

Path Request (PREQ) – requisição de caminho – estes quadros são enviados em difusão (broadcast) por um MP que deseja encontrar um caminho para outro MP.

Path Reply (PREP) – resposta de caminho – estes quadros são enviados pelo MP de destino, em resposta ao recebimento de uma requisição de caminho (PREQ).

Path Error (PERR) – erro no caminho – estes quadros são usados para notificação de que um caminho não está mais disponível.

Root Announcement (RANN) – anúncio de nó raiz – estes quadros são utilizados pelo nó que se anuncia como nó raiz (MP raiz). Existem dois mecanismos para implementação do modo pró-ativo no HWMP, sendo o quadro RANN usado em um deles.

Exemplificando um caso, onde um nó designado como origem S-MP deseja encontrar um caminho para um nó de destino D-MP e, para tal, precisará da colaboração dos nós intermediários I-MPs.

O mecanismo opera da seguinte maneira. O nó S-MP envia, por difusão, um quadro PREQ contendo o endereço MAC de D-MP, o nó de destino. Um nó mesh que receba esse quadro deverá checar suas tabelas e verificar se conhece um caminho para D-MP. Em caso afirmativo, deverá enviar um quadro de resposta (PREP) de volta para S-MP. Em caso negativo, o nó mesh intermediário (I-MP) deverá retransmitir o quadro, novamente usando o endereço MAC de difusão (FF:FF:FF:FF:FF:FF).

O nó de origem S-MP, no entanto, pode evitar que nós intermediários respondam à requisição PREQ setando o flag DO (Destination Only – destino apenas) no cabeçalho do quadro PREQ. Neste caso, apenas o nó de destino poderá responder a requisição original emitindo um quadro PREP. Desta forma, ao receber uma requisição (PREQ) onde DO tenha sido ativado, um nó intermediário irá forçosamente retransmitir o quadro PREQ e o processo se repetirá até que a requisição alcance seu destino.

Outro flag RF (Reply and Forward – responda e encaminhe) também pode ser empregado para controlar o comportamento dos nós intermediários. Se RF for setado e DO não, um nó intermediário poderá responder a requisição, isto é, enviar um PREP (contanto, é claro, que conheça um caminho para o nó de destino), mas ainda assim deverá retransmitir o quadro de requisição adiante.

Se, por outro lado, DO e RF estiverem desativados, um nó intermediário está autorizado a responder a requisição, mas uma vez que o faça, não deverá mais retransmitir o quadro PREQ. Observa-se, portanto, que os flags DO e RF determinam a quantidade de respostas (PREPs) recebidas pela origem S-MP.

A cada vez que manipula um quadro PREQ, um nó mesh intermediário aprende um caminho reverso para o nó de origem S-MP. Este poderá ser útil mais tarde para o encaminhamento dos quadros de resposta (PREPs), no caso do nó intermediário em questão participar do caminho selecionado. Justamente por conta da formação deste caminho reverso, os quadros de resposta (PREPs) poderão ser encaminhados em unicast para o nó de origem S-MP.

Os quadros PREQ e PREP carregam um campo de métrica que é incrementado por cada nó intermediário, refletindo os tempos de transmissão de cada enlace no caminho. É através desta métrica que o nó de destino D-MP é capaz de selecionar um caminho reverso dentre os múltiplos caminhos eventualmente existentes (dado um cenário de nuvem densa). Analogamente o nó de origem S-MP poderá escolher entre vários caminhos diretos, caso existam, através da métrica contida nos quadros de resposta, encerrando, desta forma, o ciclo de descoberta de caminho.

No que diz respeito à densidade da nuvem mesh, devemos notar que, em um meio sem fio, grande cobertura e alta taxa de transmissão são objetivos conflitantes, pois estes são inversamente proporcionais. Quadros broadcast e multicast são normalmente transmitidos a baixas taxas para atingir o maior número de nós possíveis. Nós distantes terão maior chance de receber os quadros, se eles foram transmitidos a uma taxa baixa. Por outro lado, esses quadros levarão um maior tempo para se propagar através da nuvem, podendo trazer problemas em um ambiente denso.

Como mencionado anteriormente, além do mecanismo de descoberta de caminho por demanda, o protocolo HWMP provê dois diferentes métodos pró-ativos para construção de tabelas de encaminhamento. O primeiro deles é baseado no emprego de quadros PREQ e por isso chamado de “mecanismo pró-ativo PREQ”. O segundo utiliza um quadro especial, chamado RANN e, da mesma forma, fica designado como “mecanismo pró-ativo RANN”.

No mecanismo baseado em PREQs, uma vez configurado para operar como MP raiz, um nó mesh difunde periodicamente um quadro PREQ com os flags DO e RF ativados, o que configura um quadro “PREQ pró-ativo”. Cada nó que receba este quadro irá atualizar seu cabeçalho com os valores de métrica e contagem de saltos e retransmiti-lo. Com o tempo, todos os nós da nuvem mesh serão notificados.

Ao receber um PREQ pró-ativo um nó responde ou não com um PREP em função do valor de um terceiro flag no cabeçalho do quadro de requisição. Se setado, este flag chamado PREP pró ativo (Proactive PREP) faz com que os nós enviem um PREP de volta ao nó raiz. Na verdade, mesmo que PREP pró-ativo esteja desativado, um nó pode responder ao nó raiz com um PREP se desejar estabelecer um caminho no esquema peer-to-peer com o nó raiz. Por exemplo, ele pode ter dados para enviar ao nó raiz.

No segundo mecanismo pró-ativo previsto pelo IEEE 802.11s, ao invés de utilizar quadros PREQs o nó raiz inunda a nuvem mesh com quadros RANN. Neste caso, os nós que eventualmente desejem formar caminhos para o nó raiz enviam, para este, um quadro PREQ.

Desta vez, a requisição PREQ será enviada em unicast, mas será processada pelos nós intermediários através das mesmas regras aplicadas aos quadros PREQ difundidos pelo mecanismo reativo do protocolo. O nó raiz, ao receber a requisição responderá com o respectivo quadro PREP, estabelecendo assim, um caminho entre o nó requisitante e o nó raiz. Por fim, o mecanismo RANN introduz um passo adicional e pode ser vantajoso se comparado com o mecanismo PREQ apenas se uma pequena porção dos MPs deseja estabelecer caminhos com o nó raiz.

Finalmente, é importante comentar o papel do quadro PERR dentro do esquema recém descrito. Sempre que um quadro não puder ser encaminhado por um nó pertencente ao caminho, este deverá notificar o remetente sobre a quebra do enlace e, consequente inviabilidade daquele caminho. Esta informação deverá ser encaminhada de volta a todos os participantes anteriores alcançando finalmente o remetente original que, assim, deverá iniciar um novo ciclo de descoberta de caminho.

Formatos dos quadros 802.11s

Inicialmente, recordamos que os dois primeiros bytes de um quadro 802.11 contêm o chamado campo de controle do quadro (frame control field), sendo que dois bits deste campo (o terceiro e o quarto) identificam o tipo de quadro.

Além do campo tipo, outros quatro bits são reservados para definir subtipos dentro de uma categoria. Assim, um beacon, por exemplo, é definido como tipo gerenciamento (0×0) e subtipo beacon (0×8), ao passo que um ACK (acknowledgement) pertence ao tipo controle (0×1) e subtipo (0xD). Por se tratar de uma extensão ao padrão IEEE 802.11, os quadros mesh introduzidos pelo 802.11s devem ser classificados dentro dos quatro tipos existentes. Inicialmente, pretendia-se utilizar o tipo reservado, ainda disponível (0×3), mas em versões mais recentes da proposta definiu-se que:

Os dados trocados por MPs são transportados por quadros de dados mesh (Mesh Data Frames), definidos como quadros de dados (tipo 0×2) com um cabeçalho mesh pré-posto ao corpo do quadro 802.11.

Quadros de gerência da rede mesh, como por exemplo os quadros PREQ, PREP, etc, são definidos como pertencentes ao tipo 0×0 (management frames) e subtipo 0xF, até então reservado. Estes quadros foram batizados como Multihop Action frames.

Outra característica dos novos quadros é a utilização dos flags FromDS e ToDS. Estes bits são utilizados, em uma rede IEEE 802.11, para marcar pacotes que sejam destinados a um sistema de distribuição (ToDS) ou sejam oriundos deste (FromDS). O sistema de distribuição, em uma rede sem fio, é a infra-estrutura que pode interligar diversos pontos de acesso ou mesmo conectar a rede sem fio à Internet. Assim, por exemplo, um quadro oriundo de uma estação IEEE 802.11 em modo infra-estrutura que seja destinado a outra estação IEEE 802.11 tem os flags FromDS = 0 e ToDS = 1. Um sistema de distribuição sem fio (Wireless Distribution System), ou WDS, é aquele em que diversos pontos de acesso permitem a troca de dados entre estações a eles associadas através de quadros IEEE 802.11, ou seja, por intermédio de um backbone sem fio, e não através de quadros IEEE 802.3 como em uma rede cabeada. Chama-se de quadro WDS aquele que possui ambos os flags fromDS e ToDS setados. Sua função original é, portanto, a de permitir a troca de dados entre estações associadas a diferentes pontos de acesso dentro de uma mesma rede local sem fio. O que o IEEE 802.11s propõe é que quadros trocados pelos MPs em um nuvem mesh sejam também marcados com ambos esses flags.

Como não foi padronizada, diversas implementações proprietárias e não documentadas de WDS podem ser encontradas em modelos variados de pontos de acesso, algumas potencialmente conflitantes com o padrão emergente. Isso aponta para um futuro de ajustes não apenas na proposta do IEEE 802.11s, mas destas implementações, de forma a evitar problemas de compatibilidade.

É oportuno observar que em uma rede IEEE 802.11 no modo ad-hoc, cada quadro traz ambos os flags (FromDS e ToDS) desmarcados (zerados). Isto evidencia uma importante diferença. Uma rede ad-hoc IEEE 802.11 é aquela em que conexões oportunistas podem ser formadas entre estações IEEE 802.11, mas onde não há múltiplos saltos ou, em outras palavras, encaminhamentos de quadros, e não deve ser confundida com uma rede mesh.Os primeiros dois bits determinam a quantidade de endereços MAC presentes no último campo, Mesh Address Extension, o que pode variar entre 0 e 3, indicando um campo de 0, 6, 12 ou 18 bytes, onde cada endereço possui 6 bytes.

O campo Mesh TTL indica a quantidade máxima de saltos que um quadro poderá realizar na nuvem mesh e é decrementado por cada nó que retransmitir o quadro. Seu objetivo é evitar que quadros sejam eternamente retransmitidos na nuvem por conta de algum loop de encaminhamento.

O número de sequência mesh (Mesh Sequence Number) é um identificador do quadro que permite a uma estação detectar o recebimento de duplicatas prevenindo retransmissões desnecessárias dentro da nuvem mesh. E, finalmente, o já mencionado campo Mesh Address Extension que carrega endereços MAC extras, já que a rede mesh pode precisar de até seis endereços.

Conectividade de STAs e Endereçamento de Quadros

De acordo com o IEEE 802.11s, nós não-mesh (STAs) podem participar da rede mesh através de um nó mesh (MP) com capacidades de ponto de acesso (nós MAP). STAs se comunicando pela nuvem mesh são intermediados pelos seus respectivos MAPs e este cenário constitui um exemplo de como é usado o formato de quadro com seis endereços.

O formato de quadro IEEE 802.11 usual, com quatro endereços, pode ser usado tanto para transmissão de dados como para quadros de controle. Os quatro endereços MAC nesse caso são:

• SA (Source Address) é o endereço MAC da fonte do quadro, ou seja, o nó que gerou o quadro original.
• DA (Destination Address) é o endereço MAC do nó que é o destino final do quadro.
• TA (Transmitter Address) é o endereço MAC do nó que transmite um quadro. Será igual à SA quando o quadro for originado e transmitido pela primeira vez. Será diferente de SA toda vez que for transmitido por um nó intermediário.
• RA (Receiver Address) é o endereço MAC do próximo nó que irá receber o quadro e pode ser o mesmo que DA quando o quadro está para alcançar seu destino final.

Em resumo, SA e DA estão associados aos nós extremos em um caminho completo pela nuvem mesh, ao passo que TA e RA estão associados aos nós participantes de uma transmissão em um enlace. Mas, quadros com quatro endereços, utilizados no padrão IEEE 802.11 original para transmissão usando um sistema de distribuição sem fio, não são suficientes para implementar todas as funcionalidades propostas pela emenda “s”.

Como exemplificado, se dois nós não-mesh estão se comunicando através da nuvem mesh, dois endereços adicionais são necessários – o Mesh SA (Mesh Source Address) e o Mesh DA (Mesh Destination Address). Para entendê-los, as entidades DA e SA são definidas de uma forma mais geral:

• Mesh SA – Em um quadro de seis endereços, o SA (Source Address) é o nó originador da comunicação fim-a-fim e esta fora da nuvem mesh, enquanto o Mesh SA é o endereço do nó que introduz o quadro na nuvem mesh (em nome de SA).
• Mesh DA – Da mesma forma, DA (Destination Address) define o endereço final do quadro, ao passo que Mesh DA é o endereço da última estação que recebe o quadro na nuvem (e faz isso em nome de DA).

Um outro caso onde o formato com seis endereços é usado é no modo pró-ativo do HWMP, baseado em árvore, onde dois nós conseguem se comunicar através de um MP raiz. Neste cenário, o caminho completo inclui dois sub-caminhos – um do MP fonte até o MP raiz e outro deste até o MP de destino. Finalmente, MPs conseguem também se comunicar com o “mundo exterior” através de portais mesh (MPPs). Em todos esses casos, mais de quatro endereços são necessários.

Características Adicionais

O Padrão IEEE 802.11s cobre muito mais itens do que podemos analisar nesta oportunidade. Foram apresentados os pontos mais importantes para o entendimento do funcionamento de uma rede mesh, mas ainda existem muitos outros aspectos interessantes para serem abordados.

O IEEE 802.11s introduz um método de acesso ao meio chamado MDA (Mesh Deterministic Access), que ajuda a reduzir a contenção com o uso de uma nova função de coordenação. O mecanismo é opcional e pode ser implementado por um sub-grupo de MPs presentes na nuvem mesh. Como conseqüência, MPs com o MDA ativado devem ser capazes de interoperar com MPs com o MDA desativado, mesmo que isso prejudique a eficácia do esquema.

A idéia central do MDA é introdução de períodos de tempo, chamados MDAOPs (MDA Opportunities), período pelo qual o nó com o MDA ativado tem a oportunidade de acessar o meio com o mínimo de contenção, pode ainda haver contenção devido a presença de nós com o MDA desativado. O MDA é implementado através da ação de cinco novos quadros: MDA Setup Request, MDA Setup Reply, MDAOP Advertisement Request, MDAOP Advertisements, MDAOP Set Teardown.

Controle de congestionamento é brevemente citado na proposta do padrão. Um mecanismo de controle de congestionamento deve ser selecionado para toda a rede e também será anunciado pelo elemento de configuração mesh, junto com o protocolo de seleção de caminho e métrica. O draft descreve o formato do quadro de notificação de congestionamento (Congestion Control Notification) enviado pelo MP para seu MP par (ou MPs) a fim de indicar seu status de congestionamento. Contudo, detalhes sobre como o congestionamento é detectado ou o que provoca a notificação de congestionamento são considerados além do escopo do futuro padrão.

Economia de energia, por outro lado, recebe maior atenção no draft. A idéia principal é que alguns nós escolhidos, chamados de Power Save Supporting MPs, irão armazenar quadros de outros nós, chamados de Power Saving MPs, e os transmitir apenas em tempos negociados. Este é um serviço similar ao que um ponto de acesso deve prover aos nós que estão associados a ele nas redes IEEE 802.11.

Em termos de segurança, IEEE 802.11s descreve mecanismos que provêem tanto autenticação e privacidade. A segurança é baseada no mecanismo MSA (Mesh Security Association), que garante segurança no enlace entre dois MPs e pode operar mesmo que não exista nenhum autenticador central, isto é, existe suporte para autenticação distribuída.

Uma vez configurado para oferecer segurança, um MP só deve estabelecer peer links seguros com outros MPs e renegociar peer links pré-existentes que ainda sejam inseguros. O estabelecimento de um peer link envolve a troca de quadros extras (como um four-way handshake) que começa imediatamente após a troca inicial de quadros Peer Link Open e Peer Link Confirm.

Case: Projeto One Laptop per Child (OLPC)

O projeto One Laptop per Child é realizado pela One Laptop per Child Association, fundada por Nicholas Negroponte. O objetivo do projeto é criar um laptop educacional de baixíssimo custo para a inclusão digital das crianças de escolas pelo mundo.

A missão do projeto, conforme descrita no site do projeto, é “criar oportunidades educacionais para as crianças mais pobres do mundo provendo cada criança com um laptop robusto, com baixo custo, baixo consumo de energia, e conectado, com conteúdo colaborativo, que seja prazeroso e auto-explicativo”.

O subsistema de rádio do XO é composto por um chip controlador Marvell 88W8388, que contém um processador ARM9 e memórias RAM e ROM, e um rádio Marvell 88W8015, com interface IEEE 802.11b/g. O sistema de rádio está conectado à CPU principal através de um barramento USB (Universal Serial Bus) e continua sendo alimentado de energia mesmo que a CPU principal não esteja. O processamento de quadros MAC é realizado pelo controlador Marvell 8838 e não utiliza a CPU principal, necessária apenas para o processamento de informações de nível de rede e camadas superiores.

A segregação do subsistema de rádio traz uma vantagem interessante decorrente do fato deste poder operar ainda que a CPU principal se encontre em modo inativo. A possibilidade do SoC implementado pelo Marvell 8838 processar quadros IEEE 802.11 sem a necessidade de intervenção da CPU principal permite que um XO opere como nó intermediário de uma nuvem mesh ainda que esteja desligado e com um consumo da ordem de apenas 0,5 watt.

A CPU principal é solicitada apenas no processamento de pacotes IP. Portanto, é importante salientar que a implementação do IEEE 802.11s reside no subsistema de rádio e, com isso, um laptop XO pode participar ativamente da rede mesh e encaminhar quadros de outros nós da rede mesmo sem o uso da CPU principal ou de uma pilha de protocolos TCP/IP.

Dessa maneira, é possível obter uma rede mesh para fornecer conexões aos laptops XO com um custo extremamente baixo, já que não há necessidade de pontos fixos de antenas para o estabelecimento dos nós, bastando um ponto de conexão com a internet para que salas de aula estejam conectadas.

Conclusão

As redes em malha sem fio, ou redes mesh, possuem a grande vantagem do baixo custo de implementação e manutenção, pois uma vez configurada, novos nós são incorporados à malha através dos protocolos de roteamento, sem a necessidade de configuração por parte dos administradores da rede.

Além de projetos como o OLPC, onde as redes mesh tornam possíveis a criação de uma infraestrutura onde antes isso não era pensado devido ao custo de implementação, as redes em malha podem ser utilizadas para baratear custos, utilizando a rede criada como rota alternativa quando existente. É só imaginarmos os celulares criando uma malha utilizando o 802.11s, e quando na área de uma rede mesh, utilizando-a para trafegar os dados ao invés de redes com custo mais elevado, como redes 3G.

Com a aprovação do padrão 802.11s, novos dispositivos utilizarão o grupo, permitindo então a expansão de uma excelente tecnologia a um custo baixo para o estabelecimento de redes em instituições de ensino, condomínios e outras localidades.

O corretor ortográfico é “estilo Word” com a linha sublinhada e tudo mais, também faz a inclusão de imagens sem problemas no estilo “drag-n-drop”.

Só falta testar mesmo o envio para o WordPress, se você conseguir ler isso é porque funcionou.

Ele buscou as categorias já definidas no blog, deixa escolher a data de publicação e as “marcas” (aka keywords) também. O corretor ortográfico existe mas não é automático como no Word (aquelas cobrinhas podem sem um bocado chatas mesmo!). Existe um preview que utiliza inclusive o tema fazendo aquela “velha” expressão WYSWYG ser mais verdadeira do que nunca. Finalmente para os puristas o “código-fonte” em html também está numa aba para ser editado! E tudo isso sem timeout e sem alguns bugs que encontrei no editor nativo do WordPress.

Quem sabe o blog volta a vida com esse software!

Checklist:

• Leitor de BD: OK!
• Placa de Video com HDMI e Suporte à HDCP: OK!
• Display com HDMI e Suporte à HDCP: OK!
• Software Player: Fail!

Tinha que comprar um software… Procurei rapidamente pois a pizza já tava chegando. As três opções que encontrei são pagas (Dicas? Alguém tem uma solução free?) , fui ver o preço de todas.

Segundo o site que fez a análise, o PowerDVD estava mais caro do que o Total Media que por sua vez estava mais caro que o WinDVD. Não tive dúvida, WinDVD.

Ao “chegar” ao site do programa da Corel, tive uma supresa ao ver que ele detecta sua localização e coloca a versão apropriada para o visitante. Fui jogado no “.br” e fiquei abismado:

R$199,00!! Que absurdo!! Verifiquei que na parte superior do site tem um selecionador de paises e com apenas um clique…

Na versão US o preço virou US$39,99!!! Que pelo câmbio de ontem saiu em reais por R$68,57 através do PayPal!

Você também não ama o “Custo Brasil”…

P.S.: Sobre o Software: Não tem muita firula e faz o serviço.

Espero que gostem!

Hoje recebi um dos meus sonhos de consumo, o volante Logitech Driving Force GT. Quem curte jogos de corrida sempre se imagina correndo utilizando um bom volante, um volante que dê a verdadeira sensação de direção de um carro. E este é o caso desta maravilha!

Ele vem muito bem embalado e assusta à primeira vista, devido ao tamanho da caixa.

Primeira Caixa

Segunda caixa

O produto é fabricado em plástico rígido de ótima qualidade e tem dimensões agradáveis para a direção (cerca de 28 cm)

Abrindo a caixa

Fora da caixa

Peças

Peças

Montado

Montado

Nos primeiros testes pude perceber que ele é muito preciso, tanto na direção como na aceleração e frenagem (No próximo post tentarei colocar vídeos da utilização). Possui funcionalidades específicas para o Gran Turismo que permite a modificação de alguns atributos do carro durante a corrida (O que não é muito simples pois temos que fazer o ajuste de forma correta sem esquecer de fazer as curvas).

Em uso!

Recomendo a todos os entusiastas de simuladores de corrida. O equipamento é excelente.

Quando se escreve scripts, é possível usar o Zenity para criar diálogos simples que interajam graficamente com o usuário:

• Você pode criar um diálogo para obter informações do usuáro. Por exemplo, você pedir ao usuário que selecione uma data em um diálogode calendário ou para escolher um arquivo por um diálogo de seleção de arquivo.
• Você pode criar um diálogo para prover informações ao usuário. Por exemplo, você pode usar um diálogo indicador de progresso para indicar o estado atual de uma operação ou usar um diálogo de mensagem de aviso para alertar o usuário.

O Zenity lhe habilita a criar os seguintes tipos de diálogo simples:

• Calendário
• Seleção de arquivo
• Lista
• Ícone de notificação
• Mensagem
• Indicador de progresso
• Entrada de texto
• Informação de texto

Uma das funcionalidades que achei mais interessante e util foi a barra de progresso. Partindo deste ponto criei um script para mostrar uma barra te progresso enquanto aguardamos um período de tempo para que alguma tarefa seja executada novamente.

#!/bin/bash
(
   for(( i=0; i<=$1; i++))
   do
      j=`echo $i \* 100 / $1 | bc`;
      sleep 1;
      echo $j;
   done
) |
zenity --progress --percentage=0 --auto-close --title="Titulo da Janela" --text="Mensagem de conteudo da janela"

Para acessar a documentação completa do Zenity é só conferir a página do projeto.

if [ -n "$DEFAULT_INSTALLPATH" ]; then # estamos rodando o instalador

# mensagens do instalador

HELLO_IN_LANGUAGE=” — Prey vai falar em português então!”
WHERE_TO_INSTALL_PREY=” -> Onde você quer que instalemos o Prey? [$DEFAULT_INSTALLPATH] ”
USING_DEFAULT_INSTALL_PATH=” — Bom, usando o caminho de instalação padrão…”
INVALID_INSTALL_PATH=” !! Caminho de instalação inválido. Diretório pai não existe!\n”
SETTING_INSTALL_PATH=” — Certo, definindo $INSTALLPATH como nosso caminho de instalação.”

IT_SEEMS_PATH=”Parece que você já instalou o Prey em”
DIFFERENT_PATH=”\nA nova versão usa um caminho diferente para a instalação,”
REMOVE_OLD_FILES=”então devemos remover os arquivos antigos, já que eles não serão mais usados.”
ASK_RM_OLD_FILES=”Você quer que façamos isso automaticamente pra você?”
DELETING_OLD_FILES=” — Removendo os arquivos de instalação antigos do Prey…\n”
CONFIG_FILE_EXISTS=” -> O arquivo Config já existe! Quer pular todas aquelas perguntas chatas? (Não recomendado) [n] ”

SKIP_INSTALL_QUESTIONS=” — Certo, então atualize somente os arquivos necessários!\n”

DEFINE_REPORT_METHOD=” -> Que método de reporte você gostaria de usar? (http, email) [http] ”
IS_REGISTERED_ON_WEB=” — Você já se registrou no site?”
DEFAULT_REPORT_METHOD=” — Usando o painel de controle (http) como nosso método de reporte. Tudo certo!”
ADD_API_KEY=” -> Por favor entre com sua chave de API (API Key) fornecida pelo web service: ”
INVALID_API_KEY=” !! Chave de API inválida! Lembre-se de se registrar em preyproject.com para receber uma.\n”
ADD_DEVICE_KEY=” -> Por favor entre com sua chave de dispositivo (Device Key) para este PC fornecida pelo web service: ”
INVALID_DEVICE_KEY=” !! Chave de dispositivo inválida! Lembre-se de se registrar em preyproject.com para receber uma.\n”

DESIRED_USER_WEB=” — Certo, então deixe-nos fazer pra você. Por favor digite o seu nome completo: ”
ASK_EMAIL_WEB=” — Por favor digite o seu email: ”
DESIRED_PASS_WEB=” — Por favor digite a sua senha: (Nós só a usamos para se registrar por você!) ”
PROBLEM_SIGNUP_WEB=”Ocorreu um problema para se registrar no web service. Por favor tente novamente ou se registre diretamente pelo site”
PROBLEM_RESPONSE_WEB=”A resposta que tivemos foi:”

USING_DEFAULT_APP_URL=” — Usando caminhos para a aplicação web. Nada a escrever aqui!”

ENTER_EMAIL_ADDRESS=” -> Para qual endereço de email você gostaria que o email fosse enviado? (e.g. caixadeemail@dominio.com) [] ”
INVALID_EMAIL_ADDRESS=” !! Você precisa definir uma caixa de entrada. Saindo…\n”

ENTER_SMTP_SERVER=” -> Qual servidor smtp devemos usar? (com a porta) [smtp.gmail.com:587] ”
DEFAULT_SMTP_SERVER=” — Iremos usar o do Gmail então! ”
ENTER_SMTP_USER=” -> Digite o seu nome de usuário smtp: (e.g. caixadeemail@gmail.com)”
DEFAULT_SMTP_USER=” — Certo, nosso nome de usuário SMTP será” # o instalador adicionará a variável email
ENTER_SMTP_PASS=” -> Digite a sua senha smtp: (Não será mostrada) [] ”
INVALID_SMTP_PASS=” !! Você precisa digitar uma senha válida. Saindo…\n”
YES_NO=”y/n”
YES=”y”
CHECK_URL_OR_NOT=” — Você gostaria que o Prey checasse uma URL? (Não significa que o relatório só será gerado a cada vez que o programa rodar) [n] ”
ENTER_URL=” — Certo, então qual será a URL? [i.e. http://meuservidor.com/url_checagem_prey] ”
INVALID_URL=” !! Você precisa definir uma URL. Saindo…\n”
SET_TIMING=” — Certo, essa é a última. Com que frequência (em minutos) você quer que o Prey seja rodado? [$TIMING] ”

INSTALLING_SOFTWARE=” — Certo, instalando programa necessário…\n”
COPYING_ISIGHTCAPTURE=” — Copiando iSightCapture para $INSTALLPATH…”
COPYING_FILES=”\n — Copiando os arquivos necessários para $INSTALLPATH e definindo as permissões…”
ADDING_CRONTAB=” — Adicionando uma entrada no crontab…”
INSTALL_OK=”\033[1m\n — Tudo certo! O Prey está funcionando agora. Você agora pode remover este diretório com segurança.
– Se algum dia você quiser desinstalar o Prey, é só remover o diretório $INSTALLPATH
e remover a linha do Prey no crontab raiz: \n
\t $ sudo rm -Rf $INSTALLPATH\n \t $ sudo crontab -l | grep -v prey | sudo crontab -\n
– Para atualizações lembre-se de dar uma checada em http://preyproject.com!\033[0m\n\n”

else # mensagens de status do prey

STRING_START=”\n ### PREY $version abre suas asas!\n”
STRING_TRY_TO_CONNECT=” — Tentando se conectar a primeira rede wifi aberta disponível…”
STRING_NO_CONNECT_TO_WIFI=” — Não foi possível encontrar uma maneira de se conectar a uma rede wifi aberta!”
STRING_CHECK_URL=” — Checando URL…”
STRING_NO_PROBLEM=” — Nada para se preocupar. \n”
STRING_PROBLEM=” — TEMOS UM PROBLEMA!!!”
STRING_WRITE_EMAIL=” — Escrevendo email…”
STRING_SENDING_EMAIL=” — Enviando o relatório…”
STRING_ERROR_EMAIL=”\n\033[1m !! Ocorreu um problema ao tentar enviar o email. Você tem certeza que ele foi configurado corretamente?
Se você está usando o Gmail, tente remover o ‘@gmail.com’ do campo smtp_username no arquivo de configuração do Prey.\033[0m\n”
STRING_REMOVE_EVIDENCE=” — Removendo todos os traços de evidência…”
STRING_DONE=” — Pronto! Boa caça! \n”

EMAIL_NOTICE=”"
EMAIL_HEADER=”Boas notícias meu amigo, parece que nós o encontramos.\n\nAqui está o relatório do seu computador:\n\n”
EMAIL_FOOTER=”\n\nAgora, vá pegar o desgraçado!\n\n–\nSeu humilde servente, Prey\nhttp://preyproject.com”

fi