Minicursos Livro Texto

Transcrição

1

2 XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos 30 de maio a 3 de junho de 2011 Campo Grande, MS Minicursos Livro Texto Editora Sociedade Brasileira de Computação (SBC) Organizadores Fabíola Gonçalves Pereira Greve (UFBA) Ronaldo Alves Ferreira (UFMS) Realização Faculdade de Computação Universidade Federal de Mato Grosso do Sul (UFMS) Promoção Sociedade Brasileira de Computação (SBC) Laboratório Nacional de Redes de Computadores (LARC)

3 ii Minicurso Livro Texto Copyright 2011 da Sociedade Brasileira de Computação Todos os direitos reservados Capa: Venise Melo Produção Editorial: Fabíola Greve, Lucilene Vilela Gonçalves, Ronaldo Alves Ferreira Cópias Adicionais: Sociedade Brasileira de Computação (SBC) Av. Bento Gonçalves, 9500 Setor 4 Prédio Sala 219 Bairro Agronomia CEP Porto Alegre RS Fone: (51) sbc@sbc.org.br Dados Internacionais de Catalogação na Publicação (CIP) Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos (29.: 2011 : Campo Grande, MS). Minicursos / XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos ; organizadores Fabíola Gonçalves Pereira Greve, Ronaldo Alves Ferreira. Porto Alegre : SBC, c p. ISSN Redes de computadores. 2. Sistemas distribuídos. I. Greve, Fabíola Gonçalves Pereira. II. Ferreira, Ronaldo Alves. III. Título.

4 XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos - SBRC 2011 iii Promoção Sociedade Brasileira de Computação (SBC) Diretoria Presidente José Carlos Maldonado (USP) Vice-Presidente Marcelo Walter (UFRGS) Diretor Administrativo Luciano Paschoal Gaspary (UFRGS) Diretor de Finanças Paulo Cesar Masiero (USP) Diretor de Eventos e Comissões Especiais Lisandro Zambenedetti Granville (UFRGS) Diretora de Educação Mirella Moura Moro (UFMG) Diretora de Publicações Karin Breitman (PUC-Rio) Diretora de Planejamento e Programas Especiais Ana Carolina Salgado (UFPE) Diretora de Secretarias Regionais Thais Vasconcelos Batista (UFRN) Diretor de Divulgação e Marketing Altigran Soares da Silva (UFAM) Diretor de Regulamentação da Profissão Ricardo de Oliveira Anido (UNICAMP) Diretor de Eventos Especiais Carlos Eduardo Ferreira (USP) Diretor de Cooperação com Sociedades Científicas Marcelo Walter (UFRGS)

5 iv Minicursos Livro Texto Promoção Conselho Mandato Virgílio Almeida (UFMG) Flávio Rech Wagner (UFRGS) Silvio Romero de Lemos Meira (UFPE) Itana Maria de Souza Gimenes (UEM) Jacques Wainer (UNICAMP) Mandato Cláudia Maria Bauzer Medeiros (UNICAMP) Roberto da Silva Bigonha (UFMG) Cláudio Leonardo Lucchesi (UFMS) Daltro José Nunes (UFRGS) André Ponce de Leon F. de Carvalho (USP) Suplentes Mandato Geraldo B. Xexeo (UFRJ) Taisy Silva Weber (UFRGS) Marta Lima de Queiroz Mattoso (UFRJ) Raul Sidnei Wazlawick (PUCRS) Renata Vieira (PUCRS) Laboratório Nacional de Redes de Computadores (LARC) Diretoria Diretor do Conselho Técnico-Científico Artur Ziviani (LNCC) Diretor Executivo Célio Vinicius Neves de Albuquerque (UFF) Vice-Diretora do Conselho Técnico-Científico Flávia Coimbra Delicato (UFRN) Vice-Diretor Executivo Luciano Paschoal Gaspary (UFRGS) Membros Institucionais CEFET-CE, CEFET-PR, IME, INPE/MCT, LNCC, PUCPR, PUC-RIO, SESU/MEC, UECEM UERJ, UFAM, UFBA, UFC, UFCG, UFES, UFF, UFMG, UFMS, UFPA, UFPB, UFPE, UFPR, UFRGS, UFRJ, UFRN, UFSC, UFSCAR, UNICAMP, UNIFACS, USP

6 XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos - SBRC 2011 v Realização Comitê de Organização Coordenação Geral Ronaldo Alves Ferreira (UFMS) Coordenação do Comitê de Programa Artur Ziviani (LNCC) Bruno Schulze (LNCC) Coordenação de Palestras e Tutoriais Nelson Luis Saldanha da Fonseca (UNICAMP) Coordenação de Painéis e Debates José Augusto Suruagy Monteiro (UNIFACS) Coordenação de Minicursos Fabíola Gonçalves Pereira Greve (UFBA) Coordenação de Workshops Fábio Moreira Costa (UFG) Coordenação do Salão de Ferramentas Luis Carlos Erpen De Bona (UFPR) Comitê Consultivo Antônio Jorge Gomes Abelém (UFPA) Carlos André Guimarães Ferraz (UFPE) Francisco Vilar Brasileiro (UFCG) Lisandro Zambenedetti Granville (UFRGS) Luci Pirmez (UFRJ) Luciano Paschoal Gaspary (UFRGS) Marinho Pilla Barcellos (UFRGS) Paulo André da Silva Gonçalves (UFPE) Thais Vasconcelos Batista (UFRN)

7 vi Minicursos Livro Texto Realização Organização Local Brivaldo Alves da Silva Jr. (UFMS) Edson Norberto Cáceres (UFMS) Eduardo Carlos Souza Martins (UFMS/POP-MS) Hana Karina Sales Rubinstejn (UFMS) Irineu Sotoma (UFMS) Kátia Mara França (UFMS) Luciano Gonda (UFMS) Lucilene Vilela Gonçalves (POP-MS) Márcio Aparecido Inácio da Silva (UFMS) Marcos Paulo Moro (UFGD) Massashi Emilson Oshiro (POP-MS) Nalvo Franco de Almeida Jr. (UFMS) Péricles Christian Moraes Lopes (UFMS) Renato Porfírio Ishii (UFMS)

8 XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos - SBRC 2011 vii Mensagem do Coordenador Geral Sejam bem-vindos ao XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos (SBRC 2011) em Campo Grande, MS. É um prazer e uma distinção organizar um simpósio de tamanha relevância para a computação no Brasil, mais ainda por ser a primeira vez que a Região Centro-Oeste tem o privilégio de sediá-lo. O SBRC é um evento anual promovido pela Sociedade Brasileira de Computação (SBC) e pelo Laboratório Nacional de Redes de Computadores (LARC). Ao longo dos seus quase trinta anos, o SBRC tornou-se o mais importante evento científico nacional em Redes de Computadores e Sistemas Distribuídos e um dos maiores da área de Informática no país. O SBRC 2011 está com uma programação bastante rica, de qualidade diferenciada e que consiste em: 18 sessões técnicas de artigos completos que abordam o que há de mais novo nas áreas de redes de computadores e sistemas distribuídos; três sessões técnicas para apresentação de ferramentas selecionadas para o Salão de Ferramentas; cinco minicursos, com quatro horas de duração, sobre temas atuais; três palestras e t rês tutoriais com pesquisadores de alto prestígio internacional; e três painéis sobre assuntos de interesse da comunidade. Além dessas já tradicionais atividades do simpósio, ocorrerão em paralelo oito workshops: XVI Workshop de Gerência e Operação de Redes e Serviços (WGRS), XII Workshop da Rede Nacional de Ensino e Pesquisa (WRNP), XII Workshop de Testes e Tolerância a F alhas (WTF), IX Workshop em Clouds, Grids e Aplicações (WCGA), VII Workshop de Redes Dinâmicas e Sistemas P2P (WP2P), II Workshop de Pesquisa Experimental da Internet do Futuro (WPEIF), I Workshop on A utonomic Distributed Systems (WoSIDA) e I Workshop de Redes de Acesso em Banda Larga. O desafio de organizar um evento como o SBRC só pode ser cumprido com a ajuda de um grupo especial. Eu tive a f elicidade de contar com a co laboração de inúmeras pessoas ao longo desta jornada. Meus sinceros agradecimentos aos membros dos Comitês de Organização Geral e Local por realizarem um trabalho de excelente qualidade e com muita eficiência, a qualidade da programação deste simpósio é fruto do trabalho dedicado dessas pessoas. Sou grato a Faculdade de Computação da UFMS por ter sido uma facilitadora ao longo de todo o pr ocesso de organização, desde a nossa proposta inicial até o fechamento da programação. Gostaria de agradecer, também, ao Comitê Gestor da Internet no Brasil (CGI.br), às agências governamentais de fomento e aos patrocinadores por reconhecerem a importância do S BRC e investirem recursos financeiros fundamentais para a realização do evento. Com o apoio financeiro recebido, foi possível manter os custos de inscrição baixos e oferecer um programa social de alta qualidade. Em nome do Comitê Organizador, agradeço a todos os participantes pela presença em mais esta edição do SBRC e d esejo uma semana produtiva, agradável e com estabelecimento de novas parcerias e amizades. Ronaldo Alves Ferreira Coordenador Geral do SBRC 2011

9 viii Minicursos Livro Texto Mensagem da Coordenadora de Minicursos É um grande prazer introduzir os minicursos que serão apresentados nessa 29a. edição do Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos. Ao longo dos anos, os minicursos vêm se configurando como uma excelente fonte de divulgação de resultados de pesquisa em temas atuais, de grande relevância e n ão cobertos pelas grades curriculares. Cada minicurso compõe um capítulo deste livro e está estruturado para ser apresentado durante o evento em cerca de quatro horas. Para esta edição, foram escolhidas 5 e xcelentes propostas, dentre 31 s ubmetidas, configurando uma taxa de aceitação de cerca de 16%. Cada proposta obteve entre 3 e 4 avaliações feitas por um Comitê de Avaliação criterioso composto por 26 pe squisadores especialistas nas diversas áreas de redes e sistemas distribuídos. Os minicursos selecionados para essa 29a. edição têm temática bastante atual e em sua maioria abordam questões relativas à próxima geração de infraestrutura e serviços para a Internet do futuro. Sabe-se que num futuro próximo, a Internet estará conectando os mais variados tipos de dispositivos e objetos e em quantidades inimagináveis. Ela será omnipresente e universal. As redes deverão se auto configurar de forma a at ender de maneira eficaz, permanente, segura e co nfiável as demandas de serviços dos mais variados graus por comunidades que se auto organizam no tempo e no espaço. Mais do nunca os aspectos de confiança no f uncionamento dos sistemas precisarão ser assegurados. Novos mecanismos de identicação de objetos, distribuição de conteúdo e buscas, inclusive semânticas, além da oferta de recursos sob demanda, serão necessários. Esses requisitos, dentre outros, formam o objeto de estudo dos capítulos a seguir. O Capítulo 1 a borda técnicas de virtualização de redes, considerando o padrão de comunicação OpenFlow. Seu foco são as redes experimentais como laboratório para as soluções e desafios enfrentados na implementação dos novos protocolos, arquiteturas e serviços da Internet do futuro. O capítulo apresenta recentes experiências na área tanto no Brasil como Exterior, uma descrição do arcabouço OpenFlow e aspectos de virtualização, além de requisitos, mecanismos de configuração e t estes para as redes experimentais. O Capítulo 2 introduz as redes sociais on-line. As redes sociais são um extraordinário testemunho e acelerador de movimentos sociais e sobretudo um formidável vetor de democracia. Para tanto, permitem com que usuários criem e manipulem conteúdo de maneira ad-hoc e quase irrestrita. Tudo isso suscita o emprego de novas técnicas para a manipulação de grande volume de dados e para o de senvolvimento de sistemas de distribuição de conteúdo confiáveis e seguros, além de novas formas de organização, uso e busca de conteúdo, particularmente de mineração de dados. Elas introduzem novos padrões de tráfego na Internet e várias alternativas de interação humanocomputador. O capítulo faz uma breve apresentação das redes existentes, discute suas principais características, as diferentes abordagens de coleta e extração de dados, além de importantes métricas e tipos de análises utilizadas no estudo dos grafos que modelam essas redes.

10 XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos - SBRC 2011 ix Web das coisas é o t ema do C apítulo 3. A Internet das coisas abre a perspectiva de integrar objetos inteligentes que permeiam o nosso cotidiano (computadores ou dispositivos embarcados) à Internet. A Web das coisas (WoT) propõe a interligação dos diversos objetos via padrões Web, de maneira a facilitar o seu uso e a sua integração às inúmeras aplicações existentes na Web. O capítulo introduz os conceitos e tecnologias da WoT, uma arquitetura de software com descrição do projeto de implementação de seus componentes, bem como exemplos práticos de construção de aplicações baseadas no paradigma da WoT. O Capítulo 4 tem como preocupação a gerência de identidades de usuários na Internet do futuro. A segurança é uma preocupação maior no pr ojeto dos sistemas modernos. Fatores como o alto dinamismo, o e cletismo, a mobilidade, o anonimato, a extensibilidade e a es cassez de recursos tornam os ambientes atuais extremamente vulneráveis e sujeitos a variados ataques de agentes maliciosos. A gestão de identidades possibilita o c ontrole do pe rfil dos usuários e das suas relações de confiança, define políticas de acesso e f az uso de mecanismos de autenticação para a o ferta segura de serviços na rede. O capítulo apresenta os principais desafios, descreve técnicas adequadas, bem como os dispositivos específicos e arquiteturas existentes para a implementação da gerência de identidades no novo modelo computacional introduzido pela Internet do futuro. O Capítulo 5 discute a questão de alocação de recursos na Computação em Nuvem. Este novo paradigma permite com que um grande volume de recursos disponíveis na Internet tenha utilização imediata e s ob demanda, viabilizando assim a o ferta de serviços, processos, dispositivos e infra-estrutura de maneira universal e ilimitada. O processo de alocação de recursos é nesse contexto fundamental para o provimento dos mesmos. Ele deve ser dinâmico e permitir com que os requisitos do conjunto de aplicações possam ser atendidos. O capítulo define e apresenta as tecnologias essenciais da computação em nuvem, com foco nos desafios e soluções para a alocação de recursos. Gostaria de expressar os meus sinceros agradecimentos ao Ronaldo Alves Ferreira da UFMS, coordenador do SBRC 2011, pela confiança, presteza e apoio recebido ao longo das nossas interações. Um grande agradecimento a todos os membros do Comitê de Avaliação pelas ótimas intervenções, reatividade e boas discussões que contribuíram para termos uma seleção criteriosa e construtiva. Meu agradecimento especial aos autores que, mais uma vez, prestigiaram a trilha de minicursos do SBRC, encaminhando propostas maduras e bem delineadas, que refletem a qualidade dos resultados das suas pesquisas. Fabíola Gonçalves Pereira Greve Coordenadora de Minicursos do SBRC 2011

11 XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos - SBRC 2011 x Comitê de Avaliação de Minicursos Alfredo Goldman vel Lejbman (USP) Alysson Bessani (Universidade de Lisboa) Antônio Jorge Gomes Abelém (UFPA) Carlos Alberto Kamienski (UFABC) Carlos Montez (UFSC) Daniel Mossé (University of Pittsburg) Eduardo Nakamura (UFAM) Elias Procópio Duarte Jr. (UFRP) Fabíola Gonçalves Pereira Greve (UFBA) Francisco Brasileiro (UFCG) Genaro Costa (UFBA) Hana Karina Salles Rubinsztejn (UFMS) José Marcos Nogueira (UFMG) Jussara Almeida (UFMG) Luci Pirmez (UFRJ) Lucia Drummond (UFF) Luciano Paschoal Gaspary (UFRGS) Luis Carlos De Bona (UFPR) Luiz Eduardo Buzato (UNICAMP) Marcelo Dias de Amorim (LIP6/CNRS) Marinho Barcellos (UFRGS) Nabor Mendonça (UNIFOR) Noemi Rodriguez (PUC-Rio) Paulo André da Silva Gonçalves (UFPE) Regina Araújo (UFSCar) Thais Vasconcelos Batista (UFRN)

12 XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos - SBRC 2011 xi Sumário Capítulo 1 Pesquisa Experimental para a Internet do Futuro: Uma Proposta Utilizando Virtualização e o Framework OpenFlow Introdução Pesquisa Experimental em Internet do Futuro no Brasil e no Mundo Desafios Relacionados à Internet do Futuro Iniciativas para Investigação em Internet do Futuro GENI (Global Environment For Network Inovation) Future Internet Research and Experimentation (FIRE) Iniciativas Brasileiras OpenFlow e Virtualização O OpenFlow Aplicações Modos de Funcionamento dos Switch Controle Usando NOX Virtualização Virtualização de Sistemas Virtualização de Redes Redes de Sobreposição (Overlay) Virtualização de Rede com OpenFlow Requisitos para Construção de um Ambiente para Experimento e Virtualização de Redes Tipos de Hardwares Arcabouços de Controle Monitoração e Medição Ferramentas para Gerência de Virtualização Estudo de Caso Definição do Ambiente Dados de Implementação do Ambiente Plano de Dados Plano de Controle Aplicação Prática Conclusão Considerações Finais e o Futuro em Pesquisa Experimental em Internet do Futuro Considerações Finais Tendências Futuras Referências... 55

13 xii Minicursos Livro Texto Capítulo 2 Explorando Redes Sociais Online: Da Coleta e Análise de Grandes Bases de Dados às Aplicações Introdução Definições e Características de Redes Sociais Online Definição Elementos das Redes Sociais Online Teoria de Redes Complexas Métricas para o Estudo de Redes Complexas Grau dos Vértices Coeficiente de Agrupamento Componentes Distância Média e Diâmetro Assortatividade Betweenness Reciprocidade PageRank Redes Small-World Redes Power-Law e Livres de Escala Técnicas de Coleta de Dados Dados dos Usuários Dados de Pontos Intermediários Servidores Proxy Agregadores de Redes Sociais Dados de Servidores de Redes Sociais Online Coleta por Amostragem Coleta em Larga Escala Coleta por Inspeção de Identificadores Coleta em Tempo Real Utilizando APIs Ferramentas e Bibliotecas Ética dos Coletores Dados de Aplicações Extração de Informação Visão Geral Identificação de Entidades Resolução de Entidades Bases de Dados Disponíveis na Web Conclusões Referências... 94

14 XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos - SBRC 2011 xiii Capítulo 3 Web das Coisas: Conectando Dispositivos Físicos ao Mundo Digital Introdução Da Internet das Coisas a Web das Coisas Internet das Coisas Web das Coisas Concretizando a Web das Coisas: REST & ROA REST Princípios REST ROA URIs Endereçabilidade Sem Estado Representação Links e Conectividade Interface Uniforme Desenvolvimento de Serviços RESTful Requisitos do Serviço Web de Exemplo Identificação de Recursos Representação de Recursos Definição de URI Descritor WADL REST versus WS-* SOAP Estendendo ROA para a Web das Coisas Comunicação Orientada a Eventos Web das Coisas: Desenvolvendo Aplicações na Plataforma Sun SPOT Introdução a Plataforma Sun SPOT Integração de Dispositivos na Web Técnica de Implementação de Servidores Web em Dispositivos Embarcados Implementação de Gateways Exposição de Dispositivos como Recursos REST Representação de Estado Técnicas de Implementação de Mashups Físicos Conclusão Referências

15 xiv Minicursos Livro Texto Capítulo 4 Gerência de Identidade na Internet do Futuro Introdução Internet do Futuro Exemplos de Serviços da Internet do Futuro Redes da Próxima Geração Gerência de Identidade Entidade, Identidade e Credencial Ciclo de Vida Sigle Sign-On Usuários, Provedores de Identidade e Provedores de Serviços Requisitos de um Sistema de Gestão de Identidade na Internet do Futuro Iniciativas de Gerência de Identidade para as Redes da Próxima Geração Projetos e Arquiteturas Alianças Especificações Consolidadas Ferramentas e Tecnologias para Gerência de Identidade Cartões Inteligentes (Smart Cards) Biometria Conclusões Referências Capítulo 5 Resource Allocation in Clouds: Concepts, Tools and Research Challenges Introduction The Emergence of Cloud Computing The Value of Cloud for Business The Value of Cloud Academy Structure of the Short Course What is Cloud Computing? Definitions Agents Involved in Cloud Computing Classification of Cloud Operators Mediation System Groundwork Technologies Open Research Problems Challenges in the Negotiation Layer Challenges in the Resource Management and Resource Control Layers Resource Allocation Definitions for Resource Allocation

16 XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos - SBRC 2011 xv Research Challenges in Resource Allocation Solutions Open-Source Mediation Systems Eucalyptus OpenNebula Nimbus Comparisons Final Considerations Review of the Matter Future Trends Referências

17

18 Capítulo 1 Pesquisa Experimental para a Internet do Futuro: Uma Proposta Utilizando Virtualização e o Framework Openflow Fernando N. N. Farias, José M. Dias Júnior, João J. Salvatti, Sérgio Silva, Antônio J. G. Abelém, Marcos R. Salvador and Michael A. Stanton Abstract The Internet has become a huge worldwide success and is changing the way we interact, work, and amuse ourselves. Much of its success is due to the great flexibility of IP (Internet Protocol) technology. Despite all the success of the Internet, IP core technology is the cause of its own limitations, which become increasingly more evident. The main goals of activities labeled as Future Internet (FI) are the formulation and evaluation of alternative architectures to substitute IP. In this context, two approaches are being discussed and investigated, where the first, called Clean Slate, aims at replacing the current architecture by a new fully rebuilt one, and the second, called Evolutionary, that intends to evolve the current architecture without losing compatibility with the current one. However, the biggest challenge now is where to enable and test the proposed approaches in order to validate efficiently them without sacrificing the current infrastructure, since there will be the need for routers and switches to be reconfigured, and resources to be allocated and monitored. Thus, the network must be as flexible as possible so that this infrastructure allows the coexistence of multiple parallel models. In this sense, virtualization (of network devices, links, etc.) and the OpenFlow solution are being seen as the best alternatives to enable multiple experiments of new architectures in a production environment. An Open- Flow network allows the programming of network behavior, in addition to creating virtual network environments called slices (virtual networks with nodes, links and resources) to test new protocol models. This short course will be essentially theoretical and starts by presenting the motivation that is leading professionals and the academic community to

19 2 Minicursos Livro Texto invest in research to investigate the challenges of the Future Internet. Next, recent experiments carried out for the Future Internet in Brazil and in research networks in Europe, North America, and Asia will be presented. After that, the OpenFlow framework will be detailed, including the main aspects of virtualization. We also describe the requirements for construction of an experimental testbed, including demonstration and details of the mechanisms needed to configure and evaluate such a test environment. A case study of creating multiple slices for testing networking protocols will be shown. Finally, future trends will be presented regarding the experimental research and the Future Internet. Resumo A Internet é um enorme sucesso mundial e vem mudando a forma como interagimos, trabalhamos e nos divertimos. Boa parte deste sucesso se deve à grande flexibilidade da tecnologia IP. Apesar de todo o sucesso da Internet, a tecnologia básica IP é a causa das suas próprias limitações que se tornam cada vez mais evidentes. Um dos principais objetivos da atividade conhecida como Internet do Futuro (IF) é a formulação e avaliação de arquiteturas alternativas para substituir o protocolo IP. Nesse contexto, duas abordagens estão sendo discutidas e investigadas: a primeira denominada limpa (Clean Slate), que visa substituir a arquitetura atual por uma nova totalmente reconstruída, e a outra chamada evolucionária (Evolutionary) que pretende evoluir a arquitetura atual sem perder a compatibilidade com a anterior. No entanto, o maior desafio agora é onde habilitar e testar as propostas das respectivas abordagens de modo a validá-las eficientemente, sem prejudicar a infraestrutura atual, já que haverá a necessidade de que roteadores e switches sejam reconfigurados, e recursos sejam alocados e monitorados. Em suma, a rede deve ser a mais flexível possível, para que essa infraestrutura permita a coexistência de múltiplos modelos paralelos. Nesse sentido, a virtualização (de rede, dispositivos, enlace e etc.) e a solução OpenFlow vem se tornando uma interessante alternativa para habilitar múltiplos experimentos com novas arquiteturas em um ambiente de produção. Uma rede OpenFlow admite a programação do comportamento da rede, além da criação de ambientes de rede virtuais chamados fatias (redes virtuais com nós, enlaces e recursos) para testar novos modelos de protocolo. Este minicurso tem como principal objetivo apresentar os desafios e soluções para se criar um ambiente de testes para a Internet do Futuro utilizando técnicas de virtualização de redes e o framework Open- Flow. O minicurso será essencialmente teórico e apresentará os fatores motivacionais que vêm levando os profissionais da área e a comunidade acadêmica a investirem na realização de pesquisa experimental para investigar os desafios da Internet do Futuro. Em seguida, serão expostas as recentes experiências realizadas para IF, tanto no Brasil como em backbones da Europa, da América do Norte e da Ásia. Após isso, será detalhado o arcabouço OpenFlow, incluindo os principais aspectos sobre virtualização. Logo depois, serão descritos os requisitos para construção de uma rede para experimentação, com a demonstração e o detalhamento dos mecanismos necessários para configurar e testar esse ambiente. Um estudo de caso de criação de várias fatias de redes para testes de protocolos também será demonstrado. Por fim, serão apresentadas as tendências futuras em relação à pesquisa experimental em Internet do Futuro.

20 XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos - SBRC Introdução A Internet hoje está sendo usada para uma grande variedade de propósitos comerciais e não comerciais. Para muitas pessoas é uma ferramenta de trabalho crucial, para outras, seu local de trabalho. Porém, para a grande maioria, é um eficiente meio de comunicação, entretenimento ou plataforma educacional. Ou seja, a Internet é um enorme sucesso mundial e vem mudando a forma como interagimos, trabalhamos e nos divertimos. Boa parte deste sucesso se deve à grande flexibilidade da tecnologia IP (Internet Protocol), que provê um mecanismo uniforme de transporte fim a fim, independente das tecnologias utilizadas nas camadas de mais baixo nível. Apesar de todo o sucesso da Internet, a tecnologia básica IP é a causa das suas próprias limitações, que se tornam cada vez mais evidentes. A noção central de tamanho único, que requer tratamento idêntico para todos os fluxos de informação na Internet ao nível do pacote IP, não é desejável e nem necessariamente econômica, especialmente quando certas classes de aplicação, tais como de mídia interativa ou de acesso remoto a instrumentos científicos que, requerem garantias de qualidade de serviço (Quality of Service - QoS) desnecessárias para a maioria de outras aplicações. A atual arquitetura da Internet, inicialmente projetada há aproximadamente 30 anos, sofreu muitas extensões nos anos recentes para incluir novas funcionalidades, as quais não foram previstas no projeto inicial. Muitos especialistas de rede agora consideram que é necessário conduzir um estudo de arquiteturas alternativas para Internet do Futuro (IF), como uma maneira realmente eficiente de resolver muitos dos problemas prementes que atualmente afligem a Internet. Algumas das desvantagens da continuada persistência no uso da atual arquitetura incluem: Exaustão já anunciada do espaço atualmente disponível de identificadores de rede IP versão 4 (IPv4), causando uma balcanização da Internet, sem verdadeira conectividade global; Custos elevados dos roteadores IP, restringindo o crescimento da rede, motivado principalmente pela natureza não escalonável das tabelas de roteamento, e dos requisitos de desempenho necessários para poder processar essas gigantescas tabelas na mesma velocidade que seus enlaces; Investimentos imensos em medidas paliativas para conter problemas de segurança atualmente causados por spam, negação de serviço (DoS - denial of service) e crimes de roubo de informação; Dificuldades de combinar transparência de acesso e desempenho de aplicação para usuários móveis. Devido a isso, nos últimos anos, vêm sendo aplicadas à arquitetura da Internet uma série de modificações pontuais ou remendos, para atender às limitações encontradas. Entre os remendos mais conhecidos, podem ser mencionados Classless Internet Domain Routing (CIDR), Network Address Translation (NAT), Serviços Integrados (Intserv), Serviços Diferenciados (Diffserv), IP Seguro, IP Móvel, firewalls e filtros de spam; estes são os mais conhecidos.

21 4 Minicursos Livro Texto Por conta disso, há um entendimento crescente entre os pesquisadores em redes de computadores que soluções para a maioria destes problemas, dependerão de um redesenho fundamental da atual arquitetura da Internet, baseada em IP. E como aliada na busca dessas soluções, surge a atividade conhecida como Internet do Futuro, que inclui entre seus principais objetivos a formulação e avaliação de arquiteturas alternativas para substituir o IP, o qual é frequentemente ilustrado pelo conhecido modelo da ampulheta da Internet, apresentado na Figura 1.1. Figura 1.1. A evolução do conceito da Internet [Banniza et al. 2009] Nesse contexto, duas abordagens estão sendo discutidas e investigadas. A primeira denominada limpa (Clean Slate), que visa substituir a arquitetura atual por uma nova totalmente reconstruída. A outra, chamada evolucionária (Evolutionary), que pretende evoluir a arquitetura atual sem perder a compatibilidade com a anterior. A proposta Clean Slate, que atualmente é um dos esforços para o desenvolvimento da Internet do Futuro, tem como principal objetivo direcionar como será efetuado o desenho da nova Internet [McKeown 2011]. Mas para que isso ocorra, a IF deve atender a um conjunto de requisitos importantes. Dentro desse contexto, David Clark [Clack 2011] cita os caminhos e os requisitos fundamentais para o sucesso desta nova arquitetura, proposta que Clean Slate irá tomar para projetar a IF. Dentre esses requisitos, é possível destacar como os principais desafios: robustez e disponibilidade, suporte a nós móveis economicamente viável e rentável, gerenciabilidade com segurança e ser evolutiva. As pesquisas baseadas em Clean Slate permitem explorar radicalmente uma nova arquitetura para Internet, mas isso não quer dizer que serão imediatamente aplicadas. Desse modo, algumas dessas soluções podem ter ou não um caminho viável de implantação na Internet atual [Feldmann 2007]. Por outro lado, tem-se a abordagem Evolutionary ou Incremental, que tem a missão, como pesquisadores da Internet, de primeiro medir e entender o estado corrente

22 XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos - SBRC que se encontra a infraestrutura atual da Internet, para poder prever qual caminho ela seguirá e quais problemas enfrentará. Depois, com isso, criar o que pode ser referenciado como uma inteligente mutação [Rexford and Dovrolis 2010], ou seja, inovações que podem, primeiro, afastar ou resolver estes desafios e, segundo, adaptar-se para a corrente infraestrutura da Internet, de uma forma que seja compatível com as versões anteriores e possa ser incrementalmente expansível. A adoção de qualquer uma das arquiteturas alternativas pode alterar a situação em que a Internet atual se encontra. Entretanto, um sério obstáculo para adoção efetiva de tais inovações tem sido a inabilidade de validá-las de maneira convincente. A redução no impacto do mundo real de qualquer inovação se deve à enorme base instalada de equipamentos e protocolos e à relutância em experimentar com tráfego de produção, o que tem criado uma barreira extremamente alta para a entrada de novas ideias. O resultado é que a maior parte das novas ideias da comunidade de pesquisa de rede não é testada, levando à crença comumente mantida de que a infraestrutura da Internet ossificou ou enrijeceu [Paul et al. 2011]. Tendo reconhecido o problema, a comunidade de pesquisa de rede está desenvolvendo soluções alternativas para pesquisa experimental em IF. Suas atividades inicias, usando redes para experimentação (testbeds), começaram nos EUA com os programas Global Environment for Network Innovations (GENI) [GENI 2011] e Future Internet Design (FIND) [FIND 2011], onde suas principais propostas são testar e amadurecer um grande conjunto de pesquisas em comunicação de dados e sistemas distribuídos. Além disso, ainda há o programa Future Internet Research and Experimentation (FIRE) na UE (União Europeia) [FIRE 2011] que é uma iniciativa de ambiente de pesquisa para experimentação e validação de ideias inovadoras e revolucionárias para novos paradigmas de redes e serviços. Nesta mesma linha, temos o projeto AKARI no Japão [AKARI 2009], um programa de pesquisa que tem como objetivo implementar a nova geração de redes para 2015, baseada na proposta Clean Slate. E por fim, iniciativas semelhantes também foram lançadas mais recentemente na Coreia [Liu et al. 2009] e na China [Bi 2011]. Neste sentido, redes de experimentação programáveis e virtualizadas vêm sendo utilizadas por esses projetos para diminuir a barreira de custo à entrada de novas ideias, aumentando a taxa de inovação da infraestrutura de rede. Com isso, são oferecidas infraestruturas capazes de habilitar, controlar e testar as respectivas abordagens, de modo a validá-las eficientemente, sem prejudicar a infraestrutura atual. No contexto de redes programáveis, o arcabouço OpenFlow é uma solução que vem oferecendo aos pesquisadores a possibilidade de testar seus protocolos experimentais em redes de produção como: redes de um campus, redes metropolitanas ou em um backbone de rede de ensino e pesquisa [McKeown et al. 2008]. O OpenFlow, além de oferecer o protocolo de controle, chamado de OpenFlow protocol para manipular a tabela de encaminhamento dos roteadores e switches, também oferece uma API (Application Programming Interface) simples e extensível para programar o comportamento dos fluxos de pacotes. Desta forma que, através desta API, pesquisadores podem rapidamente construir novos protocolos e aplicá-los em um ambiente de produção sem prejudicá-lo.

23 6 Minicursos Livro Texto A virtualização de computadores tem sido usada há muito tempo e hoje está amplamente disponível em plataformas comuns. É realizada por meio do compartilhamento de processadores e dispositivos de E/S, utilizando técnicas de fatiamento de tempo e memória virtual. A virtualização de redes, a mais recente, é conseguida pelo uso de switches, roteadores virtuais e a multiplexação de enlaces [Chowdhury and Boutaba 2010]. Observando isso, o uso das técnicas de virtualização de redes (dispositivos, enlace, etc.) em conjunto com a solução OpenFlow vem se tornando uma excelente alternativa para habilitar múltiplos experimentos com novas arquiteturas em um ambiente de produção. Uma rede OpenFlow permite que se possa programar o comportamento da rede, além de criar ambientes virtuais de rede chamados de fatias (redes virtuais com nós, enlaces e recursos) para testar novas ideias e modelos de protocolos para IF. Este minicurso tem como principal objetivo apresentar as iniciativas para o desenvolvimento da IF, seus requisitos necessários e o uso de virtualização e OpenFlow para se criar um ambiente de testes para experimentação e desenvolvimento de protocolos na abordagem de IF. Além desta seção introdutória, o artigo está dividido da seguinte maneira: Seção 2 - são apresentadas as recentes experiências realizadas para Internet do Futuro, tanto no Brasil como em backbones da Europa e da América do Norte; Seção 3 - é detalhado o framework OpenFlow, incluindo os principais aspectos sobre virtualização; Seção 4 - são descritos os requisitos para construção de um testbed experimental; Seção 5 - tem-se um estudo de caso de criação de vários slices de redes para testes de protocolos; Seção 6 - são apresentadas as considerações finais e tendências futuras em relação à pesquisa experimental e Internet do Futuro Pesquisa Experimental em Internet do Futuro no Brasil e no Mundo Atualmente, na comunidade acadêmica, existe um amplo consenso de que a Internet atual sofre várias limitações relacionadas com escalabilidade, suporte a redes móveis de vários tipos (ad-hoc, multi-hop e mesh), mobilidade, ao consumo de energia, à transparência, à segurança e outras [Jain 2006]. A partir disso, nesta seção, são levantados e comentados os principais desafios que estão relacionados à Internet do Futuro. Como também, são observados os projetos a respeito de investigação da IF como o caso do GENI (Global Environment for Network Innovation), financiado pela NSF (National Science Foundation), FIRE (Future Internet Research and Experimentation), pela União Europeia e por iniciativas brasileiras Desafios Relacionados à Internet do Futuro O conceito básico da arquitetura da Internet foi desenvolvido há mais de trinta anos atrás. Neste tempo, tem-se aprendido bastante sobre redes de computadores e encaminhamento

24 XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos - SBRC de pacotes. Também, durante este mesmo período, a Internet vem sofrendo contínuas adaptações, causadas pelo seu rápido crescimento e pela quantidade de usuários e aplicações habilitadas sobre sua arquitetura. Essas adaptações ou remendos demonstram que o projeto inicial já não se ajusta às necessidades atuais na rede. Além disso, a arquitetura atual da Internet já apresenta inúmeros problemas ainda não solucionados, impedindo o atendimento dos requisitos destas novas aplicações e serviços. Muitos especialistas em rede de computadores chegaram a um consenso de que agora consideram extremamente importante realizar estudos de arquiteturas alternativas para Internet do Futuro como uma maneira realmente eficiente de resolver muitos dos problemas prementes que atualmente afligem a Internet. A seguir, são apresentados alguns dos principais desafios, que, segundo Paul [Paul et al. 2011], a nova arquitetura da Internet deve atender. a. Suporte a Novas Tecnologias de Rede A Internet atual é projetada para tirar vantagem de uma grande gama de tecnologias de comunicação em rede. No entanto, hoje há vários desafios no horizonte, entre elas as tecnologias sem fio e as novas soluções ópticas As redes sem fio abrangem uma série de tecnologias que vão do Wi-Fi de hoje até as ultra-widebands e redes de sensores sem fio de amanhã. Considera-se que as redes sem fio são talvez umas das maiores tecnologias de rede e com granularidade maior ou igual às redes locais (LAN). No entanto, uma consequência das redes sem fio é a mobilidade. Atualmente, a mobilidade está na borda da rede, mas, os mecanismos para torná-la mais eficiente não funcionam de maneira satisfatória. Principalmente, nas questões relacionadas à eficiência energética, mudança de ponto de acesso e aplicações. Portanto, identificam-se os seguintes desafios para suporte às tecnologias sem fio: a Internet do Futuro deve suportar a mobilidade como o objetivo primordial em sua construção. Os nós devem ser capazes de modificar seu ponto de acesso na Internet e, mesmo assim, continuarem sendo alcançáveis a Internet do Futuro deve oferecer meios adequados para uma aplicação de descobrir as características dos mais variados tipos de enlace de rede sem fio e se adaptar a eles, de maneira a prover as eficiências energéticas destes nós. a Internet do Futuro deve facilitar o processo pelo qual os nós móveis, fisicamente próximos, descubram-se uns aos outros. Outra tecnologia revolucionária é a rede de transporte óptica. A comunidade de pesquisadores em redes ópticas está desenvolvendo maneiras de como usar as novas tecnologias como comutadores ópticos e elementos lógicos para encaminhar dados com taxas de transmissão muito maiores que as redes puramente eletrônicas. Isso envolve mudanças em vários níveis: de redes em anéis para redes em malha; de redes com comprimentos de ondas fixamente alocados para transmissores (e receptores) dinamicamente sintonizados; de redes sem buffers ópticos para redes com planos de controles inteligentes

25 8 Minicursos Livro Texto e com buffers ópticos suficientes; e de redes ópticas que utilizam larguras de bandas fixas para as que permitem que a largura de banda seja dinamicamente alocada, acessada e utilizada. Logo se identificam os desafios para Internet do Futuro poder explorar a emergente capacidade óptica: a Internet do Futuro deve ser projetada para permitir aos usuários utilizarem essas novas capacidades de transporte ópticos, incluindo uma melhor confiabilidade através de diagnósticos entre camadas; a Internet do Futuro deve permitir que os nós que são dinamicamente configuráveis habilitem a camada eletrônica para o acesso dinâmico de usuários; a Internet do Futuro deve incluir softwares de controle e gerenciamento que permitam à rede formada por nós dinamicamente reconfiguráveis ser configurada por aplicações que necessitem de uma grande quantidade de recursos de rede, tal como largura de banda b. Segurança e Robustez Talvez a razão que mais estimulou a comunidade acadêmica a pensar em um redesenho da Internet foi a possibilidade de ter uma rede com grandes avanços na segurança e na robustez. Na Internet atual, não há nenhuma abordagem, realmente abrangente para tratar questões de segurança. Ela possui muitos mecanismos, mas não uma arquitetura segura e muito menos um conjunto de regras determinando como esses mecanismos devem ser combinados para se obter uma boa segurança de maneira geral. A segurança em redes e principalmente a da Internet, atualmente se assemelha a um conjunto crescente de remendos, extremamente suscetível a falhas. Para construção de uma rede mais robusta e segura, identificam-se os seguintes desafios: qualquer conjunto de hosts deve ser capaz de se comunicar entre si com alta confiabilidade e previsibilidade e nós maliciosos ou defeituosos não podem ser capazes de interromper esta comunicação. Além disso, os usuários devem esperar por um nível de disponibilidade correspondente ou que exceda o sistema de telefonia de hoje; a segurança e robustez devem ser estendidas através de suas camadas, pois a segurança e confiabilidade de um usuário final dependem da robustez, tanto nas camadas de comunicação quanto nas aplicações distribuídas. c. Eficiência Energética na Comunicação Atualmente, há uma preocupação mundial [Joseph and Lewis 2008] pelo desenvolvimento de tecnologias que diminuam o consumo de energia, principalmente em redes, como as de sensores sem fio e as de dispositivos móveis Wi-Fi, onde recursos energéticos são fatores

26 XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos - SBRC relevantes em sua comunicação. Com as atuais tecnologias, comunicando um bit sobre um meio sem fio, em intervalos curtos, consomem mais energia do que o seu processamento, e não possui tendência de mudanças em um futuro próximo [Chen, 2006]. No entanto, a Internet atual não possui mecanismos que levem em consideração a comunicação com requisitos de eficiência de energia, de modo a adaptar o seu consumo mediante a observação do meio. Ou ainda, que adapte o uso de energia para oferecer uma comunicação eficiente, na transmissão de dados e no gerenciamento de rede, a baixos níveis energéticos. Portanto, como desafio para o projeto da Internet do Futuro: deve-se prover meios para uma eficiência energética generalizada tanto para dispositivos sem fio quanto os com fio; desenvolver tecnologias com o foco no uso eficiente da energia elétrica; incluir em sua arquitetura mecanismos que ofereçam uma comunicação eficiente tanto na transmissão de dados como no gerenciamento de rede; prover uma arquitetura para Internet do Futuro energeticamente otimizada. d. Separação de Identidade e Endereço Na Internet atual, um sistema é identificado pelo seu endereço IP. Como resultado, quando o sistema mudar a localização do ponto da sua interligação, seu endereçamento também pode mudar. Ou seja, o endereço IP, neste caso, ao mesmo tempo, tem o papel de identificador e localizador. Devido a isso, os nós móveis se tornaram um desafio na Internet atual. Por essas características, torna-se difícil iniciar a comunicação com um sistema móvel. Este é um problema bem conhecido na Internet e há um número considerável de tentativas e propostas para resolver esse problema, incluindo: mobile IP, Internet indirection infraestructure [Stoica et al. 2004], host identify protocol [Moskowitz et al. 2005] e outros [Balakrishnan et al. 2004]. Assim, para a Internet do Futuro existem os seguintes desafios: aplicar soluções que permitam a localização global de um determinado host, através da utilização de um sistema de endereçamento global; definir novas formas de localização e identificação, além do desenvolvimento de endereçamentos coesos às necessidades da rede. e. Qualidade de Serviço e Qualidade de Experiência A natureza do IP, não orientado a conexão, dificulta qualquer aplicação de garantia de QoS (Quality of Service - qualidade de serviço). Além disso, a característica de encaminhamento de pacote baseado em melhor esforço faz com que qualquer abordagem

27 10 Minicursos Livro Texto relacionada a questões de reservar de recursos ou prioridade interfira no funcionamento estabelecido para Internet atual. Desta maneira, embora a qualidade de serviço tenha sido extremamente pesquisada na comunidade acadêmica ainda não há um modelo claro de como diferentes níveis de qualidade devem ser aplicados e de que forma ele se integrar arquitetura de rede atual. Desta fora, são desafios para arquitetura da Internet do Futuro: permitir uma variedade de garantias levando em consideração tanto a qualidade da aplicação na rede como a qualidade de experiência do usuário; novos métodos de encaminhamentos de pacote baseados nas características das aplicações, principalmente as de tempo real. f. Separação entre os Planos de Controle, Gerenciamento e Dados Na Internet atual, os planos de controle, gerenciamento e dados são unificados, ou seja, mensagens de controle, por exemplo, mensagens de conexão TCP (Transmission Control Protocol) ou mensagens de gerenciamento SNMP (Simple Network Management Protocol), seguem no mesmo canal em que trafegam os dados. Como consequência, ocorre a possibilidade de um significante risco de segurança dos dados de controle, além do desperdício de recursos da rede. Uma vantagem desta separação de planos é a adoção de novas tecnologias de plano de dados pela arquitetura de rede como: um comprimento de onda; quadro SDH; ou uma linha de transmissão de energia (Power Line Comunication - PLC). Logo a separação entre os planos deve ser parte integrante desta próxima geração da arquitetura da Internet. g. Isolamento Para algumas aplicações críticas, o usuário demanda isolamento em um ambiente compartilhado como na Internet atual. Isolamento significa garantir que o desempenho desta aplicação crítica não seja afetado por outras aplicações que queiram compartilhar o mesmo recurso. Com o uso da virtualização, o isolamento se tornou um fator ainda mais importante, principalmente para virtualização de redes, onde um roteador ou uma infraestrutura de rede é totalmente virtualizada, de forma que o encaminhamento de pacotes não pode, de maneira alguma, sofrer interferências de, ou causá-las em outras infraestruturas. Assim, a próxima geração da Internet deve prover em sua arquitetura um modo eficiente de prover uma combinação programável de isolamento e compartilhamento às suas aplicações e serviços.

28 XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos - SBRC h. Mobilidade Com a crescente e diversificada quantidade de serviços na Internet, impulsionada principalmente pelo aumento do acesso de dispositivos sem fio. Amplia-se a necessidade de mobilidade pelos usuários. Com isso, a forma de comunicação estabelecida originalmente pela arquitetura da Internet atual como conexão ponto-a-ponto e entrega imediata, faz com que esses tipos de usuários não sejam atendidos satisfatoriamente. Principalmente, por causa de uma questão comum relacionada à mobilidade, que são os handovers, criados com o objetivo de evitar que os nós móveis tenham a perda das suas conexões ativas. Os protocolos da Internet atual não prevêem o tratamento desse comportamento. E ainda, protocolos como TCP também são prejudicados por não prever esse tipo de usuário. Com isso, a Internet do Futuro enfrenta o grande desafio de como permitir a movimentação do nó entre diferentes pontos de acesso sem que as conexões ativas sejam perdidas. i. Escalabilidade Com o aumento exponencial do número de estações ou sistemas conectados à Internet, alguns componentes da arquitetura atual têm sofrido com problemas de escalabilidade. Esse é o caso do sistema de roteamento, que sofre com o aumento e as atualizações frequentes de suas tabelas. Ainda há a questão dos endereçamentos que não são capazes de suportar todos os elementos conectados à rede, como é o caso do IPv4. Portanto, a Internet do Futuro terá o desafio de manter o sistema global de roteamento escalável, além de novos protocolos que mantenham essa escalabilidade, mesmo com o aumento do espaço de endereçamento. E também novas formas de endereçamento para evitar a escassez do recurso Iniciativas para Investigação em Internet do Futuro Na comunidade de pesquisa em redes, há muito tempo atento ao crescimento de problemas da Internet, aumentou-se o interesse em estudar os desafios da Internet do Futuro e, com isso, modelar a arquitetura que conduzirá a um nova geração da Internet. No entanto, estas novas propostas e especulações teóricas na direção destas soluções deveriam ser suportadas por uma infraestrutura real de rede experimental e testadas em ambientes de larga escala. Estas instalações experimentais desempenhariam o papel de rede para experimentação ou ambiente de tese (testbed), possibilitando experimentos para a prova de conceitos de novas arquiteturas, protocolos, tecnologias e serviços. Uma coexistência com a rede de tráfego de produção é essencial para observação e captura de certos aspectos e fenômenos perceptíveis apenas em instalações operacionais e assim permitir que sejam avaliados os seus impactos sobre a sociedade e a economia. Observando essas necessidades, algumas iniciativas em pesquisa na Internet do Futuro começaram a surgir, em fiferentes cantos do mundo, conforme a seguir.

29 12 Minicursos Livro Texto GENI (Global Environment for Network Inovation) O Global Environment for Network Innovation (GENI) é a principal iniciativa norteamericana em investigação e experimentação em Internet do Futuro. O GENI é um conjunto de infraestruturas de redes para experimentação, dos mais variados modelos tais como: sem fio, óptico e elétrico. Patrocinado pela National Science Fundation (NSF) desde 2005, atualmente está em fase de desenvolvimento e prototipagem. O objetivo do GENI é montar um grande laboratório em larga escala para experimentações em redes de computadores, onde a maior importância é validar novas possibilidades para Internet do Futuro. Para o GENI, os conceitos principais relacionados à experimentação em Internet do Futuro e que fazem parte do projeto de sua arquitetura são [GENI-Sys 2008]: Programabilidade: Os pesquisadores poderão carregar software nos nós do GENI para modificar o seu comportamento; Virtualização e outras formas de compartilhamento de recursos: Qualquer que seja a implementação de máquina virtual sobre um nó GENI, será permitido que múltiplos pesquisadores simultaneamente compartilhem a mesma infraestrutura. Cada experimento terá à sua disposição uma fatia isolada, com recursos fim-a-fim alocados dentro do infraestrutura do GENI; Federação: O GENI será composto por infraestruturas próprias e por outras de apoio, operadas por organizações parceiras ao projeto, criando o conceito de uma federação de recursos e nós, que, na visão de um pesquisador, comportar-se-á como se fosse uma única infraestrutura; Experimentos baseados em fatias (Slices): Cada experimento no GENI será realizada sobre uma plataforma composta de um conjunto de recursos reservados em diversas localizações, chamada de uma fatia de recursos. Dentro dessa fatia o pesquisador poderá remotamente descobrir, reservar, configurar, depurar, operar e gerenciar seus experimentos e recursos disponíveis. Para se ter uma ideia de como o GENI irá funcionar após a sua concepção, a Figura 1.2 ilustra o fluxo que um pesquisador percorrerá para habilitar seu experimento dentro da infraestrutura do GENI. Na Figura 1.2 é ilustrado o processo que um pesquisador irá executar para solicitar e utilizar uma fatia para experimentação de seus modelos ou protocolos no ambiente GENI. Esse processo é formado por três estágios intermediários: descoberta de recurso, criação da fatia e experimentação. Na descoberta de recursos (DR), Figura 1.2(a), o pesquisador terá uma visão global dos recursos disponíveis para o seu experimento. A partir disso, poderá definir, de maneira simples, quais os recursos do GENI serão utilizados em seus experimentos. Na criação da fatia, Figura 1.2(b), o pesquisado recebe uma fatia ou contêiner vazio onde serão instanciados os recursos e o software que foram definidos pela DR.

30 XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos - SBRC Figura 1.2. A criação de um fatia sobre a infraestrutura do GENI [GENI-Sys 2008] Neste caso, uma fatia é uma integração de dois agregados: um cluster de computadores e uma rede ou um conjunto de redes. Por fim, na experimentação, Figura 1.2(c), o pesquisador poderá instalar os seus softwares, executar, parar e coletar resultados do experimento. O GENI pode ser visto como a confluência de vários grandes ambientes de teste, oferecendo alternativas para experimentação em redes. Dentre estes ambientes de teste podemos destacar: PlanetLab, ORBIT e EmuLab [Spiral2 2010] [Paul et al. 2011]. PlanetLab O PlanetLab [Peterson et al. 2006] é um grande laboratório para testes e desenvolvimento de aplicações distribuídas, criado a partir de 2002 por um consórcio de instituições acadêmicas, governamentais e industriais, que montou uma grande malha de computadores espalhados pelo mundo em diversas redes. Hoje, possui mais de 1050 máquinas espalhadas em mais de 550 locais diferentes, em todos os continentes (v. O projeto é dirigido a partir da Universidade de Princeton, EUA, mas há segmentos, por exemplo, na Europa, onde há outros centros de desenvolvimento e controle dos recursos comuns. O PlanetLab foi pioneiro no uso amplo dos conceitos de virtualização dos nós e de criação de fatias de recursos virtuais e dedicados nos nós usados num experimento. No Brasil há participação do consórcio desde 2004.

31 14 Minicursos Livro Texto No projeto GENI, o PlanetLab GENI [Spiral2 2010], será uma alternativa de rede para experimentação para seus pesquisadores. O grupo de Princeton dirige esta atividade e tem como escopo integrar logicamente os componentes GENI aos serviços PlanetLab como: PLC (PlanetLab Central Sofware), responsável por criar a rede sobreposta definindo a topologia virtual que será usada para experimento; e o SFA (Slice-Based Facility Architecture), responsável por localizar e alocar os recursos para os experimentos [Peterson et al. 2009]. ORBIT O projeto ORBIT provê um rede sem fio flexível aberto à comunidade acadêmica para experimentação. Ele foi desenvolvido para que pesquisadores entendessem as limitações do mundo real das redes sem fio, que muitas vezes não são percebidas em simulações por causa das simplificações aplicadas ao modelo ou por terem sido aplicadas em uma quantidade pequenas de nós. O ORBIT possui dois ambientes de teste no campus da Universidade Rutgers: o primeiro é dentro de um laboratório, constituído por 400 nós dispostos em uma grade 20x20 (ilustrado na Figura 1.3), separados por um metro de distância entre os nós adjacentes, onde cada nó é composto por uma plataforma PC com múltiplas interfaces sem fio e com fio. O segundo está localizado ao ar livre, numa área de 1,5 hectares. Entre eles existem nós fixos, e também nós móveis para prover mobilidade entre os roteadores (v. Figura 1.3. ORBIT Testbed Indoor No GENI, sua integração permitirá que pesquisadores gerenciem esse ambiente de redes sem fio dentro do GENI, além estender a capilaridade de nós do ORBIT para outros ambientes sem fio. No GENI, o ORBIT será integrado dentro do ambiente OMF (control and Management Framework) [OMF 2011].

32 XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos - SBRC EmuLab EmuLab [Eide et al. 2006] é um ambiente de teste em redes de computadores que oferece aos seus pesquisadores um leque de ambientes nos quais eles podem desenvolver, analisar e avaliar seus sistemas. O nome EmuLab refere-se tanto ao ambiente de teste quanto ao software de interação do usuário com ele. O projeto é gerenciado pela Universidade de Utah, onde foram desenvolvidos os primeiros nós do EmuLab. Atualmente, há mais de doze países utilizando o EmuLab, totalizando uma rede para experimentação com mais de cem nós. No Brasil, há um nó desta rede instalado na USP (v. Na Figura 1.4 temos os clusters de computadores utilizados pelo EmuLab. Os ambientes disponíveis no EmuLab são: Emulação (Emulation), neste ambiente, o pesquisador define uma topologia arbitrária com switches ou roteadores e nós PC; Live-Internet, onde o Emulab oferece um ambiente federado para experimentos sobre Internet; No Wireless, provê um ambiente com ponto de acesso, roteadores e cliente para experimentos em rede sem fio; e o ambiente Software-Defined Radio o qual permite experimentações em camada 1 para análise de processamento de sinal. Figura 1.4. Cluster EmuLab No GENI, a integração do EmuLab ao projeto deu origem a um subprojeto conhecido como ProtoGENI [ProtoGENI 2011], e permitirá ao EmuLab expandir ainda mais seu ambiente de teste, além de controlar novos não oferecidos atualmente, por exemplo, à infraestrutura de altíssima velocidade da rede Internet2.

33 16 Minicursos Livro Texto Future Internet Research and Experimentation (FIRE) A iniciativa FIRE (Future Internet Research and Experimentation) na Europa visa a pesquisa experimental e ao financiamento de projetos que produzam infraestruturas para experimentação em Internet do Futuro. A meta é que as pesquisas em tecnologias para Internet do Futuro sejam direcionadas à rede ou a serviço e tenham a possibilidade de comparar as soluções correntes com as propostas futuras. Desta forma, afirma-se que o FIRE possui duas dimensões relacionadas que direcionam suas pesquisas e seus investimentos [FIRE 2008]: Pesquisa Experimental: o objetivo é integrar a pesquisa multidisciplinar e a experimentação em larga escala. A partir daí, definir uma metodologia que direcionará pesquisa experimental na infraestrutura FIRE, baseada em um ciclo interativo que vai da pesquisa, passando pelo projeto e chegando à experimentação; Facilidades para Testes: o objetivo é oferecer múltiplos ambientes de teste, suportando várias tecnologias e interligados e federados entre si para permitir a realização de experimentos envolvendo dois ou mais dos ambientes distintos. Deste modo pretende-se que FIRE seja sustentável, renovável, dinâmico e integrado em larga escala. Deverá ainda facilitar a pesquisa experimental na comunidade acadêmica, nos centros de pesquisa e na indústria. Para o FIRE, as experiências práticas são essenciais para dar credibilidade e levantar o nível de confiança na conclusão da pesquisa. Além disso, a experimentação deve ser executada em larga escala para que seja representativa, convincente e, para provar a escalabilidade da solução, testada. Os projetos de ambiente de teste em destaque aqui, financiados pela iniciativa FIRE incluem [FIRE 2010]: BonFIRE, CREW e OFELIA. BonFIRE A iniciativa BonFIRE (Building Services Testbeds on FIRE) [BonFIRE 2011] é um projeto baseado em nuvens em múltiplos locais para o suporte à pesquisa de aplicações, serviços e sistemas, visando a Internet de Serviços dentro da Internet do Futuro. O Bon- FIRE objetiva oferecer aos pesquisadores acesso a um ambiente experimental em larga escala para experimentação de seus sistemas e aplicações, avaliações do efeito crosscutting da convergência dos serviços, infraestrutura de rede e a análise do impacto socioeconômico. O BonFIRE irá operar uma nuvem baseada em IaaS (Infrastructure as a Service) com políticas e melhores práticas de experimentações. Ele irá se adaptar a uma abordagem multiplataforma federada provendo interconexão e interoperação entre os serviços e a rede no ambiente de teste. A plataforma irá oferecer serviços avançados e ferramentas para pesquisa de novos serviços, incluindo nuvens de federações, gerenciamento de máquinas virtuais, modelagem, gerenciamento do ciclo de vida a experimentação, monitoramento da qualidade de serviço e análise de desempenho.

34 XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos - SBRC CREW O principal objetivo do CREW (Cognitive Radio Experimentation World) [CREW 2011] é estabelecer uma plataforma de teste aberta e federada que facilite o avanço em pesquisa em sensoriamento de espectros, rádios cognitivos e estratégias de redes cognitivas em visões horizontais e verticais do espectro compartilhado em bandas licenciadas e não licenciadas. A Figura 1.5 ilustra a topologia e as tecnologias utilizadas no ambiente de teste. Figura 1.5. Ambiente federado CREW [FIRE 2010] O CREW incorpora quatro ambientes individuais de teste de rede sem fio utilizando um leque de tecnologias sem fio como: heterogêneos ISM, Celular e Sensores sem fio, com o estado da arte de plataforma de sensoriamento cognitivo. O CREW irá fisicamente e virtualmente federar componentes interligando entidades de software e hardware de diferentes padrões usando APIs padronizadas. Além disso, o CREW estabelecerá um benchmark framework (arcabouço de controle padrão), habilitará experimentos controlados, metodologias para análise automática de performance e reproduzirá condições para teste. OFELIA O projeto OFELIA [OFELIA 2011] visa criar um ambiente para experimentação que também permita a seus pesquisadores o controle a redes da sua maneira de forma precisa e dinâmica. Para alcançar isso, o ambiente OFELIA é baseado em OpenFlow, atualmente uma tecnologia de rede emergente que permite virtualizar e controlar ambientes de rede através de interfaces seguras e padronizadas (v. seção 4.3.1). O OFELIA proverá equipamentos OpenFlow de alto desempenho para habilitar experimentos em alta escala. A infraestrutura federada pelo OFELIA inclui ilhas (ambientes de teste locais) OpenFlow na Bélgica, Alemanha, Espanha, Suíça e Reino Unido. Essas ilhas reúnem uma diversidade de infraestruturas baseadas em OpenFlow que permitirá experimentações em

35 18 Minicursos Livro Texto redes multicamadas e multitecnologicas. Na Figura 1.6 é apresentada como a estrutura dessas ilhas serão instaladas em cada um desses países. Figura 1.6. Estrutura de uma ilha, baseada em OpenFlow no projeto OFE- LIA [OFELIA 2011] O OFELIA permitirá o teste de novos algoritmos de roteamento, tunelamento, protocolos e planos de controle. Além disso, novas aplicações poderão ser colocadas no controlador OpenFlow a qualquer momento na infraestrutura. Também permitirá serem investigadas novas estruturas e formatos de endereçamento e modelos de encaminhamentos Iniciativas Brasileiras Os parceiros brasileiros contribuem no projeto com a experiência na implantação de instalações de experimentações locais e na participação em diferentes projetos de pesquisa experimental em Internet do Futuro, embora com pouca ou nenhuma coalizão estratégica entre elas. O primeiro desses projetos a destacar-se é o de pesquisa e desenvolvimento GIGA e suas instalações experimentais em grande escala conhecido como rede GIGA, coordenado conjuntamente pelo CPqD e a RNP [Scarabucci et al. 2005]. O projeto GIGA atualmente se concentra em redes ópticas e as definidas por software. Deverá ser atualizado em breve com comutadores OpenFlow de 10G (o primeiro na América do Sul) e uma solução aberta ( open-source ) de roteamento de pacotes (o primeiro do mundo e neste momento disponível para parceiros selecionados nos EUA e no Brasil) que roda sobre o NOX para controlar o encaminhamento de pacotes em redes com tecnologia OpenFlow habilitada. A rede GIGA conecta mais de 66 laboratórios de 23 instituições da Região Sudeste do Brasil e está conectada com a rede nacional da RNP (Rede Ipê). Através desta, interliga-se com redes de pesquisa e ensino em todo o mundo. A rede GIGA mantém um nó GENI, ou seja, servidores, no CPqD. O segundo projeto de destaque é o projeto Web Science [WEBSCIENCE, 2010],

36 XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos - SBRC apoiado pelo CNPq dentro do programa Institutos Nacionais de Ciência e Tecnologia (INCT). O projeto Web Science começou efetivamente em 2010 e o subprojeto de Arquiteturas para a Internet do Futuro envolve a RNP, e 4 Universidades parceiras (UFF, UFPA, UNIFACS e USP), com experiência em redes ópticas e sem fio, estudos de simulação e emulação e monitoramento de rede. Um dos primeiros objetivos do projeto é estabelecer ilhas experimentais nos laboratórios de cada parceiro e interligá-las em camada 2 através das redes de Ipê e GIGA OpenFlow e Virtualização O OpenFlow A pesquisa na área de arquiteturas de redes de computadores possui diversos desafios em relação à implementação e experimentação de novas propostas em ambientes reais. Isso ocorre devido à dificuldade para o pesquisador possuir uma rede de testes próxima de uma rede real. Para isso foi desenvolvido o OpenFlow [McKeown et al. 2008], que propõe um mecanismo para permitir que redes reais sejam utilizadas como um ambiente de experimentos. O OpenFlow é uma proposta tecnológica que, baseada na separação dos planos de controle e de dados em comutadores de pacotes, permite que pesquisadores executem seus experimentos em redes utilizadas no dia-a-dia, sem interferir no tráfego de produção. A proposta é fundamentado em comutadores Ethernet comerciais e define um protocolo padrão para controlar o estado destes comutadores (tabela de fuxos, estatísticas e etc.). O conceito de fluxo é o bloco fundamental que habilita aos pesquisadores definir o plano de encaminhamento na rede, conforme os objetivos definidos pelas novas propostas de arquiteturas e protocolos de rede. O OpenFlow também define um novo elemento de rede, o controlador, e software de controle que executa nele, entre os quais o software NOX criado pelo grupo OpenFlow da U. Stanford (v. Seção ). No OpenFlow é proposto um mecanismo que é executado em todos os comutadores ou roteadores de forma que se possa haver isolamento entre os tráfegos, o experimental e o de produção. Assim, o OpenFlow possibilita que os pesquisadores reprogramem os comutadores, sem provocar interferência na configurações da rede de produção. Outro objetivo dessa proposta é permitir que os fabricantes possam incluir as funcionalidades do OpenFlow nos seus comutadores sem necessitarem expor o projeto desses equipamentos. Além disso, tais equipamentos devem possuir um custo baixo e desempenho semelhante aos já utilizados nas redes de produção, tanto nas universidades como nas redes de pesquisa, de forma que os administradores destas redes aceitem a substituição dos equipamentos já existentes. Com base no exposto, o projeto do OpenFlow tem como objetivo ser flexível para atender aos seguintes requisitos: possibilidade de uso em implementação de baixo custo e de alto desempenho; capacidade de suportar uma ampla gama de pesquisas científicas; garantia de isolamento entre o tráfego experimental e o tráfego de produção;

37 20 Minicursos Livro Texto consistência com a necessidade dos fabricantes não exporem o projeto de suas plataformas. O OpenFlow explora a tabela de fluxo que já existe nos comutadores atuais, e normalmente são utilizadas para implementar serviços como NAT, firewall e VLANs. O comutador OpenFlow é constituído de uma tabela de fluxos e um evento associado a cada entrada na tabela. Basicamente, a arquitetura do OpenFlow é composto por três partes: Tabela de Fluxos: Cada entrada na tabela de fluxos contém uma ação associada, e consiste em Campos do cabeçalho (utilizado para definir um fluxo), ações (define como os pacotes devem ser processados e para onde devem ser encaminhados) e contadores (utilizados para estatísticas ou remoção de fluxos inativos). Canal Seguro: Para que a rede não sofra ataques de elementos mal intencionados, o Secure Channel assegura confiabilidade na troca de informações entre o comutador e o controlador. A interface utilizada para acesso ao tráfego é o protocolo Secure Socket Layer (SSL). O NOX também suporta outras interfaces (passivas ou ativas), TCP e PCAP. Essas são bem úteis em ambientes virtuais, pela simplicidade de utilização, pois não necessitam de chaves criptográficas. Protocolo OpenFlow: Disponibiliza um protocolo aberto para estabelecer a comunicação entre o comutador e o controlador. Ao fornecer uma interface externa que atue sobre os fluxos de um comutador, o Protocolo OpenFlow (OFP - OpenFlow Protocol) evita a necessidade de um comutador programável Aplicações Como visto anteriormente, o OpenFlow permite o experimento de novas propostas na área de Redes de Computadores, utilizando uma infraestrutura de rede já existente. Dentre os possíveis experimentos permitidos, podem ser citados os seguintes [McKeown et al. 2008]: Novos Protocolos de Roteamento: Os algoritmos de um protocolo de roteamento podem ser implementados para executarem no controlador de uma rede OpenFlow. Assim, quando um pacote do experimento chegar a um comutador, ele é encaminhado para o controlador, que é responsável por escolher a melhor rota para o pacote seguir na rede a partir dos mecanismos do protocolo de roteamento proposto. Após isso, o controlador adiciona entradas na Tabela de Fluxos de cada comutador pertencente à rota escolhida. Os próximos pacotes desse fluxo que forem encaminhados na rede não necessitarão serem enviados para o controlador; Mobilidade: Uma rede OpenFlow pode possuir pontos de acesso sem-fio, permitindo que clientes móveis utilizem sua infraestrutura para se conectarem a Servidores ou à Internet. Assim, mecanismos de handoff podem ser executados no Controlador realizando alteração dinâmica das tabelas de fluxo dos comutadores de acordo com a movimentação do cliente, permitindo a redefinição da rota utilizada;

38 XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos - SBRC Redes Não-IP: Como visto anteriormente, um comutador OpenFlow pode ser desenvolvido para analisar campos arbitrários de um pacote, permitindo flexibilidade na definição do fluxo. Assim, podem ser testadas, por exemplo, novas formas de endereçamento e roteamento. Nos comutadores do tipo 0, os pacotes Não-IP podem ser definidos pelo endereço MAC de origem ou destino ou a partir de um novo Tipo de Ethernet ou IP; Redes com Processamento de Pacotes: Existem propostas de protocolos que realizam processamento de cada pacote de um fluxo como, por exemplo, os protocolos de Redes Ativas. Esse tipo de proposta pode ser implementado no OpenFlow forçando que cada pacote que um comutador receba seja enviado para o Controlador para ser processado. Outra alternativa é enviar esses pacotes para processamento por um comutador programável, como é o caso de um roteador programável baseado em NetFPGA [Lockwood et al. 2007] Modos de funcionamento dos Switch Existem dois tipos de comutadores OpenFlow. O primeiro consiste em um comutador OpenFlow dedicado, que não suporta encaminhamento comum de Nível 2 e Nível 3. O segundo tipo consiste em um comutador ou roteador comercial com OpenFlow habilitado que, além de suportar as funcionalidades do OpenFlow, realiza as funções comuns de um comutador ou roteador. Esses dois tipos são detalhados abaixo. Comutador OpenFlow Dedicado Esse tipo de comutador, exemplificado na Figura 1.7, é um elemento que apenas encaminha o tráfego entre as portas do comutador de acordo com a Tabela de Fluxos configurada remotamente via controlador. O fluxo pode ser definido de diferentes formas, por exemplo, um fluxo pode ser definido como todos os pacotes provenientes de certa porta TCP ou os pacotes com um determinado endereço MAC de destino. Além disso, alguns comutadores OpenFlow podem tratar pacotes que não utilizam o IPv4, verificando campos arbitrários de seu cabeçalho. Isso mostra a flexibilidade do OpenFlow para suportar diferentes tipos de experimentos. Para cada entrada da tabela de fluxos é definida uma ação para ser tomada com os pacotes oriundos de um determinado fluxo. As três ações básicas que todos Comutadores OpenFlow devem suportar são as seguintes: encaminhar os pacotes do fluxo para uma ou várias portas específicas. Isso permite que os pacotes sejam roteados pela rede; encapsular os pacotes e encaminhá-los para o Controlador utilizando o Canal Seguro de comunicação. Essa ação pode ser executada no momento do envio do primeiro pacote de um fluxo, que ainda não tenha sido definido nas Tabelas de Fluxo dos comutadores, com o objetivo do Controlador configurar os comutadores

39 22 Minicursos Livro Texto Figura 1.7. Comutador OpenFlow Dedicado com esse novo fluxo. Além disso, a ação pode ser realizada em um experimento no qual é necessário processamento adicional nos pacotes de um fluxo; descartar o pacote. Essa ação pode ser utilizada em aplicações de segurança para impedir, por exemplo, ataques de negação de serviço. Uma entrada na Tabela de Fluxos possui três campos, como apresentado na Figura 1.8a. O primeiro identifica o cabeçalho que define o fluxo. Por exemplo, no cabeçalho dos comutadores OpenFlow (comutadores tipo 0 ), um fluxo pode ser definido por 10 parâmetros. Esses parâmetros podem ser o MAC e IP de origem ou destino, as portas TCP usadas, entre outros como mostra a Figura 1.8b. Em outras gerações de comutadores OpenFlow, esses parâmetros podem ser definidos arbitrariamente, permitindo o experimento de protocolos que não utilizam o IP. (a) (b) Figura 1.8. Cabeçalhos que definem um fluxo em comutadores do tipo 0.

40 XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos - SBRC O segundo campo identifica a ação a ser tomada e o terceiro armazena as estatísticas do fluxo. Essas estatísticas podem ser o número de pacotes ou bytes referentes ao fluxo que passaram pelo comutador e o intervalo de tempo desde a última vez em que um pacote do fluxo foi identificado pelo comutador. Esse último é importante, por exemplo, para remoção de um fluxo da tabela caso esteja inativo. Comutador com OpenFlow Habilitado Esse tipo de comutador consiste nos equipamentos que já realizam encaminhamento normal de Nível 2 e Nível 3, mas adicionaram o OpenFlow com uma funcionalidade. Assim, o tráfego de produção pode ser encaminhado utilizando o encaminhamento normal e permanece isolado do tráfego experimental, que utiliza o mecanismo do OpenFlow. Para isso, esses comutadores podem adicionar outra ação além das três ações básicas citadas anteriormente: encaminhar os pacotes do fluxo pelo pipeline normal do comutador. Nessa ação, um fluxo identificado como não sendo referente ao OpenFlow será processado utilizando o encaminhamento normal. Como alternativa ao uso da ação anterior, um comutador pode isolar o tráfego de produção do tráfego OpenFlow através do uso de VLANs. Alguns comutadores podem suportar tanto essa alternativa como a outra Controle usando NOX O NOX [Gude et al. 2008] é uma proposta de sistema operacional para redes, possuindo como objetivo facilitar o gerenciamento de redes de grande escala. O conceito de sistema operacional de rede pode ser entendido pela analogia com os sistemas operacionais utilizados nos computadores. As ideias básicas dos sistemas operacionais de computadores são oferecer uma interface de alto nível para as aplicações utilizarem os recursos de hardware e também controlar a interação entre essas aplicações. A interface de alto nível tornou os programas mais fáceis de serem desenvolvidos e de executarem em diferentes plataformas de hardware. Isso ocorre porque os programadores não precisam mais se preocupar com interações de baixo nível da aplicação com o hardware e podem escrever seus programas utilizando primitivas genéricas que funcionam em diversas arquiteturas. Em redes de computadores, o gerenciamento é realizado por configurações de baixo nível que depende do conhecimento da rede, análogo às aplicações desenvolvidas sem os sistemas operacionais. Como exemplo, o controle de acesso aos usuários de uma rede utilizando uma ACL (Access Control List - Lista de Controle de Acesso), necessita do conhecimento do endereço IP do usuário, que é um parâmetro de baixo nível dependente da rede.

41 24 Minicursos Livro Texto Portanto, existe a necessidade de um sistema operacional de redes que forneça interfaces para controlar e observar uma rede, semelhantes às interfaces de leitura e escrita em diversos recursos oferecidos através de um sistema operacional de computador [Gude et al. 2008]. Assim, o sistema operacional de redes deverá fornecer uma interface genérica de programação que permite o desenvolvimento de aplicações de gerenciamento da rede. Esse sistema centraliza o gerenciamento da rede, necessitando haver uma grande preocupação com sua escalabilidade. O NOX é um sistema operacional de rede que procura atender os requisitos já citados. Esse sistema foi desenvolvido para ser executado nos controladores de redes OpenFlow. Apesar do objetivo principal do OpenFlow ser o experimento de novas propostas, o NOX pode ser utilizado também no gerenciamento de redes de produção. A Figura 1.9 ilustra os principais componentes de uma rede baseada no NOX. Esse tipo de rede possui um ou mais servidores executando o NOX. Cada um realiza o papel do controlador OpenFlow. Esses controladores possuem aplicações executando a partir do NOX. Todos os controladores compartilham uma única visão da rede, que é mantida na base de dados de um dos servidores. Figura 1.9. Componentes de uma rede baseada no NOX A visão da rede é montada com base em informações da rede coletadas pelo NOX e é usada na tomada de decisões pelas aplicações de gerenciamento. As informações coletadas podem ser a topologia dos comutadores, a localização dos elementos da rede (ex. usuários, clientes, middleboxes) e os serviços oferecidos (ex. HTTP ou NFS). As aplicações irão manipular o tráfego da rede a partir da configuração remota dos comutadores OpenFlow. Esse controle é realizado no nível de fluxo, ou seja, sempre quando um determinado controle é realizado no primeiro pacote de um fluxo todos os outros pacotes desse fluxo sofrerão a mesma ação. O funcionamento da rede baseada no NOX ocorre da seguinte forma: ao receber um pacote, o comutador verifica o cabeçalho do pacote para ver se ele está definido em sua Tabela de Fluxos. Se estiver definido, o comutador executa a ação especificada na Tabela

42 XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos - SBRC de Fluxos e atualiza os contadores referentes à estatística do fluxo. Senão, encapsula o pacote e o envia para o NOX. O NOX então será responsável por adicionar uma entrada na Tabela de Fluxos do comutador, identificando o fluxo referente aquele pacote. Dependendo da aplicação, o NOX pode não adicionar essa entrada, forçando que os comutadores enviem sempre para o NOX os pacotes que receberem. Como exemplo de aplicação que pode ser desenvolvida para o NOX, pode ser citado o gerenciamento de consumo de energia [Gude et al. 2008]. Por exemplo, nesse tipo de gerenciamento, pode ser reduzida a velocidade de enlaces subutilizados ou esses enlaces podem ser simplesmente desligados. Com a Visão da Rede do NOX, na qual é conhecida uma visão global da rede e as rotas em uso, pode-se adquirir conhecimento necessário para realizar tais ações. Além disso, essas ações podem ser auxiliadas por aplicações desenvolvidas para o NOX, como redução de velocidade dos enlaces ou migração dos fluxos de um comutador que será desligado para outro comutador em uso. Além do NOX ainda há outro tipos de controladores para redes OpenFlow, como é caso do BEACON [BEACON 2011] que é baseado na linguagem JAVA, e do DIFANE [Yu et al. 2010] que é um controlador distribuído Virtualização A virtualização é uma técnica que permite que um sistema execute processos oferecendo a cada um deles a ilusão de executar sobre recursos dedicados. Inicialmente um mecanismo de isolamento, ela representa um fator de uso eficiente da crescente capacidade computacional disponível [Egi et al. 2010] e a integra arquiteturas onde elementos comuns a um conjunto de processos virtualizados possuem apenas uma cópia em execução, acessada de forma compartilhada [Bhatia et al. 2008]. O conceito foi estendido do âmbito de nós para os demais elementos de uma rede de computadores, dando origem à virtualização de redes [Chowdhury and Boutaba 2010]. Em um processo paralelo àquele descrito para a virtualização tradicional, a aplicação da virtualização de redes passou a permitir que os componentes de uma rede física particionassem sua capacidade de maneira a realizar simultaneamente múltiplas funções, estabelecendo infraestruturas lógicas distintas e mutuamente isoladas. Assim como no caso da virtualização de sistemas, a virtualização de redes também permitiu que as arquiteturas de redes se tornassem mais eficientes. Funções que tradicionalmente eram gerenciadas de forma distribuída passaram a ser projetadas para uma execução e administração centralizadas. É o caso do encaminhamento do tráfego IP: podem ser encontradas arquiteturas do estado-da-arte [Nascimento et al. 2010] em que decisões de roteamento, originalmente tomadas de forma local por nós especializados, são encaminhados por comutadores a um sistema controlador, que executa em memória uma versão virtualizada da rede e dos respectivos elementos roteadores. Deriva decisões da base de informações de roteamento construída pela execução desta rede virtual e as transmite aos comutadores, que reagem de acordo.

43 26 Minicursos Livro Texto Virtualização de Sistemas Uma solução de virtualização fornece aos sistemas, executando sob sua supervisão, a abstração de um ambiente computacional exclusivo sobre o qual eles estão operando (nó convidado ), quando de fato tem-se um computador ( anfitrião ) cujos recursos foram partilhados entre esses mesmos sistemas. Pode-se realizar a virtualização de sistemas de duas formas: a virtualização completa, em que cada convidado executa seu sistema operacional, e a virtualização baseada em containers, em que o sistema operacional do anfitrião distribui e isola os recursos disponíveis entre os sistemas convidados [Bhatia et al. 2008]. Ainda segundo Bhatia [Bhatia et al. 2008], na virtualização completa, ilustrada na Figura 1.10, o anfitrião executa um Monitor de Máquinas Virtuais - MMV, também chamado hypervisor. É responsabilidade do MMV prover abstração de hardware (chamada de máquina virtual) para que seja possível executar o sistema operacional convidado, bem como mapear cada requisição dos convidados a seus respectivos dispositivos virtuais, para o elemento físico correspondente. Figura Virtualização Completa Também existe uma variação desta técnica chamada paravirtualização, que consiste em otimizar a emulação de hardware provida pelo MMV com vistas a um ganho de desempenho. Nesta abordagem, porém, os sistemas operacionais convidados devem ser modificados para que possam ser executados, o que não acontece na virtualização completa. Em um sistema baseado em containers, apresentado na Figura 1.11, uma imagem de sistema operacional virtualizada é compartilhada entre todos os convidados - o que pode ser especialmente eficiente em cenários em que se deseja apenas executar de forma isolada diversas cópias do mesmo software. Ainda assim, os nós virtuais podem ser individualmente gerenciados, tal como na virtualização completa.

44 XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos - SBRC Figura Virtualização utilizando Container A virtualização é empregada através de ferramentas que apresentam diferenças entre si e possuem suas vantagens e desvantagens. Atualmente, há uma gama enorme de softwares livres e empresas que fornecem soluções com esse conceito. Neste minicurso, são comentados apenas as ferramentas Xen e o OpenVz, por serem as mais relevantes no contexto atual. XEN O Xen é um monitor de máquina virtual (VMM ou hypervisor), em software livre, para arquiteturas x86. Originário de um projeto de pesquisa da Universidade de Cambridge, sua primeira versão foi criada em 2003, quatro anos antes de ser comprada pela Citrix System, em Ele apresenta uma solução para virtualização um pouco diferente das conhecidas. Seu conceito consiste em criar um hypervisor, responsável por controlar os recursos das máquinas virtuais, mas que não possui drivers de dispositivos. Dessa forma, não é possível rodar um sistema operacional diretamente no hypervisor. Assim, faz-se necessário que um sistema seja invocado para fazer a comunicação entre o hypervisor e os sistemas hóspedes. A Figura 1.12 apresenta uma visão geral do Xen. Esse sistema inicial chama-se domínio 0. Ele consiste em uma máquina virtual que executa um núcleo Linux modificado e possui privilégios para acessar dispositivos de entrada e saída às outras máquinas virtuais, onde podem rodar outros sistemas operacionais, chamados domínio U. Elas são criadas, inicializadas e desligadas através do domínio 0. Possuem um driver virtual para acesso aos recursos de hardware. O domínio 0 possui os drivers dos dispositivos da máquina física, além de dois drivers especiais que tratam as requisições de acesso à rede e ao disco enviadas pelas

45 28 Minicursos Livro Texto Figura Visão Geral do Arquitetura XEN máquinas virtuais. Assim, toda requisição de uso da máquina real feita por uma máquina do domínio U deve ser tratada pelo domínio 0 antes de ser enviada ao hypervisor. Originalmente, o Xen foi desenvolvido com o objetivo de implementar a técnica de para-virtualização, e, para isso, era necessário modificar os sistemas hóspedes para darlhes a consciência de rodarem sobre um hypervisor. Essa estratégia foi tomada visando ganhos em desempenho, mas limitou a difusão do Xen aos sistemas Unix, de código aberto. OPENVZ O OpenVZ é uma solução de virtualização em nível de sistema operacional. Cria ambientes virtuais isolados, que funcionam como servidores convencionais, porém, utilizando um único hardware em comum. Estes ambientes virtuais seguros são conhecidos como VE (Virtual Environment) ou como VPS (Virtual Private Server). VPS s podem ser reinicializados independentes uns dos outros. Todos possuem hostname, root access e endereço IP próprio, ou seja, o que um servidor real normalmente possui, sendo assim uma solução extremamente confiável e funcional de virtualização. As capacidades básicas dos VPS s são: Dynamic Real-time Partitioning: artição de um único servidor físico em dezenas de VPSs, cada um com funcionalidade total; Resource Management: atribuição e controle dos recursos dos VPSs. Realocação de recursos em tempo real; Mass Management: gerenciamento unificado de uma grande quantidade de servidores físicos e virtuais (VPSs). Como pode ser visto na Figura 4.13, um servidor físico pode conter diversos VPS s

46 XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos - SBRC Figura Arquitetura de virtualização utilizada pelo openvz (Virtual Private Servers). Cada VPS possui isolamento total uns dos outros, inclusive com uma visão única de seus Ambientes Virtuais (VE s). O OpenVZ provê uma solução para Provedor de Serviços de Hospedagem possibilitando que: Centenas de usuários possuam seus próprios servidores privados (Virtual Private Servers) compartilhando um único servidor físico; Provê para cada usuário uma garantia de qualidade de serviço; Transferência transparente dos ambientes virtuais dos usuários para outros servidores físicos, sem nenhum tipo de reconfiguração manual. O Virtual Private Server se comporta como um único servidor, onde: Cada VPS possui seus próprios processos, usuários e provê acesso completo de root via shell Cada VPS possui seu próprio endereço IP, número de portas, firewall e roteamento; Cada VPS possui seus próprios arquivos de configuração para o sistema e aplicações, como também suas próprias bibliotecas de sistema Virtualização de Redes Assim como a virtualização provê o compartilhamento de recursos de um nó computacional por múltiplos sistemas, a virtualização de redes (VR) é um método para que múltiplas arquiteturas de rede heterogêneas compartilhem o mesmo substrato físico - neste caso, componentes de uma rede como roteadores, comutadores, etc.

47 30 Minicursos Livro Texto Segundo Chowdhury [Chowdhury and Boutaba 2010], existem quatro abordagens para a implementação de VR: as Redes Locais Virtuais (VLANs), as Redes Privadas Virtuais (VPNs) e as redes de sobreposição (Overlay). Em [Sherwood et al. 2010a], apresenta-se uma quarta, a partir do conceito de redes programáveis. Redes Locais Virtuais (VLANs) Uma VLAN é um agrupamento lógico de dispositivos ou usuários que podem ser unidos por função, departamento ou aplicativo, independentemente da localização de seus segmentos físicos. A configuração de VLANs é feita no comutador, e possivelmente no roteador, através de software proprietário do fabricante. Com efeito, numa rede local a comunicação entre as diferentes máquinas é governada pela arquitetura física. Graças às redes virtuais (VLANs), é possível livrar-se das limitações da arquitetura física (constrangimentos geográficos, restrições de endereçamento, etc), definindo uma segmentação lógica (software), baseada num agrupamento de máquinas com critérios como endereços MAC, números de porta ou protocolo. Foram definidos vários tipos de VLAN, de acordo com o critério de comutação e o nível em que se efetua: VLAN de nível 1 (Port-Based VLAN) - define uma rede virtual em função das portas de conexão no comutador; VLAN de nível 2 (MAC Address-Based VLAN) - consiste em definir uma rede virtual em função dos endereços MAC das estações; VLAN de nível 3 - distinguem-se vários tipos de VLAN de nível 3: VLAN por sub-rede (Network Address-Based VLAN), que associa sub-rede de acordo com o endereço IP fonte dos datagramas e VLAN por protocolo (em inglês Protocol- Based VLAN) que permite criar uma rede virtual por tipo de protocolo, por exemplo: TCP/IP, IPX e AppleTalk, agrupando assim todas as máquinas que utilizam o mesmo protocolo numa mesma rede. A VLAN permite definir uma nova rede acima da rede física e a esse respeito oferece mais flexibilidade para a administração e modificações da rede porque qualquer arquitetura pode ser alterada por simples parametrização dos comutadores. E ainda, um ganho em segurança, porque as informações são encapsuladas em um nível suplementar e são eventualmente analisadas. A VLAN oferece também redução da divulgação do tráfego sobre a rede. Redes Privadas Virtuais (VPNs) A ideia de utilizar uma rede pública como a Internet em vez de linhas privativas para implementar redes corporativas é denominada de VPN (Virtual Private Network) ou Rede Privada Virtual. As VPNs são túneis seguros entre pontos autorizados, criados através da

48 XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos - SBRC Internet ou outras redes públicas e/ou privadas para transferência de informações, com proteção criptográfica, entre redes corporativas ou usuários remotos. A segurança é a primeira e mais importante função da VPN. Uma vez que dados privados serão transmitidos pela Internet, que é um meio de transmissão inseguro, eles devem ser protegidos de forma a não permitir que sejam modificados ou interceptados. Outro serviço oferecido pelas VPNs é a conexão entre corporações, as Extranets, através da Internet, além de possibilitar conexões discadas e cifradas que podem ser muito úteis para usuários móveis ou remotos, bem como filiais distantes de uma empresa. Uma das grandes vantagens decorrentes do uso das VPNs é a redução de custos com comunicações corporativas, pois elimina a necessidade de enlaces dedicados de longa distância que podem ser substituídos pela Internet. As LANs podem, através de enlaces dedicados ou discados, conectarem-se a algum provedor de acesso local e interligarem-se a outras LANs, possibilitando o fluxo de dados através da Internet. Esta solução pode ser bastante interessante sob o ponto de vista econômico, sobretudo nos casos em que enlaces internacionais ou nacionais de longa distância estão envolvidos. Outro fator que simplifica a operacionalização da WAN é que a conexão LAN-Internet-LAN fica parcialmente a cargo dos provedores de acesso Redes de Sobreposição (Overlay) Uma rede de sobreposição é uma rede virtual que cria uma topologia virtual no topo da topologia física de outras redes. Os nós em uma rede de sobreposição são unidos por meio de ligações virtuais que correspondem a caminhos na rede subjacente. Na Figura 1.14 ilustra essa afirmação, na camada IP os nós correspondem aos roteadores e sistemas terminais, enquanto na camada Overlay, que é uma rede de sobreposição, tem-se a topologia virtual. As redes de sobreposição são tipicamente programadas na camada de aplicação, embora várias implementações nas camadas inferiores da pilha de redes o faça existir. As redes de sobreposição não são restritas geograficamente e são bastante flexíveis e adaptáveis a mudanças, se comparadas a qualquer outra rede. Como resultado, as redes sobrepostas têm sido usadas para implantar novos recursos e extensões na Internet. Figura Modelo de Rede de Sobreposição

49 32 Minicursos Livro Texto Muitos modelos de sobreposição têm sido propostos nos últimos anos para resolver problemas que incluem: desempenho assegurado [Savage et al. 1999], disponibilidade de roteamento na internet [Andersen et al. 2001], multicast [Jannotti et al. 2000] [Chu et al. 2001], garantias de qualidade de serviço [Subramanian et al. 2004], ataque de negação de serviços [Andersen 2003], distribuição de conteúdo, compartilhamento de arquivos [Lua et al. 2005] e até sistemas de armazenamento [Dabek et al. 2001]. Redes de sobreposição também estão sendo usada como ambientes de teste, por exemplo PlanetLab [Peterson et al. 2009], Federica [Campanella 2011] e o GENI [GENI 2011], para desenvolvimento e avaliação de novas arquiteturas Virtualização de Rede com OpenFlow Similar à virtualização de computadores, a virtualização de redes promete melhorar a alocação de recursos além de permitir que seus operadores possam checar suas redes antes de eventuais mudanças, e também que clientes compartilhem o mesmo equipamento de forma controlada e isolada. Portanto, analogamente, a rede em si deve ter uma camada de abstração de hardware, similar ao que acontece na virtualização de computadores. Esta camada deve ser facilmente fatiável, para que múltiplas redes completamente diferentes possam ser executadas simultaneamente em cima, sem interferir uns aos outros, sobre uma variedade de hardwares diferentes abaixo, incluindo comutadores, roteadores, pontos de acesso e assim por diante. Ou seja, acima desta camada de abstração de hardware, têm-se novos protocolos e formatos de endereçamento rodando independentemente e sua própria fatia, uma mesma rede física, e na parte de baixo da camada de virtualização, novos hardwares, podendo ser desenvolvidos para diferentes ambientes e diferentes velocidade, mídia (com fio e sem fio) e energia. De acordo com Sherwood [Sherwood et al. 2010a], a camada de abstração de hardware é provida pelo OpenFlow e como camada de virtualização se tem FlowVisor. Similar à virtualização de computadores, o FlowVisor é uma camada de abstração que reside entre o hardware e o software dos componentes da arquitetura, conforme ilustrado na Figura Portanto, a integração FlowVisor e OpenFlow permite que em uma rede OpenFlow possam ser criados várias fatias de recursos de redes rodando simultaneamente e isoladamente. O FlowVisor é um controlador especializado que atua como um procurador (proxy) transparente entre os comutadores de uma rede OpenFlow e seus múltiplos controladores. Todas as mensagens do protocolo OpenFlow tanto aquelas originárias dos comutadores para os controladores quanto as dos controladores para os comutadores, são interceptadas através do FlowVisor. Desse modo, os controladores não necessitam de modificações e, devido à interceptação transparente do FlowVisor, os mesmos acreditam estar se comunicando diretamente com os dispositivos da rede que constitui o plano de dados [Sherwood et al. 2010b]. Devido à existência da interface entre os planos de dados e o de controle, a técnica empregada permite a partição do plano de dados em fatias que estão sob a gerência do FlowVisor [Sherwood et al. 2009].

50 XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos - SBRC Figura Comparação entre o FlowVisor como camada de virtualização com a virtualização computacional [Sherwood et al. 2009] Cada fatia está vinculado a um controlador. O FlowVisor define uma fatia como um conjunto de fluxos também chamado de espaço de fluxo (ou flowspace). Devido à versão atual do protocolo OpenFlow permitir a definição de um fluxo como uma combinação de dez campos do cabeçalho de pacote incluindo informações das camadas física, de enlace, de rede e de transporte, o FlowVisor possibilita que se implemente fatias com um elevado nível de granularidade, no que diz respeito à caracterização do flowspace [Sherwood et al. 2010a]. Além disso, as fatias podem ser definidas por ações de negação, união e intersecção. A Figura 1.16 ilustra o particionamento da rede em fatias. Nesta figura, além da fatia da rede de produção, têm-se mais duas fatias identificadas por Alice e Bob. Os círculos enumerados em ordem crescente indicam a dinâmica de execução durante o processamento das mensagens interceptadas pelo FlowVisor. Inicialmente, o FlowVisor intercepta as mensagens provenientes de um determinado controlador convidado no ambiente de controle (1). Utilizando a política do espaço de fluxos definida para aquela fatia (2), o FlowVisor reescreve a mensagem do controlador transparentemente para a fatia da rede que compõe o plano de dados (3). As mensagens originárias dos comutadores para o plano de controle (4), por sua vez, são novamente interceptadas pelo FlowVisor e reescritas para o respectivo controlador de acordo com a política que define o espaço de fluxos. O particionamento da rede possibilita que as ações desenvolvidas em uma de suas fatias não interfiram negativamente nos demais, mesmo que estes estejam compartilhando a mesma infraestrutura física. Em arquiteturas mais tradicionais, a rede é fatiada através da técnica de VLAN (Virtual Local Area Network), porém, com a diversidade dos modelos de redes, a estrutura de VLANs torna os experimentos, como IP Mobility ou Wireless Handover, por exemplo, bastante difíceis de gerenciar.

51 34 Minicursos Livro Texto Figura Gerenciamento de slices por meio do FlowVisor [Sherwood et al. 2009] As características inerentes ao FlowVisor, como a virtualização transparente, o forte isolamento entre as fatias e a sua rica política de definição de flowspaces tornam o mesmo uma ferramenta extremamente eficiente no que diz respeito à virtualização e implementação de redes programáveis orientadas a software Requisitos para Construção de um Ambiente para Experimento e Virtualização de Redes Iniciativas [FIRE 2011] [GENI 2011] [AKARI 2009] vêm construindo infraestruturas para testar novos protocolos, serviços e aplicações em ambientes de larga escala, visando solucionar esses desafios da Internet atual e compor a arquitetura da chamada Internet do Futuro. Por essas razões, definir estratégias corretas para construção e operação destes ambientes de teste para Internet do Futuro é considerado uma etapa vital. Além disso, o ambiente deve combinar flexibilidade a um conjunto mínimo de restrições e um completo controle do ambiente para seus pesquisadores [Kim et al. 2009]. Deste modo, o OpenFlow vem se destacando como arcabouço capaz de habilitar experimentos de novas tecnologias utilizando redes reais de produção. Nesta mesma linha, a virtualização vem como uma ferramenta essencial, para permitir o acesso compartilhado de recursos, seja de rede ou computacional. Portanto nesta seção, observam-se as informações importantes para construção de uma rede para experimentação, levando em consideração a utilização de OpenFlow e virtualização. Verificam-se o modo que se descrevem, os hardwares utilizados dentro desta infraestrutura, tipos de enlaces, software de virtualização e ferramentas para análise de tráfegos e geração de tráfego

52 XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos - SBRC Tipos de Hardwares Para construção do ambiente de teste, é necessário principalmente hardware que suporte virtualização e OpenFlow. Para isso, são necessários dispositivos especiais para que o desempenho da rede virtual não tenha uma influência nos experimentos realizados, e que seja possível sua otimização de forma programável. Entre esses dispositivos estão interfaces de redes programáveis e comutadores programáveis com OpenFlow habilitado. Interface de Rede Programável O NetFPGA [Lockwood et al. 2007] é uma plataforma aberta que permite estudantes e pesquisadores desenvolverem protótipos de sistemas de redes em alta velocidade e sistemas de aceleração de redes via hardware, além de protótipos de comutadores ou roteadores IP para Internet do Futuro. O NetFPGA consiste em um placa de desenvolvimento reconfigurável, interface de ligação ao PC, utilizando PCI e PCI-e, dois processadores PowerPC, e software que possibilita o desenvolvimento de novas funcionalidades. Há duas versões da placa: a mais antiga possui quatro interfaces de 1 Gbps Ethernet RJ-45 e um vazão que de 8Gbps; a mais nova tem quatro interfaces 10 Gbps Ethernet SFP+, e vazão até 80 Gbps. Além disso, é totalmente compatível com Linux e OpenFlow. Switches Programáveis O OpenFlow é um arcabouço que permite o gerenciamento da tabela de encaminhamento de comutadores Ethernet, desacoplando a lógica de controle do equipamento do hardware de encaminhamento de pacotes, permitindo assim o conceito chamado de Software- Defined Networking (SDN) [Greene 2009]. Esta separação não só permite um modelo de inovação aberta tanto no plano de controle quanto no plano de encaminhamento, mas também permite a virtualização do plano de encaminhamento em fatias ou redes lógicas. Deste modo, são necessários equipamentos que possuam o OpenFlow habilitado. No entanto, o protocolo Openflow ainda está em fase de padronização nos comutadores e algum fabricantes já disponibilizam versões de comutadores com OpenFlow habilitado, como é o caso dos modelos Pronto 3290 para soluções até 1 Gbps Ethernet e o Pronto 3790 para 10 Gbps Ethernet e SFP+. Também há o projeto Indigo [INDIGO 2011] que é uma implementação aberta do OpenFlow que permite rodar sobre comutadores físicos baseados em chipsets da Broadcom. A cada comutador suportado é desenvolvido um firmware para essa linha de produto. Este firmware sobrescreve o original do comutador, instalando a nova imagem com OpenFlow habilitado. Dentre os comutadores compatíveis, temos, além dos modelos da linha Pronto, os modelos GSM7328 (24 x 1 GbE) e GSM7352 (48 x 10 GbE) da linha Netgear. Servidores de Alto Desempenho Os servidores também são uma parte importante dentro do substrato, pois deles são virtualizados recursos como: processador, armazenamento e E/S. Para isso, são necessários servidores de alto capacidade computacional para que não haja perda de desempenho no nível virtualizado e suporte à quantidade de usuários locais e também os federados. Observando esses requisitos, as linhas de servidores do tipo blade surgem como uma excelente

53 36 Minicursos Livro Texto solução para oferecer essa capacidade computacional. Blade é uma nova forma de tecnologia computacional que permite a alta densidade de componentes e recursos incluindo servidores, armazenamento e interfaces de comunicação integradas em um mesmo chassis. A vantagem do uso de servidores blade é a possibilidade do crescimento incremental mediante a demanda de usuários, devido a sua característica modular, baseada em containers de servidores, comutadores e armazenamento. O seu capacidade computacional pode ser incrementado com introdução de novas lâminas blade, que são servidores que são inseridos no chassis e incluem recursos de processamento e memória. Além disso, outra vantagem é a sua otimização para uso de virtualização com barramento em altíssimas taxas de transferência, e implementação de grupos de recursos dentro de conjunto virtualizado. O uso de blades está ligado principalmente à virtualização de servidores e à computação em nuvem Arcabouços de Controle O arcabouço de controle é o coração de qualquer infraestrutura de experimentação baseada em virtualização. Porém, muitos arcabouços são limitados a certos tipos de recurso e a um tipo de comunidade de pesquisa. Com base nisso, são apresentados alguns arcabouços de controle que devem ser selecionados de acordo com o tipo de infraestrutura que se está oferecendo: ProtoGENI (GENI) O ProtoGENI [ProtoGENI 2011] é atualmente dirigido pela Universidade de Utah. É um arcabouço que pretende controlar a integração em larga escala de infraestruturas existentes e em construção no GENI. Esses ambientes de teste são compostos principalmente por elementos embarcados e programáveis nas redes backbone, PCs com hardwares programáveis e uma variedade de redes sem fio, redes de acesso e clusters programáveis. Atualmente, o ProtoGENI está usando RSpec para descrever seus nós, enlaces e interfaces. Esses recursos são mapeados para o Emulab que aplica os mapas virtuais de recursos em nós locais e vlans. ORCA(GENI) O ORCA [ORCA 2011] [BEN 2011] é framework de código fonte aberto, utilizado para gerenciar e controlar a programabilidade de substratos (hardware) compartilhados, que podem incluir, servidores, storages, redes e outros componentes. O ORCA foi desenvolvido como um protótipo arcabouço GENI. No ORCA, há uma coleção dinâmica de controladores de interação que trabalham juntas para o aprovisionamento e configuração de recursos para as fatias requisitadas pelos seus usuários, de acordo com as políticas dos participantes. Atualmente, o ORCA foi estendido para gerenciar um ambiente de teste em uma rede óptica metropolitana. Também está em processo de integração a seleção para utilização de protótipos para redes de sensores e sem fio, de modo que o ORCA ofereça a maior variedade possível de ambientes de teste.

54 XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos - SBRC FEDERICA (FIRE) O FEDERICA [Szegedi et al. 2009] é uma iniciativa composta de roteadores, comutadores e computadores para experimentações em Internet do Futuro. Ele é baseado nas redes acadêmicas de alguns países europeus e na rede pan-europeia GEANT. O arcabouço FEDERICA é capaz de alocar recursos para múltiplas fatias e diferentes redes a serem utilizadas pelos pesquisadores que possuem o controle completo dos recursos de sua fatia. Ele é composto de pequenas ferramentas e outros recursos de instrumentação que vão desde a gerência e controle de máquinas virtuais à alocação de circuitos fim-a-fim camada 2, camada 1 ou MPLS. PII (FIRE) O objetivo do projeto PII [Paul et al. 2011] é criar uma federação de instalações experimentais entre diferentes pólos de inovação regional na Europa. Isso permite que as empresas participantes possam testar novos serviços de comunicação e aplicações na Europa como um todo. O arcabouço também terá como objetivo federar redes para experimentação distribuídas por laboratórios espalhados pela Europa, assim provendo um ambiente de teste realístico para novos conceitos de serviços, tecnologias de rede e modelos de negócios. Os mecanismos de seu arcabouço incluem regras e procedimentos para alcançar níveis de teste e colaboração dentro dessas federações de infraestruturas dentro da Europa Monitoração e Medição Medição e monitoramento são atividades que observam o estado operacional do ambiente de teste que está sendo usado, de modo que se possa obter informações sobre o desempenho dos recursos disponíveis no ambiente, e verificar a disponibilidade do recurso ou componente. O objetivo disso é oferecer a outros sistemas uma visão dos recursos da infraestrutura, para auxiliar decisões como a possibilidade de alocação de recurso, bem como sua escolha e disponibilização. Portando, dentro dos requisitos para construção dessas ambientes de teste, esses elementos são essenciais. A seguir, são apresentados alguns softwares relacionados a características de medição e monitoramento. PerfSONAR O perfsonar (PERFormance Service-Oriented Network monitoring ARchitecture) é uma arquitetura orientada a serviços (SOA) que foi projetada para o monitoramento de redes em ambientes interdomínios. No perfsonar, existe um conjunto de serviços bem definidos que realizam ou disponibilizam resultados de medições de desempenho em um ambiente federado. Esses serviços atuam como uma camada intermediária entre as ferramentas de medições e as ferramentas de visualização [Tierney et al. 2009]. Além disso, o perfsonar também definiu um protocolo comum entre os serviços para permitir que sejam criados novos serviços seguindo a padronização deste protocolo, dando flexibilidade à arquitetura. Também, criou-se uma representação unificada para definir, armazenar e arquivar os dados relativos às medidas do experimento que é mais

55 38 Minicursos Livro Texto um componente chave, de modo que certo nível de concordância é necessário para fazer convergir esforços e melhorar a experiência, fidelidade e usabilidade das infraestruturas de experimentação em escala global. O ps-performance Toolkit [Ps-Performace 2011] é uma coleção de ferramentas de medida de desempenho de redes desenvolvida dentro do projeto perfsonar. BWCTL O BWCTL [Hu et al. 2010] é uma aplicação cliente/servidor que permite o agendamento de testes com políticas de medidas utilizando IPERF, THRULAY [Shalunov 2011] e NUTTCP [Fink and R. 2011]. Estes testes podem medir, por exemplo, a máxima largura de banda para TCP ou testes UDP para medir o atraso, a variação do atraso ou nível de perda de datagrama na rede. BWCTL tem sido utilizado para testar as qualidades das reservas de circuitos. Neste caso, o seu cliente solicita e agenda um circuito, verifica se foi criado ou não, e caso seja criado, ele verifica se os desempenhos solicitados estão realmente disponíveis. Real-Time Unified Measurement Framework O UMF (Unifed Measurament Framework) é um arcabouço desenvolvido para oferecer capacidade de medições em tempo real a avaliações de desempenho sobre vários cenários de infraestrutura, interfaces de integração dos recursos de medição com os substratos e os framewoks de controle dos protótipos de GENI e outros sistemas que necessitem de suas medidas e a monitoração das condições dos recursos de um slice durante um experimento [UMF 2011]. Inicialmente, o UMF está sendo desenvolvido para alimentar informações dos demais arcabouços de controle do GENI e de visualização dos usuários pesquisadores. Na Figura 1.17, mostra o esquema de interação dos arcabouços com o UMF. Figura Esquema de interação do UMF com outros frameworks do GENI UMF é um arcabouço genérico para gerenciamento de ambiente de teste e coleta de métricas de experimentos. Quando o experimento está sendo executado, os dados são medidos e coletados de acordo com a descrição do usuário. Pontos de medição são

56 XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos - SBRC definidos dentro de uma aplicação C/C++ ou automaticamente, baseados em arquivos de configuração XML. Os dados medidos são transmitidos usando codificação XDR e salvos em um banco de dados para análise posterior. Um novo banco de dados de medição é criado para cada experimento. O SQLite pode ser usado para manipular os dados ou estes podem ser exportados para geração de gráficos ou tabelas. No UMF, há medidores de desempenho (Performance Monitors) para os mais variados tipos de substratos físicos, como: unidades externas de hardware, por exemplo, servidores com capacidade de armazenamento (storage), interface de Ethernet NetFPGA (10G - NetFPGA). Outras interfaces Ethernet seriam GPIB e sem fio, e protocolos padrões para medição como TL1, SNMP e NetConf Ferramentas para Gerência de Virtualização As ferramentas de gerência são essenciais no desenvolvimento dos ambientes de experimentação, pois elas têm o papel de manipular, criar, configurar e remover recursos nestes ambientes. Portanto, abaixo, são apresentadas as principais ferramentas para gerenciamento de virtualização, computação em nuvem e manipulação de fatias. LIBVIRT A LIBVIRT [Wu et al. 2010] existe como um conjunto de APIs projetadas para serem usadas como um aplicativo de gerenciamento. Por meio de um mecanismo específico de hypervisors, a LIBVIRT comunica-se com um hypervisor disponível para executar as solicitações da API. Deste modo, a LIBVIRT provê uma comum genérica e estável camada para gerenciamento. A API pode acessar esse hypervisor permitindo o aprovisionamento, criação, modificação, controle, monitoramento, migração, inicialização e finalização da VM (virtual machine). No entanto, o suporte a todas essas operações irá depender da tecnologia de virtualização utilizada. Com a LIBVIRT, têm-se dois meios de controle distintos. O primeiro é demonstrado na Figura 1.18, no lado esquerdo, em que o aplicativo de gerenciamento e os domínios existem no mesmo nó. Nesse caso, o aplicativo de gerenciamento trabalha por meio da biblioteca libvirt para controlar os domínios locais. Outros meios de controle existentes são quando o aplicativo de gerenciamento e os domínios estão em nós separados, o que é ilustrado na Figura 4.19, lado direito. Este modo usa um daemon especial chamado libvirtd que é executado em nós remotos. Tal daemon é iniciado automaticamente quando a libvirt é instalada em um novo nó e pode determinar, de forma automática, os hypervisors locais e configurar drivers para eles. O aplicativo de gerenciamento se comunica por meio da libvirt local com o libvirt remoto através de um protocolo customizado [Bolte et al. 2010]. A API LIBVIRT foi construída para trabalhar através de múltiplos ambientes de virtualização. Dentre as tecnologias de virtualização temos: QEMU, LXC, OpenVZ, User Mode Linux, KVM, VirtualBox e VMWare. Além disso, também consegue gerenciar as seguintes tecnologias de armazenamento: Storage IDE/SCSI/USB, FiberChannel, LVM, iscsi e NFS.

57 40 Minicursos Livro Texto Figura Modos de controle de hypervisor [Wu et al. 2010] EUCALYPTUS Eucalyptus [Nurmi et al. 2009] é um arcabouço aberto para montagem e gerência de ambientes de computação em nuvem utilizando virtualização, sendo o seu foco a pesquisa acadêmica. Ele provê uma implementação baseada em IaaS (Infraestructure as a Service), ou seja, infraestrutura como recurso nuvem. Os usuários do Eucalyptus são capazes de iniciar, controlar, acessar e finalizar máquinas virtuais (VMs). A atual versão do Eucalyptus suporta VMs, rodando sobre uma hypervisor XEN, mas há planos de utilizar KVM/QEMU e VMWare. O projeto Eucalyptus apresenta quatro características que o diferenciam de outras soluções de computação em nuvem e virtualização: o Eucalyptus foi projetada para ser simples, de modo que não há a obrigatoriedade da dedicação de recursos; o arcabouço foi projetado para encorajar extensões de software de terceiros; possui uma interface externa que é baseada na API EC2 da Amazon; e o Eucalyptus provê uma rede sobreposta virtual que isola o tráfego de rede de diferentes usuários, permitindo que clusters remotos pareçam partes da mesma rede local. A gerência do Eucalyptus é baseada em serviços Web, o que oferece alguns benefícios à arquitetura, como a exposição da API em forma bem conhecida e funcional como o WSDL (Web Service Description Language), definindo tanto as operações que seus serviços podem desempenhar, quanto as estruturas de dados de entrada e saída utilizadas. A arquitetura define três níveis de gerenciamento da infraestrutura de nuvem: Instace Manager (IM): Controla a execução, inspecção e finalização das instâncias de VMs nos hospedeiros nos quais estão rodando; Group Manager (GM): Suas funcionalidades são as seguintes: escalonamento e gerenciamento de execução de operações sobre os IM, controle de operações sobre a rede virtual sobreposta e reportagem de informações sobre um conjunto de IMs; Cloud Manager (CM): Interage com os usuários e gerenciadores reportando informações a respeito dos estados dos recursos da nuvem.

58 XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos - SBRC O Eucalyptus é flexível e pode ser instalado em uma infraestrutura mínima (no mínimo duas máquinas), como também em milhares de núcleos e terabytes de armazenamento, Com total integração sobre uma rede sobreposta de interligação das infraestruturas de nuvem. E-GENI O Enterprise-GENI [E-GENI 2011] é uma arquitetura/arcabouço utilizada para gerenciar o uso de fatia em uma infraestrutura baseada em OpenFlow e FlowVisor. O objetivo do arcabouço é criar uma interface para visualização e gerências de múltiplos experimentos em rede OpenFlow. A Figura 1.19 mostra como está definida a arquitetura do E-GENI. Figura Arquitetura do E-GENI [E-GENI 2011] A arquitetura do E-GENI é dividida em três partes: OpenFlow-Based Substrate: Composto de switches que se comunicam utilizando o protocolo OpenFlow para uma aplicação do controlador; FlowVisor: Customizado para controlar slice de rede pelo isolamento e controle de tráfego de experimentos individuais; Aggregate Manager: Uma aplicação integra o Clearinghouse, responsável pela manipulação dos experimentos, ao E-GENI FlowVisor utilizando o protocolo SOAP, baseado no GENILight Protocol. O E-GENI vem sendo desenvolvido para integrar redes do tipo OpenFlow ao arcabouço GENI como mais uma alternativa dentro da infraestrutura de experimentação para Internet do Futuro do GENI.

59 42 Minicursos Livro Texto 1.5. Estudo de Caso Com o propósito de criação de ambientes experimentais em Internet do Futuro, a comunidade acadêmica vem orientando esforços consideráveis na criação de ambientes de teste baseados em redes programáveis. Baseada em tráfegos reais de usuários, a criação de ambientes programáveis permite uma abordagem mais realística com relação à escalabilidade da rede e seu comportamento interativo De maneira complementar a esta abordagem com ambientes de teste, este estudo de caso tem por objetivo demonstrar como é possível implementar uma rápida prototipagem de protocolos de rede que seja facilmente aplicável a redes reais. Ou seja, por meio de um ambiente local, é possível implementar uma funcionalidade que possa ser imediatamente aplicada para testes num ambiente global possibilitando uma maior inovação em redes programáveis. Como importante proposta no contexto de redes programáveis, neste estudo de caso utiliza-se do arcabouço OpenFlow devido à possibilidade de criação de uma infraestrutura de experimentação sobre uma rede de produção. Além disso, por meio da utilização do OpenFlow associado à virtualização, demonstra-se como é possível criar, utilizar e gerenciar várias fatias sobre uma infraestrutura de rede compartilhada, possibilitando que vários experimentos de protocolos possam ser executados de maneira simultânea. Por meio deste estudo de caso demonstra-se que é possível implementar uma nova funcionalidade, ou mesmo uma nova arquitetura de rede em ambientes locais baseados em software. Estas funcionalidades podem então ser testadas por seus usuários por meio de largas topologias e com tráfegos específicos. Posteriormente, os mesmos códigos que implementam estas funcionalidades podem ser empregados em ambientes de teste reais Definição do Ambiente Para exemplificar a utilização do OpenFlow associado à virtualização, esse estudo de caso tem como principal objetivo apresentar como se pode desenvolver um ambiente capaz de suportar simultaneamente vários experimentos de protocolos compartilhando a mesma infraestrutura física Dados de Implementação do Ambiente O estudo de caso é formado por um ambiente virtualizado, ou seja, os nós de equipamentos OpenFlow e hosts clientes da redes são elementos de virtualização. Para implementar esse ambiente com suporte ao arcabouço OpenFlow, utiliza-se dois servidores: um com Xen Server para armazenar os servidores que contêm os controladores que são utilizados em cada fatia do experimento e outro servidor utilizando apenas o sistema operacional Linux e o software Mininet [MiniNet 2011]. O Mininet utiliza virtualização baseada em contêineres para criar instâncias virtuais de cada comutador (ou host cliente) que seja utilizado no experimento. Além disso, utiliza-se um comutador para interligar o plano de controle (controlador) e plano de dados (comutadores). A Figura 1.20 ilustra o ambiente que foi desenvolvido para realização do

60 XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos - SBRC estudo de caso. Figura Ambiente de teste do estudo de caso A Tabela 1.1 apresenta, de forma resumida, as informações e configurações dos servidores utilizados no estudo de caso. Tabela 1.1. Dados dos Servidores Dados Servidor MiniNet Servidor de Controladores NOX Sistema Operacional Debian Lenny 5.0 Citrix XenServer 5.6 Memória 4096 MB 2048 MB Interface de Rede 1GbE 2 2 Armazenamento 320 GB SAS 500 GB SATA Virtualização Contêiner XEN No servidor de controladores têm-se três maquinas virtuais (VM) rodando três aplicações diferentes no controlador. Cada controlador se comunica com o FlowVisor usando 3-tuplas de informações: VLAN, IP e porta TCP do processo servidor do FlowVisor. Com o objetivo de isolar o tráfego de cada controlador para eventuais análises do comportamento das informações de controle entre o controlador e o FlowVisor são divididas por VLANs, VM1 VLAN 100, VM2 VLAN 200 e VM3 VLAN 300. A Tabela 1.2 contém um resumo dos dados de configuração de cada VM de controlador.

61 44 Minicursos Livro Texto Tabela 1.2. Configurações das VMs com os Controladores NOX Dados VM 1 VM 2 VM 3 Sistema Operacional Debian Lenny 5.0 Debian Lenny 5.0 Debian Lenny 5.0 Memória 512 MB 512 MB 512 MB Interface de Rede 1GbE Endereçamento IP VLAN Software Controlador NOX 0.6 NOX 0.6 NOX 0.6 Porta de Conexão com FlowvVisor Armazenamento 4 GB 4 GB 4 GB Aplicação Switch Switch e SpanningTree Switch e Routing No Servidor Mininet, observa-se dois ambientes distintos virtualizados. O primeiro contém o aplicativo Mininet virtualizando a infraestrutura física de comutadores e clientes. E um segundo com o FlowVisor que realiza a criação, remoção e gerência das fatias no plano de dados do Mininet. A Tabela 1.3 resume as configurações do servidor Mininet. Tabela 1.3. Dados do Servidor MiniNet Dados Servidor MiniNet Sistema Operacional Debian Lenny 5.0 Memória 4096 MB Interface de Rede 1GbE 2 Armazenamento 320 GB SAS Virtualização de Rede FlowVisor 0.6 Virtualização Contêiner Virtuais LXC Porta FlowVisor 6633 Mesmo utilizando a infraestrutura virtualizada de comutadores Openflow, os testes aqui executados são totalmente compatíveis se aplicados em uma ambiente real de comutadores OpenFlow. Deste modo, o ambiente desenvolvido aqui serve como um ponto de partida no desenvolvimento de uma nova solução que depois pode ser aplicado em um ambiente maior com elementos OpenFlow reais Plano de Dados Para o planejamento do plano de dados, foi desenvolvido o um script 1, que é utilizado pelo Mininet, e contém a descrição da topologia e dos elementos que fazem parte da mesma, como: comutadores ou roteadores e hosts (clientes). Para isso é utilizado uma API fornecida pela Mininet. A Figura 1.21 ilustra o plano de dados configurado no ambiente Mininet. Para este trabalho optou-se pelo emprego de uma topologia em malha 3x3. O objetivo é ter um cenário com uma quantidade de nós consideráveis e que também pos- 1 O scripts para o Mininet, assim como as aplicações NOX podem ser encontrados em

62 XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos - SBRC Figura Topologia e do plano de dados sibilite nós em comum entre as fatias, de modo a observar entre eles o compartilhamento de recursos e isolamento Plano de Controle Para o plano de controle foi alocado três fatias de planos de dados distintos, mostrado na Figura 1.22, nomeados de switch, switch_stp e switch_router. O comportamento de encaminhamento de pacote em cada fatia é gerenciado por três aplicações NOX, tais como, Switch, Spanning_Tree e Routing. Nas extremidades têm-se os hosts utilizados para geração de tráfego no plano de dados, seja por meio de requisições ICMP ou utilizando fluxos TCP ou UDP com uso da aplicação Iperf. Figura Slice dos Experimentos

63 46 Minicursos Livro Texto Representando o controle lógico dos pesquisadores, tem-se três controladores NOX, um em cada VM, associado a uma fatia do plano de dados. Abaixo apresentamos os comandos utilizados e executados em cada VM, para iniciar os controlares NOXs com sua aplicação respectiva: # nox_core -v -i ptcp:1515 switch # nox_core -v -i ptcp:1516 switch spanning_tree # nox_core -v -i ptcp:1517 switch route Os comandos acima indicam: iniciação do processo núcleo do NOX (nox_core), onde a opção -v indica o modo de depuração, a opção -i informa o protocolo de transporte e a porta ao qual o NOX estará escutando conexões dos comutadores do plano de dados, e, por fim, a aplicação NOX utilizada. Cada um destas fatias deve conectar-se ao seu respectivo controlador NOX inicializado pelos comandos anteriores. As instruções a seguir, utilizando o comando fvctl, efetivam a criação das fatias: # fvctl createslice switch tcp: :1515 research_switch@ufpa.br # fvctl createslice switch_stp tcp: :1516 research_switch_stp@ufpa.br # fvctl createslice switch_router tcp: :1517 research_router@ufpa.br O comando fvctl permite a gerência das fatias, portanto os parâmetros dos comandos acima indicam: createslice o tipo de ação que é aplicado à fatia; switch descreve o nome da fatia a ser criado; tcp: :1515 apresenta o endereço do controlador vinculado à fatia; e no final define-se o correio eletrônico do responsável. Ao final de cada entrada é solicitada a criação de uma senha para fatia específica, provendo um controle de acesso a cada operação na fatia. O comando a seguir lista as fatias criadas atualmente: # fvctl listslices Enter root s password: Slice 0: root Slice 1: switch Slice 2: switch_stp Slice 3: switch_router Aplicação Prática A primeira aplicação apenas efetua o encaminhamento de pacote na camada 2, com um comportamento de comutador; a segunda, além de efetuar o encaminhamento na camada 2 via comutador, também trata o aparecimento de ciclos na rede através do algoritmo SpanningTree; e, a terceira, habilita o roteamento de pacotes. Fatia Switch Para a fatia Switch, foi designado a topologia representada pela Figura Nesta topologia, têm-se dois hosts clientes, um em cada extremidade da topologia da fatia, gerando fluxo de pacotes entre eles.

64 XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos - SBRC Figura Slice Switch Os comandos abaixo alocam os recursos para o slice Switch. A definição inclui a especificação dos nós que compõem o plano de dados e a característica do fluxo que percorre o plano de dados. # fvctl addflowspace 00:00:00:00:00:01 10 dl_vlan=100 Slice:switch=4 # fvctl addflowspace 00:00:00:00:00:02 10 dl_vlan=100 Slice:switch=4 # fvctl addflowspace 00:00:00:00:00:03 10 dl_vlan=100 Slice:switch=4 Neste comando os parâmetros são as flags, addflowspace, que adiciona o recurso identificado pelo Datapath, a prioridade de execução (10), onde quanto maior o valor da prioridade mais rápido a informação da fatia é processada, e, por fim, Slice:switch=4 que indica a qual fatia o recurso é alocado. Nos comandos acima se tem a adição dos nós SW01, SW02 e SW03 formando a topologia da fatia Switch, neste caso os nós são identificados pelos endereços Datapath 00:00:00:00:00:01, 00:00:00:00:00:02 e 00:00:00:00:00:03, respectivamente. Para identificar os fluxos acrescentados à fatia foram utilizados elementos de camada 2, neste caso pelo vlan_id 100. O que se percebe é que, dependendo da camada onde o experimento é realizado, precisa-se de elementos dessa camada para identificar o fluxo que faz parte daquela fatia. Nesta aplicação o comportamento do comutador consiste em analisar cada pacote e aprender sobre sua porta de origem, associando o endereço MAC de origem à porta onde o mesmo está conectado. Caso o destino do pacote já esteja associado a uma dada porta, o pacote será enviado diretamente, caso contrário, o comutador realizará a ação de flood, ou seja, encaminha para todas as portas. Após a inclusão dos nós na fatia Switch, os nós OpenFlow passam a ser reconhecidos pelo NOX correspondente à fatia, e a executar as ações da aplicação instanciada na mesma. Para ilustrar o funcionamento da aplicação Switch, aplica-se um fluxo ICMP do tipo ECHO_REQUEST e ECHO_REPLY entre os hosts da fatia. Na primeira tentativa de comunicação são trocadas informações de controle entre os comutadores da fatia e o controlador. Como o pacote é desconhecido é aplicada a todos os nós a ação FLOOD,

65 48 Minicursos Livro Texto como mostra a Figura Figura Encaminhamento dos primeiros pacotes Para os pacotes seguintes que possuem o mesmo destino como o primeiro pacote, e como o controlador já aprendeu a porta que possui o MAC correspondente de destino, ele muda a ação de FLOOD para a porta correspondente, de modo a alcançar o nó de destino. Como mostrado na Figura Figura Tabela de fluxo após o conhecimento do nó de destino Fatia STP O protocolo STP possibilita a inclusão de ligações redundantes entre os comutadores, provendo caminhos alternativos no caso de falha de uma dessas ligações. Nesse contexto, seu objetivo é evitar a formação de ciclos entre os comutadores e permitir a ativação e desativação automática dos caminhos alternativos.

66 XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos - SBRC Para a fatia denominado switch_stp, optou-se por implementar a topologia representada pela Figura Nesta topologia tem-se um cenário no qual há presença de ciclos no caminho entre os hosts finais. O objetivo, neste caso, é tratar este problema por meio da implementação do algoritmo SpanningTree no ambiente do controlador. Figura Slice STP A alocação de recursos à fatia switch_stp é feita de maneira similar ao que foi implementado para a fatia switch. Para este fim, deve-se executar a seguinte sequência de comandos: # fvctl addflowspace 00:00:00:00:00:04 10 dl_vlan=200 Slice:switch_stp=4 # fvctl addflowspace 00:00:00:00:00:05 10 dl_vlan=200 Slice:switch_stp=4 # fvctl addflowspace 00:00:00:00:00:07 10 dl_vlan=200 Slice:switch_stp=4 # fvctl addflowspace 00:00:00:00:00:08 10 dl_vlan=200 Slice:switch_stp=4 Os comandos definem os recursos da fatia switch_stp, que neste caso são os fluxos de pacotes com vlan_id igual a 200. E também os nós utilizados, tais como: SW4 (Datapath 00:00:00:00:00:04); SW5 (Datapath 00:00:00:00:00:05); SW7 (Datapath 00:00:00:00:00:07); e SW8 (Datapath 00:00:00:00:00:08). No módulo STP, quando um novo comutador conecta-se ao controlador NOX, o módulo registra o nó e neste momento desabilita a operação de FLOOD em todas as suas portas. Periodicamente o módulo realiza consultas com todos os enlaces para montar a lista de elementos da topologia. Esta lista é utilizada para a construção da árvore geradora (Spanning Tree). De modo que, todos os comutadores candidatos são alocados em uma lista e ordenados (de maneira crescentemente) por meio de seu Datapath; O primeiro elemento é removido da lista e definido como "comutador raiz"da árvore geradora. Este procedimento é então executado para todos os comutadores candidatos que compõem a lista. O módulo Spanning Tree, também utiliza o módulo de descoberta do NOX, chamado Discovery, para localizar as ligações dos comutadores com os seus nós

67 50 Minicursos Livro Texto vizinhos. Como realizado no experimento anterior, foi gerado um fluxo ICMP entre os hosts clientes que utilizam a fatia switch_stp. Uma vez encontrada a topologia, através do módulo Discovery, o algoritmo calcula a melhor forma de desfazer o ciclo, desabilitando umas das portas do comutador que foi escolhida no cálculo. Na Figura 1.27, os itens numerados de 1 a 5 mostram o processo de reconhecimento de características dos comutadores que compõem a fatia, além da convergência da aplicação na habilitação (e não-habilitação) de portas. Figura Log do controlador sobre as decisões do STP O item 1 corresponde à descoberta dos comutadores, neste momento o comando de non-flood é enviado em todas as portas dos comutadores OpenFlow descobertos, representados por valores numéricos. No item 2, o primeiro comutador é selecionado, tem suas portas 1, 3 e 4 habilitadas para flood e a porta 2 desabilitada. Deste modo o algoritmo segue para os próximos comutadores candidatos conforme itens 3, 4 e 5 até que a árvore esteja formada e o protocolo convirja completamente, habilitando assim o tráfego entre os dois hosts. A partir desse momento o encaminhamento dos dados é igual ao do módulo comutador. Fatia Roteamento Na fatia switch_router utiliza-se a aplicação de routing. Esta aplicação possui a capacidade de aplicar aos nós o comportamento de roteadores, efetuando encaminhamento na camada 3. A Figura 1.28 exibe como os recursos de rede que são visualizados pelo controlador NOX que está habilitado com a aplicação routing. Para aplicar os nós que fazem parte da fatia neste experimento, a seguinte configuração foi realizada:

68 XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos - SBRC Figura Visão do controlador do fatia Roteamento # fvctl addflowspace 00:00:00:00:00:01 10 dl_vlan=300 Slice:switch_router=4 # fvctl addflowspace 00:00:00:00:00:02 10 dl_vlan=300 Slice:switch_router=4 # fvctl addflowspace 00:00:00:00:00:03 10 dl_vlan=300 Slice:switch_router=4 # fvctl addflowspace 00:00:00:00:00:06 10 dl_vlan=300 Slice:switch_router=4 # fvctl addflowspace 00:00:00:00:00:09 10 dl_vlan=300 Slice:switch_router=4 Para esta fatia utilizou-se os comutadores SW01, SW02, SW03, SW06 e SW09. Cada host está endereçado com sub-redes diferentes por meio das seguintes configurações de endereçamento IP listados pela Tabela 5. Tabela 1.4. Endereçamento IP dos hosts ligados ao slice Host Endereço IP Sub-rede Host /24 Host /24 Host /24 Para testar o encaminhamento de pacotes via camada 3, utiliza-se dois fluxos de pacotes, sendo o primeiro UDP e o segundo TCP. Desta forma, entre os hosts 02 e 04 têm-se um fluxo TCP na porta 200 e entre os hosts 02 e 05 têm-se um fluxo UDP na porta 100. O que se percebeu nesse experimento é que na primeira tentativa de estabelecimento de comunicação entre os hosts, tanto para fluxo TCP quanto UDP, são trocadas informações de controle (comutador e controlador), para determinar o que fazer com esse fluxo. Os primeiros pacotes são enviados para a fila, através da ação IN_QUEUE, ilustrado na Figura 1.29, para evitar a perda de pacote, enquanto se determina a sua rota. Quando a rota é determinada, são aplicadas as ações de encaminhamento para cada nó OpenFlow do caminho encontrado, conforme ilustrado na Figura De forma que

69 52 Minicursos Livro Texto essa rota é calculada apenas uma vez quando o primeiro pacote entra no roteador, os demais usam as ações que já foram aplicadas. O que se observa é que quando um pacote é destinado a um host que está nesta mesma sub-rede, o nó age como um comutador, encaminhando o pacote sem alterações para uma porta conhecida. Caso um pacote seja destinado para um endereço IP no qual o roteador conhece o próximo salto, o mesmo utiliza a rota previamente definida e aplica as ações de encaminhamento para cada comutador na rota determinada. Figura Ações aplicadas a tabela de fluxo dos nós openflow durante o primeiro pacote Figura Após a passagem dos primeiro pacote Também se observou que esta aplicação de roteamento não é baseada em algoritmos específicos tais como de vetor de distâncias ou estado de enlaces. O que se percebe é a necessidade de melhorias e novas idéias para a aplicação de roteamento. Nesse sentido,

70 XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos - SBRC existem exemplos de esforços vem sendo desenvolvido para aplicar essas características, como é o caso da aplicação QuagFlow [Nascimento et al. 2010]. Por meio do QuagFlow é possível aplicar algoritmos de roteamento baseado no conjunto de aplicações disponíveis do Quagga [Quagga 2011], para uso no OpenFlow. Desse modo, algoritmos como RIP ou OSPF, implementados no Quagga, podem ser utilizados pelo NOX para atender aos requisitos mais exigentes de roteamento Conclusão O estudo de caso mostrou que de uma maneira rápida e simplificada é possível construir infraestruturas prontas para experimento de protocolos baseadas em redes Open- Flow. Além disso, é uma excelente ferramenta para experimentação em Internet do Futuro (IF). Observou-se que com pequenos recursos é possível iniciar estes estudos para IF virtualizando todo plano de dados alinhado às necessidades de um ambiente real. Um ponto fraco da solução seria a não disponibilidade de interfaces de mais alto nível, como por exemplo interfaces web que facilitem a interação com FlowVisor. O que deixa a sua manipulação fortemente dependente do administrador da rede para criação da fatia do experimento com alta probabilidade de falha durante a inserção de comandos Considerações finais e o futuro em Pesquisa Experimental em Internet do Futuro Considerações Finais A virtualização tornou-se a principal ferramenta para pesquisa de desenvolvimento e habilitação da Internet do Futuro em todas as comunicações ou camadas computacionais dessas grandes infraestruturas. Com o uso da virtualização na construção desses ambientes de teste foi possível desacoplar a complexidade dos recursos físicos dos serviços oferecidos e apresentar simples interfaces com usuário, em localizações geográficas distintas e independentes de dispositivo de acesso. Além disso, a virtualização terá um papel importante, pois ela permitirá a comparação das novas tecnologias que estão sendo desenvolvidas para Internet do Futuro, com as tecnologias atuais. Também garantirá que tecnologias desenvolvidas no passado possam ser disponíveis nessa moderna infraestrutura. Com isso, a construção dos arcabouços para esses ambientes de teste está sendo desenvolvida com base na virtualização, seja ela baseada na virtualização do substrato, seja na infraestrutura física que contém todos os hardware e software para inicializar os recursos virtuais, bem como para a criação da infraestrutura virtual contendo os recursos virtuais e a topologia lógica, interligando-as. O arcabouço OpenFlow é uma dessas soluções, pois provê um protocolo aberto para programação do comportamento de fluxos de pacote em diferentes comutadores e roteadores. A rede contendo OpenFlow pode ter o tráfego particionado entre tráfego de produção e tráfego de experimentação, de maneira que pesquisadores possam controlar seus próprios fluxos. A rede de produção permanecerá isolada e processada da mesma maneira que antes do uso do OpenFlow.

71 54 Minicursos Livro Texto Ainda, o OpenFlow integrado com a ferramenta FlowVisor é capaz de criar e virtualizar elementos de redes de modo que uma mesma infraestrutura física possa ser compartilhada entre várias topologias lógicas, onde cada uma possui sua própria lógica de encaminhamento e tratamento de fluxos de pacotes distintos. Por fim, o OpenFlow possibilita de maneira rápida e simples a criação de uma infraestrutura para concepção de novos protocolos, como apresentada na seção de estudos de casos onde em um único servidor, conseguimos simular uma infraestrutura de comutadores e roteadores OpenFlow. Também conseguimos aplicar os conceitos de virtualização baseada em fatias de recursos e redes programáveis. Este capítulo apresentou o andamento da pesquisa experimental em Internet do Futuro no mundo e observou duas grandes tecnologias que estarão presentes nessas infraestruturas montadas em escala mundial. São elas: a virtualização e o arcabouço Open- Flow Tendências Futuras Nossa observação é que esta busca pela Internet do Futura ainda está em sua fase inicial, porém se expandindo com rapidez em algumas regiões do mundo. Liderando esta busca estão os EUA, a UE e o Japão, seguida por Coreia, China e Brasil. Nos EUA o programa GENI está iniciando a sua terceira fase, a chamada espiral 3, e as tendências, nesta terceira fase, será iniciar o suporte de pesquisadores nas infraestruturas de experimentação e a incrementação de recursos disponíveis para uso entre seus usuários, através de integração à chamada meso-scale, envolvendo a participação de maior número de universidades interligadas pelas grandes redes de pesquisa, Internet2 e NLR. Além disso, a ênfase será em ambientes de redes móveis 4G na periferia, integradas por redes ópticas e Ethernet nas redes fixas, e a ênfase no uso de tecnologia OpenFlow, para possibilitar experimentação com redes definidas por software. O GENI está sendo complementado pelo novo programa Future Internet Architectures (FIA), lançado em 2010 pela NSF, para fomentar pesquisa em novas arquiteturas, que poderiam ser validadas no ambiente GENI. Já na Europa, o programa FIRE, que deu início no final de 2010 à segunda rodada de grandes projetos, incluindo OFELIA, o primeira projeto europeu com OpenFlow. Diferente dos EUA, onde foram separados os programas FIA (pesquisa em arquiteturas) e GENI (ambiente de teste), os europeus misturam ambos facetas no mesmo projeto, através do estudo de casos de uso dos ambientes montados. No Japão, representado pelo projeto AKARI, que está na em seu segundo período desenvolvimento, à tendência futura é para início das construções de seus ambientes de teste e as primeiras demonstrações experimentais. O objetivo é que para o final de 2016 oferecer um protótipo da nova geração de rede para disponibilidade aos pesquisadores. OpenFlow também é importante no Japão e a empresa NEC está apostando na importância desta tecnologia para seu portfólio de produtos das categorias comutador e controlador. Por fim, no Brasil, a pesquisa em Internet do Futuro iniciou através de projetos isolados, como o projeto Horizon [Horizon 2011] e o projeto Webscience [WebScience 2010] que prevê a construção de uma rede para experimentação em arquiteturas de Internet do

72 XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos - SBRC Futuro. Este último projeto servia como uma das bases para a proposta de cooperação com um consórcio europeu, através do projeto FIBRE submetido às Chamadas Coordenadas em TIC entre Brasil e a UE. O projeto FIBRE, se confirmado, tornará possível a construção de uma instalação experimental compartilhada de larga escala, que permita a experimentação em infraestrutura de rede e aplicações distribuídas. Isso consistirá em um novo ambiente de teste baseado em OpenFlow no Brasil e uma melhoria dos recursos dos projetos OFELIA e OneLab, atualmente em desenvolvimento na Europa. Além disso, possibilitará a federação de ambientes de teste dos parceiros brasileiros e europeus para permitir aos pesquisadores que usem recursos de ambos em um mesmo experimento. Tal iniciativa demonstrará o potencial das instalações ao mostrar aplicações baseadas em OpenFlow, estabelecidas sobre os recursos das instalações federadas. Portanto, aumentará a colaboração e a troca de conhecimentos entre pesquisadores europeus e brasileiros no campo de Internet do Futuro. Agradecimentos Este trabalho esta sendo apoiado por recursos financiados pelas seguintes instituições: FAPESPA, CAPES, CNpQ e RNP. Referências [AKARI 2009] AKARI (2009). New generation network architecture: Akari conceptual design. Technical report, National Institute of Information and Communications Technology. _e_preliminary.pdf. [Andersen et al. 2001] Andersen, D., Balakrishnan, H., Kaashoek, F., and Morris, R. (2001). Resilient overlay networks. SIGOPS Oper. Syst. Rev., 35: [Andersen 2003] Andersen, D. G. (2003). Mayday: distributed filtering for internet services. In Proceedings of the 4th conference on USENIX Symposium on Internet Technologies and Systems - Volume 4, USITS 03, pages 3 3, Berkeley, CA, USA. USENIX Association. [Balakrishnan et al. 2004] Balakrishnan, H., Lakshminarayanan, K., Ratnasamy, S., Shenker, S., Stoica, I., and Walfish, M. (2004). A layered naming architecture for the internet. SIGCOMM Comput. Commun. Rev., 34: [Banniza et al. 2009] Banniza, T.-R., Boettle, D., Klotsche, R., Schefczik, P., Soellner, M., and Wuenstel, K. (2009). A european approach to a clean slate design for the future internet. Bell Lab. Tech. J., 14:5 22. [BEACON 2011] BEACON (2011). Java-based openflow controller. Disponível em: em: 20/02/11. [BEN 2011] BEN (2011). Breakable experimental network. Disponível em: Acesso em: 20/02/2011.

73 56 Minicursos Livro Texto [Bhatia et al. 2008] Bhatia, S., Motiwala, M., Muhlbauer, W., Mundada, Y., Valancius, V., Bavier, A., Feamster, N., Peterson, L., and Rexford, J. (2008). Trellis: a platform for building flexible, fast virtual networks on commodity hardware. In Proceedings of the 2008 ACM CoNEXT Conference, CoNEXT 08, pages 72:1 72:6, New York, NY, USA. ACM. [Bi 2011] Bi, J. (2011). Future internet related research activities in china. Disponível em: /Session/Slides/FutureInternet/3-1.pdf. Acesso em 20/02/2011. [Bolte et al. 2010] Bolte, M., Sievers, M., Birkenheuer, G., Niehorster, O., and Brinkmann, A. (2010). Non-intrusive virtualization management using libvirt. In Design, Automation Test in Europe Conference Exhibition (DATE), 2010, pages [BonFIRE 2011] BonFIRE (2011). Building service testbeds on future internet research and experimentation. Disponível em: Acesso em: 20/02/2011. [Campanella 2011] Campanella, M. (2011). Federica: A virtualization based infrastructure for future and present internet research. In Akan, O., Bellavista, P., Cao, J., Dressler, F., Ferrari, D., Gerla, M., Kobayashi, H., Palazzo, S., Sahni, S., Shen, X. S., Stan, M., Xiaohua, J., Zomaya, A., Coulson, G., Magedanz, T., Gavras, A., Thanh, N. H., and Chase, J. S., editors, Testbeds and Research Infrastructures. Development of Networks and Communities, volume 46 of Lecture Notes of the Institute for Computer Sciences, Social Informatics and Telecommunications Engineering, pages Springer Berlin Heidelberg / _9. [Chowdhury and Boutaba 2010] Chowdhury, N. M. K. and Boutaba, R. (2010). A survey of network virtualization. Comput. Netw., 54: [Chu et al. 2001] Chu, Y., Rao, S., Seshan, S., and Zhang, H. (2001). Enabling conferencing applications on the internet using an overlay muilticast architecture. SIGCOMM Comput. Commun. Rev., 31: [Clack 2011] Clack, D. C. (2011). Toward the design of a future internet. technical report: National science fundation. Disponível em: Internet 7-0.pdf. National Science Fundation. [CREW 2011] CREW (2011). Cognitive radio experimentation world. Disponível em: Acesso em: 20/02/2011. [Dabek et al. 2001] Dabek, F., Kaashoek, M. F., Karger, D., Morris, R., and Stoica, I. (2001). Wide-area cooperative storage with cfs. SIGOPS Oper. Syst. Rev., 35: [E-GENI 2011] E-GENI (2011). Enterprise geni. Disponível em: Acesso em: 20/02/2011.

74 XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos - SBRC [Egi et al. 2010] Egi, N., Greenhalgh, A., Handley, M., Hoerdt, M., Huici, F., Mathy, L., and Papadimitriou, P. (2010). A platform for high performance and flexible virtual routers on commodity hardware. SIGCOMM Comput. Commun. Rev., 40: [Eide et al. 2006] Eide, E., Stoller, L., Stack, T., Freire, J., and Lepreau, J. (2006). Integrated scientific workflow management for the emulab network testbed. In Proceedings of the annual conference on USENIX 06 Annual Technical Conference, pages 33 33, Berkeley, CA, USA. USENIX Association. [Feldmann 2007] Feldmann, A. (2007). Internet clean-slate design: what and why? SIG- COMM Comput. Commun. Rev., 37: [FIND 2011] FIND (2011). Future internet design. [Fink and R. 2011] Fink, B. and R., S. (2011). Nuttcp. Disponível em: ftp://ftp/lcp.nrl.navy.mil/pub/nuttcp/2006. Acesado em: 20/02/2011. [FIRE 2008] FIRE (2008). Future internet research and experiment: Area 6. Disponível em: Internet.eu/fileadmin/documents/bled_documents/experiemental_facilities/FIRE- Issues-paper-2.2.pdf. [FIRE 2010] FIRE (2010). Future internet research and experimentation: An overview of european fire initiative and its projects. Technical report, Disponível em: [FIRE 2011] FIRE (2011). Future internet research and experimentation. FP7 - Seventh Framework Programme. [GENI 2011] GENI (2011). Global environment for network innovations. [GENI-Sys 2008] GENI-Sys (2008). Geni system overview. Disponível em: [Greene 2009] Greene, K. (2009). Tr10: Software-defined networking. [Gude et al. 2008] Gude, N., Koponen, T., Pettit, J., Pfaff, B., Casado, M., McKeown, N., and Shenker, S. (2008). Nox: towards an operating system for networks. SIGCOMM Comput. Commun. Rev., 38: [Horizon 2011] Horizon (2011). Horizon project: A new horizon to the internet. Disponível em: Acesso em: 20/02/2011. [Hu et al. 2010] Hu, J.-W., Chen, H.-M., Liu, T.-L., Tseng, H.-M., Lin, D., Yang, C.-S., and Yeh, C. (2010). Implementation of alarm correlation system for hybrid networks based upon the perfsonar framework. In Advanced Information Networking and Applications Workshops (WAINA), 2010 IEEE 24th International Conference on, pages

75 58 Minicursos Livro Texto [INDIGO 2011] INDIGO (2011). Disponível em: Flow+for+Hardware+Switches. Acesso em: 20/02/2011. [Jain 2006] Jain, R. (2006). Internet 3.0: ten problems with current internet architecture and solutions for the next generation. In Proceedings of the 2006 IEEE conference on Military communications, MILCOM 06, pages , Piscataway, NJ, USA. IEEE Press. [Jannotti et al. 2000] Jannotti, J., Gifford, D. K., Johnson, K. L., Kaashoek, M. F., and O Toole, Jr., J. W. (2000). Overcast: reliable multicasting with on overlay network. In Proceedings of the 4th conference on Symposium on Operating System Design & Implementation - Volume 4, OSDI 00, pages 14 14, Berkeley, CA, USA. USENIX Association. [Joseph and Lewis 2008] Joseph, W. and Lewis, C. (2008). Green: The new computing coat of arms? IT Professional, 10: [Kim et al. 2009] Kim, D. Y., Mathy, L., Campanella, M., Summerhill, R., Williams, J., Shimojo, S., Kitamura, Y., and Otsuki, H. (2009). Future internet: Challenges in virtualization and federation. Advanced International Conference on Telecommunications, 0:1 8. [Krishnamurthy et al. 2001] Krishnamurthy, B., Wills, C., and Zhang, Y. (2001). On the use and performance of content distribution networks. In Proceedings of the 1st ACM SIGCOMM Workshop on Internet Measurement, IMW 01, pages , New York, NY, USA. ACM. [Liu et al. 2009] Liu, J., Cho, S., Han, S., Kim, K., Ha, Y., Choe, J., Kamolphiwong, S., Choo, H., Shin, Y., and Kim, C. (2009). Establishment and traffic measurement of overlay multicast testbed in koren, thairen and tein2. In Proceedings of the 6th International Conference on Mobile Technology, Application & Systems, Mobility 09, pages 42:1 42:7, New York, NY, USA. ACM. [Lockwood et al. 2007] Lockwood, J. W., McKeown, N., Watson, G., Gibb, G., Hartke, P., Naous, J., Raghuraman, R., and Luo, J. (2007). Netfpga an open platform for gigabit-rate network switching and routing. In Proceedings of the 2007 IEEE International Conference on Microelectronic Systems Education, MSE 07, pages , Washington, DC, USA. IEEE Computer Society. [Lua et al. 2005] Lua, E. K., Crowcroft, J., Pias, M., Sharma, R., and Lim, S. (2005). A survey and comparison of peer-to-peer overlay network schemes. Communications Surveys Tutorials, IEEE, 7(2): [McKeown 2011] McKeown, N. (2011). Clean slate research program. Stanford Univesity. [McKeown et al. 2008] McKeown, N., Anderson, T., Balakrishnan, H., Parulkar, G., Peterson, L., Rexford, J., Shenker, S., and Turner, J. (2008). Openflow: enabling innovation in campus networks. SIGCOMM Comput. Commun. Rev., 38:69 74.

76 XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos - SBRC [MiniNet 2011] MiniNet (2011). Rapid prototyping for software-defined networks. Disponível em: Acessado em: 20/02/11. [Moskowitz and Nikander 2005] Moskowitz, R. and Nikander, P. (2005). Host identity protocol architecture. Internet draf, IETF. [Moskowitz et al. 2005] Moskowitz, R., Nikander, P., Jokela, P., and Henderson, T. (2005). Host identity protocol. Internet draf, IETF. [Nascimento et al. 2010] Nascimento, M. R., Rothenberg, C. E., Salvador, M. R., and Magalhães, M. F. (2010). Quagflow: partnering quagga with openflow. In Proceedings of the ACM SIGCOMM 2010 conference on SIGCOMM, SIGCOMM 10, pages , New York, NY, USA. ACM. [Nurmi et al. 2009] Nurmi, D., Wolski, R., Grzegorczyk, C., Obertelli, G., Soman, S., Youseff, L., and Zagorodnov, D. (2009). The eucalyptus open-source cloud-computing system. In Proceedings of the th IEEE/ACM International Symposium on Cluster Computing and the Grid, CCGRID 09, pages , Washington, DC, USA. IEEE Computer Society. [OFELIA 2011] OFELIA (2011). Openflow in europe - linking infrastructure and applications. Disponível em: Acesso em: 20/02/2011. [OMF 2011] OMF (2011). control and management framework. Disponível: Acesso em: 20/02/2011. [ORCA 2011] ORCA (2011). Open resource control architecture. Disponível em: geni/wiki/orcaben. Acesso em: 20/02/2011. [Paul et al. 2011] Paul, S., Pan, J., and Jain, R. (2011). Architectures for the future networks and the next generation internet: A survey. Comput. Commun., 34:2 42. [Peterson et al. 2006] Peterson, L., Muir, S., Roscoe, T., and Klingaman, A. (2006). Planetlab architecture: An overview. Disponível em: PLANTLAB. [Peterson et al. 2009] Peterson, L., Sevinc, S., Lepreau, J., and et al. (2009). Slicebased facility architecture, draft version Disponiível em: [ProtoGENI 2011] ProtoGENI (2011). Disponível em: Acesso em: 20/02/2011. [Ps-Performace 2011] Ps-Performace (2011). ps-performace toolkit. Disponvel em: Acesso em: 20/02/2011. [Quagga 2011] Quagga (2011). Quagga routing suite. Disponível em: Acesso em: 14/03/2011.

77 60 Minicursos Livro Texto [Rexford and Dovrolis 2010] Rexford, J. and Dovrolis, C. (2010). Future internet architecture: clean-slate versus evolutionary research. Commun. ACM, 53: [Savage et al. 1999] Savage, S., Anderson, T., Aggarwal, A., Becker, D., Cardwell, N., Collins, A., Hoffman, E., Snell, J., Vahdat, A., Voelker, G., and Zahorjan, J. (1999). Detour: informed internet routing and transport. Micro, IEEE, 19(1): [Scarabucci et al. 2005] Scarabucci, R. R., Stanton, M. A., de Barros, M. R. X., Salvador, M. R., Rossi, S. M., Sim?, F. D., Rocha, M. L., da Silva Neto, I. L., Rosolem, J. B., Fudoli, T. R. T., Mendes, J. M. D., Castro, N. F., Machado, I., Reggiani, A. E., Paradisi, A., and Martins, L. (2005). Project giga-high-speed experimental ip/wdm network. Testbeds and Research Infrastructures for the Development of Networks & Communities, International Conference on, 0: [Shalunov 2011] Shalunov, S. (2011). Thrulay - network capacity tester. Disponível em: Acesso em: 20/02/2011. [Sherwood et al. 2010a] Sherwood, R., Chan, M., Covington, A., Gibb, G., Flajslik, M., Handigol, N., Huang, T.-Y., Kazemian, P., Kobayashi, M., Naous, J., Seetharaman, S., Underhill, D., Yabe, T., Yap, K.-K., Yiakoumis, Y., Zeng, H., Appenzeller, G., Johari, R., McKeown, N., and Parulkar, G. (2010a). Carving research slices out of your production networks with openflow. SIGCOMM Comput. Commun. Rev., 40: [Sherwood et al. 2009] Sherwood, R., Gibb, G., Yap, K., Appenzeller, G., McKeown, N., and Parulkar, G. (2009). Flowvisor: A network virtualization layer. Disponível em: flowvisor.pdf. [Sherwood et al. 2010b] Sherwood, R., Gibb, G., Yap, K.-K., Appenzeller, G., Casado, M., McKeown, N., and Parulkar, G. (2010b). Can the production network be the testbed? In Proceedings of the 9th USENIX conference on Operating systems design and implementation, OSDI 10, pages 1 6, Berkeley, CA, USA. USENIX Association. [Spiral2 2010] Spiral2 (2010). Geni spiral 2 overview. Disponível em: [Stoica et al. 2004] Stoica, I., Adkins, D., Zhuang, S., Shenker, S., and Surana, S. (2004). Internet indirection infrastructure. IEEE/ACM Trans. Netw., 12: [Subramanian et al. 2004] Subramanian, L., Stoica, I., Balakrishnan, H., and Katz, R. H. (2004). Overqos: an overlay based architecture for enhancing internet qos. In Proceedings of the 1st conference on Symposium on Networked Systems Design and Implementation - Volume 1, pages 6 6, Berkeley, CA, USA. USENIX Association. [Szegedi et al. 2009] Szegedi, P., Figuerola, S., Campanella, M., Maglaris, V., and Cervello-Pastor, C. (2009). With evolution for revolution: managing federica for future internet research. Communications Magazine, IEEE, 47(7):34 39.

78 XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos - SBRC [Tierney et al. 2009] Tierney, B., Metzger, J., Berkeley, L., Laboratory, N., Boote, J., Boyd, E., Brown, A., Carlson, R., Zekauskas, M., and Internet, J. Z. (2009). perfsonar: Instantiating a global network measurement framework. Disponível em: tierney/papers/perfsonar-lbnl-report.pdf. [UMF 2011] UMF (2011). Embedding real-time substrate measurements for crosslayer communications. Disponível em: 20/02/2011. [WebScience 2010] WebScience (2010). Brazilian institute for web science research. Disponível em: Acesso em:20/02/2011. [Wu et al. 2010] Wu, S., Deng, L., Jin, H., Shi, X., Zhao, Y., Gao, W., Zhang, J., and Peng, J. (2010). Virtual machine management based on agent service. In Parallel and Distributed Computing, Applications and Technologies (PDCAT), 2010 International Conference on, pages [Yu et al. 2010] Yu, M., Rexford, J., Freedman, M. J., and Wang, J. (2010). Scalable flow-based networking with difane. SIGCOMM Comput. Commun. Rev., 40:

79 62 Minicursos Livro Texto

80 Capítulo 2 Explorando Redes Sociais Online: Da Coleta e Análise de Grandes Bases de Dados às Aplicações Fabrício Benevenuto, Jussara M. Almeida e Altigran S. Silva Resumo Redes sociais online têm se tornado extremamente populares, levando ao surgimento e à crescente popularização de uma nova onda de aplicações na Web. Associado a esse crescimento, redes sociais estão se tornando um tema central de pesquisas em diversas áreas da Ciência da Computação. Este mini-curso oferece uma introdução ao pesquisador que pretende explorar esse tema. Inicialmente, apresentamos as principais características das redes sociais mais populares atualmente. Em seguida, discutimos as principais métricas e análises utilizadas no estudo dos grafos que formam a topologia das redes sociais. Finalmente, sumarizamos as principais abordagens para coleta e tratamento de dados de redes sociais online e discutimos trabalhos recentes que ilustram o uso de tais técnicas. Abstract Online social networks have become extremely popular, causing the deployment and increasing popularity of a new wave of applications on the Web. Associated with this popularity growth, online social networks are becoming a key theme in several research areas. This short course offers an introduction to the researcher who aims at exploring this theme. Initially, we present the main characteristics of current online social network applications. Then, we discuss the main metrics and analyses employed to study the graphs that represent the social network topologies. Finally, we summarize the main approaches used to collect and process online social network datasets, and discuss recent work that illustrates the use of such approaches.

81 64 Minicursos Livro Texto 2.1. Introdução Desde seu início, a Internet tem sido palco de uma série de novas aplicações, incluindo , aplicações par-a-par, aplicações de comércio eletrônico assim como vários serviços Web. Atualmente, a Web vem experimentando uma nova onda de aplicações associada à proliferação das redes sociais online e ao crescimento da popularidade da mídia digital. Várias redes sociais online (OSNs - Online Social Networks) surgiram, incluindo redes de profissionais (ex., LinkedIn), redes de amigos (ex., MySpace, Facebook, Orkut), e redes para o compartilhamento de conteúdos específicos tais como mensagens curtas (ex., Twitter), diários e blogs (ex., LiveJournal), fotos (ex., Flickr), e vídeos (ex., YouTube). Redes sociais online têm atraído milhões de usuários. De acordo com a Nielsen Online [99], mídia social, termo usado em referência a conteúdo criado e disseminado via interações sociais, passou na frente de como a atividade online mais popular. Mais de dois terços da população online global visita ou participa de redes sociais e blogs. Como comparação, se o Facebook fosse um país, este seria o terceiro país mais populoso do mundo, graças aos seus 500 milhões de usuários registrados [5]. Tanta popularidade está associada a uma funcionalidade comum de todas as redes sociais online que é permitir que usuários criem e compartilhem conteúdo nesses ambientes. Este conteúdo pode variar de simples mensagens de texto comunicando eventos do dia-a-dia até mesmo a conteúdo multimídia, como fotos e vídeos. Como conseqüência, as estatísticas sobre conteúdo gerado pelos usuários nesses sítios Web são impressionantes. Por exemplo, o Facebook compartilha mais de 60 bilhões de fotos, que ocupam mais de 1.5 PB de espaço [10]. A quantidade de conteúdo que o YouTube armazena em 60 dias seria equivalente ao conteúdo televisionado em 60 anos, sem interrupção, pelas emissoras norte-americanas NBC, CBS e ABC juntas [12]. De fato, o YouTube foi acessado por mais de 100 milhões de usuários apenas em Janeiro de 2009 [1], com uma taxa de upload de 10 horas de vídeo por minuto [14]. Apesar de tanta popularidade e da enorme quantidade de conteúdo disponível, o estudo de redes sociais ainda está em sua infância, já que esses ambientes estão experimentando novas tendências e enfrentando diversos novos problemas e desafios. A seguir sumarizamos alguns elementos motivadores para o estudo de redes sociais online. Comercial: Com usuários passando muito tempo navegando em redes sociais online, esses sítios Web têm se tornado um grande alvo para propagandas. De fato, em 2007, 1,2 bilhões de dólares foram gastos em propagandas em redes sociais online no mundo todo, e é esperado que este número triplique até 2011 [21]. Além disso, usuários de redes sociais online compartilham e recebem uma grande quantidade de informação, influenciando e sendo influenciados por seus amigos [40]. Conseqüentemente, redes sociais online estão se tornando cada vez mais um alvo de campanhas políticas [59] e de diversas outras formas de marketing viral, onde usuários são encorajados a compartilhar anúncios sobre marcas e produtos com seus amigos [78]. Sociológica: No passado o estudo de redes sociais era um domínio de sociólogos e antropólogos, que utilizavam, como ferramentas típicas para se obter dados,

82 XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos - SBRC entrevistas e pesquisas com usuários voluntários [113]. Como conseqüência, muitos desses estudos foram realizados com base em amostras de dados pequenas e possivelmente pouco representativas. Com a popularização de aplicações de redes sociais online, surgiu a oportunidade de estudos nesse tema com o uso de grandes bases de dados, coletadas de tais aplicações. Sistemas como Facebook, Twitter, Orkut, MySpace e YouTube possuem milhões de usuários registrados e bilhões de elos que os conectam. Redes sociais online permitem o registro em larga escala de diversos aspectos da natureza humana relacionados à comunicação, à interação entre as pessoas e ao comportamento humano, em geral: elas permitem que as pessoas interajam mais, mantenham contato com amigos e conhecidos e se expressem e sejam ouvidas por uma audiência local ou até mesmo global. De fato, redes sociais online vêm funcionando como um novo meio de comunicação, modificando aspectos de nossas vidas. Melhorias dos sistemas atuais: Assim como qualquer sistema Web, redes sociais online são vulneráveis a novas tendências e estão sujeitas a experimentarem uma rápida transferência de seus usuários para outros sistema, sem aviso prévio. Por exemplo, inicialmente o MySpace experimentou um crescimento exponencial no número de usuários. Entretanto, este crescimento foi seguido por uma forte queda depois de abril de 2008 devido a um aumento no número de usuários do Facebook [108]. Um outro exemplo é o Orkut, que inicialmente cresceu muito rapidamente em diversos lugares, mas que teve sua popularidade concretizada somente em alguns países. Dentre esses países, o Brasil é o com maior número de usuários registrados [11]. Várias razões podem explicar este tipo de fenômeno, incluindo a interface e novas utilidades do sistema, problemas de desempenho e características dos usuários, etc. Finalmente, o grande volume de dados disponíveis em diferentes redes sociais online abre um novo leque de opções para pesquisas relacionadas à recuperação de conteúdo, onde estratégias de busca e recomendação de usuários e conteúdo são cada vez mais importantes. Outro aspecto importante está relacionado ao tráfego gerado pelas redes sociais online. Intuitivamente, existe uma diferença crucial entre publicar conteúdo na Web tradicional e compartilhar conteúdo através de redes sociais online. Quando as pessoas publicam algum conteúdo na Web, elas tipicamente fazem isso para que todos os usuários da Internet, em qualquer lugar, possam acessar. Por outro lado, quando usuários publicam conteúdo em redes sociais online, eles geralmente possuem uma audiência em mente, geralmente, seus amigos. Algumas vezes, a audiência é explicitamente definida por um usuário ou pela política do sistema. Conseqüentemente, redes sociais online constituem uma classe única de aplicações com potencial para remodelar os padrões de tráfego na Internet. Estudar aspectos de sistemas relacionados a redes sociais pode ser de grande importância para a próxima geração da infra-estrutura da Internet e para o projeto de sistemas de distribuição de conteúdo mais eficientes, eficazes e robustos [71, 102]. Segurança e conteúdo indesejável: Redes sociais online estão cada vez mais se tornando alvo de usuários maliciosos ou oportunistas que enviam propagandas não

83 66 Minicursos Livro Texto solicitadas, spam, e até mesmo phishing. O problema se manifesta de diversas maneiras, tais como a inclusão de vídeos contendo spams em listas de vídeos mais populares [29, 26], o envio de spam no Twitter [24], a inclusão de metadados (particularmente tags) que não descrevem adequadamente o conteúdo associado (p.ex: tag spamming) [27], etc. Conteúdo não solicitado consome a atenção humana, talvez o recurso mais importante na era da informação. Em última instância, o ruído e o distúrbio causados por alguns usuários reduzem a efetividade da comunicação online. Redes sociais online são ambientes perfeitos para o estudo de vários temas da computação, incluindo sistemas distribuídos, padrões de tráfego na Internet, mineração de dados, sistemas multimídia e interação humano-computador. Além disso, por permitir que usuários criem conteúdo, redes sociais vêm se tornando um tema chave em pesquisas relacionadas à organização e tratamento de grandes quantidades de dados, além de constituírem um ambiente ideal para extração de conhecimento e aplicação de técnicas de mineração de dados. Neste mini-curso apresentamos uma visão geral sobre redes sociais, oferecendo uma base necessária ao pesquisador que pretende explorar o tema. Inicialmente, apresentamos as principais características das redes sociais mais populares atualmente. Em seguida, discutimos as principais métricas e análises utilizadas no estudo dos grafos que formam a topologia das redes sociais. Finalmente, sumarizamos as principais abordagens utilizadas para coletar e tratar dados de redes sociais online e discutimos trabalhos recentes que utilizaram essas técnicas Definições e Características de Redes Sociais Online Esta seção apresenta uma visão geral sobre as redes sociais online, suas principais características e mecanismos de interação entre os usuários Definição O termo rede social online é geralmente utilizado para descrever um grupo de pessoas que interagem primariamente através de qualquer mídia de comunicação. Conseqüentemente, baseado nessa definição, redes sociais online existem desde a criação da Internet. Entretanto, neste trabalho, nós utilizaremos uma definição um pouco mais restrita, adotada em trabalhos anteriores [35, 85]. Nós definimos uma rede social online como um serviço Web que permite a um indivíduo (1) construir perfis públicos ou semipúblicos dentro de um sistema, (2) articular uma lista de outros usuários com os quais ele(a) compartilha conexões e (3) visualizar e percorrer suas listas de conexões assim como outras listas criadas por outros usuários do sistema. Com base nessa definição, existem várias redes sociais online disponíveis na Web, que variam de acordo com seus objetivos primários. A Tabela 2.1 apresenta uma lista com várias redes sociais online populares atualmente, juntamente com seus principais propósitos. Uma lista atualizada e exaustiva de redes sociais online, com mais de 150 sítios Web, pode ser encontrada em [8].

84 XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos - SBRC Nome Propósito URL Orkut Amizades Facebook Amizades MySpace Amizades Hi5 Amizades LinkedIn Professionais YouTube Compartilhamento de vídeos Flickr Compartilhamento de fotos LiveJournal Blogs e diários Digg Compartilhamento de (bookmarks) Twitter Troca de mensagens curtas LastFM Compartilhamento de rádio/músicas Tabela 2.1. Algumas Redes Sociais Online Populares Elementos das Redes Sociais Online Nesta seção, discutimos várias funcionalidades oferecidas pelas principais aplicações de redes sociais online atuais. O objetivo desta seção não é prover uma lista completa e exaustiva de funcionalidades, mas apenas descrever as mais relevantes. Perfis dos usuários: Redes sociais online possuem muitas funcionalidades organizadas ao redor do perfil do usuário, na forma de uma página individual, que oferece a descrição de um membro. Perfis podem ser utilizados não só para identificar o indivíduo no sistema, mas também para identificar pessoas com interesses em comum e articular novas relações. Tipicamente, perfis contêm detalhes demográficos (idade, sexo, localização, etc.), interesses (passatempos, bandas favoritas, etc.), e uma foto. Além da adição de texto, imagens e outros objetos criados pelo usuário, o perfil de um usuário na rede social também contém mensagens de outros membros e listas de pessoas identificadas como seus amigos na rede. Perfis são geralmente acessíveis por qualquer um que tenha uma conta na rede social online ou podem ser privados, de acordo com as políticas de privacidades definidas pelo usuário. Recentemente, Boyd e colaboradores [34] mostraram que, para a maior parte dos usuários de redes sociais online, existe uma forte relação entre a identidade do indivíduo real e seu perfil na rede social. Atualizações: Atualizações são formas efetivas de ajudar usuários a descobrir conteúdo. Para encorajar usuários a compartilhar conteúdo e navegar por conteúdo compartilhado por amigos, redes sociais online geralmente fazem as atualizações imediatamente visíveis aos amigos na rede social. Burke e colaboradores [39] conduziram um estudo utilizando dados de 140,000 novos usuários do Facebook para determinar que atividades como atualizações são vitais para que novos usuários contribuam para o sistema. Como atualizações podem receber comentários de outros usuários, elas também são formas especiais de comunicação em redes sociais online.

85 68 Minicursos Livro Texto Comentários: A maior parte das aplicações de redes sociais online permite que usuários comentem o conteúdo compartilhado por outros. Alguns sistemas também permitem que usuários adicionem comentários nos perfis de outros usuários. Comentários são um meio primordial de comunicação em redes sociais online, e também podem ser interpretados como expressão de relações sociais [19, 47]. Como exemplo, usuários do YouTube podem comentar os vídeos armazenados por outros no sistema, enquanto que tanto no Facebook quanto no Orkut, usuários podem adicionar comentários às fotos de outros. Da mesma forma, usuários do LiveJournal podem postar comentários em blogs, etc. Avaliações: Em muitas redes sociais online, o conteúdo compartilhado por um usuário pode ser avaliado por outros usuários. Avaliações podem aparecer em diferentes níveis de granularidade e formas. No Facebook, por exemplo, usuários podem apenas gostar de uma postagem, clicando no botão I like this. De fato, estatísticas recentes indicam que cada usuário do Facebook avalia, em média, 9 objetos por mês [5]. Ja no YouTube, vídeos podem ser avaliados com até 5 estrelas, de forma similar à avaliação empregada na categorização de hotéis. O YouTube ainda provê uma avaliação binária (positiva ou negativa) para os comentários recebidos por vídeos, na tentativa de filtrar comentários ofensivos ou contendo alguma forma de spam. Avaliações de conteúdo são úteis de várias formas. Como exemplo, elas ajudam usuários de sistemas como o YouTube a encontrar e identificar conteúdo relevante. Avaliações podem ainda ajudar administradores a identificar conteúdo de baixa qualidade ou mesmo conteúdo inapropriado. Além disso, avaliações podem ser utilizadas para identificar conteúdo em destaque, para suportar sistemas de recomendação, etc. Uma rede social online que coloca as avaliações dos usuários no centro do sistema é o Digg. O Digg permite que usuários avaliem URLs, notícias ou estórias e utiliza aquelas mais votadas para expor o conteúdo mais popular [77]. Listas de Favoritos: Várias aplicações sociais utilizam listas de favoritos para permitir que usuários selecionem e organizem seu conteúdo. Listas de favoritos ajudam usuários a gerenciar seu próprio conteúdo e podem ser úteis para recomendações sociais. Como exemplo, usuários podem manter listas de vídeos favoritos no YouTube e de fotos favoritas no Flickr. Nesses sistemas, usuários podem navegar na lista de favoritos de outros usuários para buscar novos conteúdos [42]. Conseqüentemente, listas de favoritos também facilitam a descoberta de conteúdo e a propagação de informação. Sistemas como o Orkut e o Twitter também provêem listas de favoritos (fãs). Listas de Mais Populares (Top Lists): Tipicamente, redes sociais online que têm o compartilhamento de conteúdo como elemento central do sistema, como o You- Tube que é centrado no compartilhamento de vídeos, provêem listas de conteúdo mais popular ou usuários mais populares. Geralmente, essas listas são baseadas em avaliações ou outras estatísticas do sistema relativas ao conteúdo (ex: número de visualizações, avaliações, ou comentários) ou relativas aos usuários (ex: número de assinantes).

86 XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos - SBRC Metadados: Em várias aplicações de redes sociais online, tais como o YouTube e o Flickr, usuários tipicamente associam metadados, como título, descrição e tags, ao conteúdo compartilhado. Metadados são essenciais para recuperação de conteúdo em redes sociais online, uma vez que grande parte dos serviços de informação (p.ex: busca, organização de conteúdo, recomendação, propaganda) ainda utilizam os metadados (particularmente as tags) como principal fonte de dados [33] Teoria de Redes Complexas da área de redes complexa Redes sociais online são inerentemente redes complexas. Consequentemente, vários estudos recentes analisaram as características de diferentes redes sociais online utilizando como base teorias existentes da área de redes complexas [15, 87, 50, 72, 79, 23, 28]. De fato, o estudo de redes complexas cobre um grande número de áreas e sua teoria tem sido utilizada como ferramenta para entender vários fenômenos, incluindo o espalhamento de epidemias [88], propagação de informação [115], busca na Web [38], e consequências de ataques a redes de computadores [17]. A seguir, várias propriedades estatísticas e métricas comumente utilizadas para analizar e classificar rede complexas são apresentadas na seção As seções e discutem propriedades específicas comumente associadas a várias redes complexas, a saber, redes small-world e redes power-law, respectivamente. Uma revisão detalhada sobre métricas e teoria de redes complexas pode ser encontrada na referência [93] Métricas para o Estudo de Redes Complexas Uma rede é um conjunto de elementos, que chamamos de vértices ou nodos, com conexões entre eles, chamadas de arestas. A estrutura topológica de uma rede pode ser então modelada por um grafo, que, por sua vez, pode ser caracterizado a partir de diversas métricas, discutidas a seguir. Assume-se que o leitor tenha um conhecimento sobre a terminologia utilizada em teoria de grafos Grau dos Vértices Uma característica importante da estrutura de uma rede é a distribuição dos graus de seus vértices. Tal distribuição já foi caraterizada em várias redes (ex: redes de s[64], a topologia da Internet [56], a Web [22], e redes neurais [36]) como seguindo uma lei de potência. Em outras palavras, a probabilidade de um nodo ter grau k é proporcional a k α, Consequentemente, uma métrica comumente utilizada para comparar diferentes redes é o expoente α, obtido através de uma regressão linear. Valores típicos para o expoente α ficam entre 1.0 e 3.5 [54]. Para redes direcionadas, é comum analisar as distribuições doso grau dos nodos em ambas as direções, isto é, a distribuição do grau de entrada e a distribuição do grau de saída. Como exemplo, a Figura 2.1 mostra as distribuições dos graus de entrada (esquerda) e de saída (direita) para um grafo formado a partir das interações entre usuários de vídeos do YouTube [23, 28]. Note que a curva da regressão linear, utilizada para se calcular o expoente α, também é exibida nesses gráficos. Ferramentas como o Gnuplot [6] e o Matlab [9] podem ser utilizados para realizar a regressão e calcular o valor de α. Para

87 70 Minicursos Livro Texto # de nodos α = fit, R 2 = Grau de entrada # de nodos α = fit, R 2 = Grau de saida Figura 2.1. Distribuições dos Grau sde Entrada e de Saída em um Grafo de Interações entre Usuários através de Vídeos do YouTube verificar a acurácia da regressão, é comum medir o coeficiente de determinação R 2 [109]. Quanto mais próximo o valor de R 2 for de 1 (regressão perfeita), menor será a diferença entre o modelo de regressão e os dados reais Coeficiente de Agrupamento O coeficiente de agrupamento (clustering coefficient) de um nodo i, cc(i), é a razão entre o número de arestas existentes entre os vizinhos de i e o número máximo de arestas possíveis entre estes vizinhos. Como exemplo, a Figura 2.2 mostra o valor do coeficiente de agrupamento para o nodo escuro em três cenários diferentes 1. No primeiro, todos os vizinhos do nodo estão conectados entre si e, conseqüentemente, o cc do nodo é 1. No segundo cenário, existe apenas 1 aresta entre os vizinhos do nodo dentre as 3 possíveis, deixando o nodo com cc = 1/3. No último cenário, não há nenhuma aresta entre os vizinhos do nodo escuro e, portanto, o cc do nodo é 0. Figura 2.2. Cálculo do Coeficiente de Agrupamento de um Nodo em Três Cenários Diferentes Podemos notar que o coeficiente de agrupamento representa uma medida da densidade de arestas estabelecidas entre os vizinhos de um nodo. O coeficiente de agrupamento 1 Arestas tracejadas não existem e apenas ilustram as possíveis conexões entre os vizinhos do nodo escuro.

88 XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos - SBRC de uma rede, CC, é calculado como a média dos coeficiente de agrupamento de todos os seus nodos Componentes Um componente em um grafo é um conjunto de nodos, onde cada nodo possui um caminho para todos os outros nodos do conjunto. Para grafos direcionados, um componente é chamado de fortemente conectado (SCC - Strongly Connected Component) quando existe um caminho direcionado entre cada par de nodos do conjunto. Um componente é fracamente conectado (WCC - Weakly Connected Component) se o caminho é não direcionado. Um trabalho que se tornou referência no estudo de componentes em redes complexas aborda a estrutura da Web representada por um grafo em que nodos são páginas Web e arestas são elos existentes entre as páginas [38]. Os autores propõem um modelo que representa como os componentes no grafo da Web se relacionam. Este modelo, aplicado somente em grafos direcionados, possui um componente central que é o SCC, chamado também de core, e outros grupos de componentes que podem alcançar o SCC ou serem alcançados por ele. O modelo ficou conhecido como bow tie [38], pois a figura que ilustrada o modelo lembra uma gravata borboleta. (a) Web (b) Fórum de Java (c) Interações com vídeo Figura 2.3. Estrutura dos Componentes da Web [38], do Fórum de Java [118] e do Grafo de Interações de Usuários do YouTube [28] Este modelo tem sido utilizado por outros estudos como forma de comparar a organização dos componentes de um grafo direcionado [118, 28]. A Figura 2.3, por exemplo, ilustra o uso do modelo bow tie para comparar a estrutura dos componentes de três

89 72 Minicursos Livro Texto redes diferentes, a saber, a rede Web, uma rede formada pelas conexões estabelecidas em um Fórum de Java e a rede estabelecidas entre usuários do YouTube. O componente central, core, das figuras corresponde à fração dos nodos do grafo que fazem parte do SCC. O componente in contém os nodos que apontam para algum nodo do core, mas não são apontados por nodos desse componente. Finalmente, o componente out corresponde aos nodos que são apontados por nodos do core. Note que há diferenças estruturais significativas entre as 3 redes: a rede Web é muito mais balanceada, em termos do tamanho dos componentes, enquanto que, para as outras duas, o componente in contém um percentual muito maior dos nodos Distância Média e Diâmetro A distância média de um grafo é o número médio de arestas em todos todos os caminhos mínimos existentes entre todos os pares de nodos do grafo. Normalmente, a distância média é computada apenas no SCC para grafos direcionados ou no WCC para grafos não direcionados, já que não existe caminho entre nodos localizados em componentes diferentes. Outra métrica relacionada é o diâmetro do grafo. O diâmetro é definido como a distância do maior caminho mínimo existente no grafo e, em geral, é também computado somente para nodos do WCC ou do SCC Assortatividade De acordo com Newman [92], assortatividade é uma medida típica de redes sociais. Uma rede exibe propriedades assortativas quando nodos com muitas conexões tendem a se conectar a outros nodos com muitas conexões. Para caracterizar a assortatividade de uma rede, medimos o grau médio de todos os vizinhos dos nodos com grau k, dado por knn(k). A assortatividade ou disassortatividade de uma rede é geralmente estimada avaliando os valores de knn(k) em função de k. Valores crescentes indicam assortatividade, isto é, nodos com graus maiores tendem a se conectar a nodos com um número maior de conexões. Valores decrescentes de knn(k) em função de k, por sua vez, indicam uma rede disassortativa Betweenness Betweeness é uma medida relacionada à centralidade dos nodos ou de arestas na rede. O betweeness B(e) de uma aresta e é definido como o número de caminhos mínimos entre todos os pares de nodos em um grafo que passam por e [95]. Se existem múltiplos caminhos mínimos entre um par de nodos, cada caminho recebe um peso de forma que a soma dos pesos de todos os caminhos seja 1. Conseqüentemente, o betweenness de uma aresta e pode ser expressado como: B(e) = σ e (u,v) u V,v V σ(u,v) (1)

90 XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos - SBRC onde σ(u,v) representa o número de caminhos mínimos entre u e v, e σ e (u,v) representa o número de caminhos mínimos entre u e v que incluem e. O betweenness de uma aresta indica a importância dessa aresta no grafo em termos de sua localização. Arestas com maior betweenness fazem parte de um número maior de caminhos mínimos e, portanto, são mais importantes para a estrutura do grafo. De forma similar, o betweenness pode ser computado para um nodo ao invés de uma aresta. Neste caso, a medida do betweenness mede o número de caminhos mínimos que passam pelo dado nodo. Nodos que possuem muitos caminhos mínimos que passam por eles possuem maior betweenness, indicando uma maior importância para a estrutura da rede Reciprocidade Uma forma interessante de se observar a reciprocidade de um nodo i em um grafo direcionado é medindo a porcentagem dos nodos apontados por i que apontam para ele. Em outras palavras, a reciprocidade (R(i)) é dada por: R(i) = O(i) I(i) O(i) (2) onde O(i) é o conjunto de nodos apontados por i e I(i) é o conjunto de nodos que apontam para i. Outra métrica interessante de ser observada é o coeficiente de reciprocidade ρ, uma métrica que captura a reciprocidade das interações em toda a rede [60]. O coeficiente de reciprocidade ρ é definido pelo coeficiente de correlação entre entidades da matriz de adjacência representativa do grafo direcionado. Em outras palavras, seja a matriz a definida como a i j = 1 se há uma aresta de i para j no grafo, e a i j = 0, caso contrário. Definimos a reciprocidade da rede ρ como : ρ = i j(a i j ā)(a ji ā) i j (a i j ā) 2, (3) onde o valor médio ā = i j a i j /N(N 1) e N é o número de usuários no grafo. O coeficiente de reciprocidade indica se o número de arestas recíprocas na rede é maior ou menor do que o de uma rede aleatória. Se o valor ρ é maior do que 0, a rede é recíproca; caso contrário, ela é anti-recíproca PageRank O PageRank é um algoritmo interativo que assinala um peso numérico para cada nodo com o propósito de estimar sua importância relativa no grafo. O algoritmo foi inicialmente proposto por Brin and Page [37] para ordenar resultados de busca do protótipo de máquina de busca da Google. A intuição por trás do PageRank é que uma página Web

91 74 Minicursos Livro Texto é importante se existem muitas páginas apontando para ela ou se existem páginas importantes apontando para ela. A equação que calcula o PageRank (PR) de um nodo i, PR(i), é definida da seguinte forma: PR(v) PR(i) = (1 d) + d (4) N v S(i) v onde S(i) é o conjunto de páginas que apontam para i, N v denomina o número de arestas que saem do nodo v, e o parâmetro d é um fator que pode ter valor entre 0 e 1. O algoritmo do PageRank tem sido aplicado em outros contextos, como por exemplo, para encontrar usuários experientes em fóruns especializados [118] e usuários influentes no Twitter [116, 73]. Além disso, existem outras modificações do PageRank com propósitos específicos, como por exemplo, a detecção de spam na Web [66] Redes Small-World O conceito de redes small-world ficou bastante conhecido com o famoso experimento de Milgram [84]. Este experimento consistiu de um grupo de voluntários tentando enviar uma carta para uma pessoa alvo através de outras pessoas que eles conheciam. Milgram enviou cartas a várias pessoas. As cartas explicavam que ele estava tentando atingir uma pessoa específica em uma cidade dos EUA e que o destinatário deveria repassar a carta para alguém que ele achasse que poderia levar a carta o mais próximo do seu destino final, ou entregá-la diretamente, caso o destinatário final fosse uma pessoa conhecida. Antes de enviar a carta, entretanto, o remetente adicionava seu nome ao fim da carta, para que Milgram pudesse registrar o caminho percorrido pela carta. Das cartas que chegaram com sucesso ao destino final, o número médio de passos requerido para o alvo foi 6, resultado que ficou conhecido como o princípio dos seis graus de separação. Em termos das propriedades das redes sociais que discutimos, uma rede pode ser considerada small-world se ela tiver duas propriedades básicas: coeficiente de agrupamento alto e diâmetro pequeno [114]. Estas propriedades foram verificadas em várias redes como a Web [18, 38], redes de colaboração científica [91, 94] em que pesquisadores são nodos e arestas ligam co-autores de artigos, redes de atores de filmes [20] em que atores são nodos e arestas ligam atores que participaram do mesmo filme, e redes sociais online [15, 87, 50, 79, 23, 28]. Em particular, Mislove e colaboradores [87] verificaram propriedades small-world em quatro redes sociais online: LiveJournal, Flickr, Orkut, e YouTube Redes Power-Law e Livres de Escala Redes cujas distribuições dos graus dos nodos seguem uma lei de potência (Seção ) são ditas redes power-law. Redes livres de escala (scale free) são uma classe de redes que seguem leis de potência caracterizadas pela seguinte propriedade: nodos de grau alto tendem a se conectar a outros nodos de grau alto. Barabási e colaboradores [22] propuseram um modelo para gerar redes livre de escala, introduzindo o conceito de conexão preferencial (preferential attachment). O modelo diz que a probabilidade de um nodo se conectar a outro nodo é proporcional ao seu grau. Os autores do modelo ainda

92 XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos - SBRC mostraram que, sob certas circunstâncias, este modelo produz redes que seguem leis de potência. Mais recentemente, Li e colaboradores [80] criaram uma métrica para medir se uma rede é livre de escala ou não, além de prover uma longa discussão sobre o tema Técnicas de Coleta de Dados Em um passado recente, redes sociais eram um domínio de sociólogos e antropólogos, que utilizavam pesquisas e entrevistas com pequenos grupos de usuários como ferramentas de coleta de dados [113]. Com o surgimento das redes sociais online, a obtenção de dados reais em larga escala se tornou possível, e pesquisadores de diversas áreas da computação começaram a realizar coletas de dados. Diferentes áreas de pesquisa demandam diferentes tipos de dados e, por isso, existem várias formas de se obter dados de redes sociais online. A Figura 2.4 apresenta possíveis pontos de coleta de dados, que variam desde entrevistas com os usuários até à instalação de coletores localizados em servidores proxy ou em aplicações. A seguir discutimos essas diferentes abordagens, bem como trabalhos que ilustram o uso dessas estratégias Dados dos Usuários Figura 2.4. Possíveis Pontos de Coleta de Dados Um método comum de se analisar o uso de redes sociais online consiste em conduzir entrevistas com usuários desses sistemas. Em particular, esta estratégia tem sido bastante empregada pela comunidade da área de interface homem-máquina [107, 69, 43, 32, 97], para a qual entrevistas estruturadas são as formas mais populares de obtenção de dados. Como exemplo, através de entrevistas com usuários do Facebook, Joinson e seus colaboradores [69] identificaram várias razões pelas quais usuários utilizam o sistema, tais como conexão social, compartilhamento de interesses, compartilhamento e recuperação de conteúdo, navegação na rede social e atualização do seu estado atual. Chapman e Lahav [43] conduziram entrevistas e analisaram os padrões de navegação de 36 usuários de quatro nacionalidades diferentes para examinar diferenças etnográficas no uso de redes sociais online.

93 76 Minicursos Livro Texto Dados de Pontos Intermediários Existem duas técnicas comuns utilizadas para coletar dados de pontos de agregação de tráfego na rede. A primeira consiste em coletar os dados que passam por um provedor de serviços Internet (ISP) e filtrar as requisições que correspondem a acessos às rede sociais online. A segunda consiste em coletar dados diretamente de um agregador de redes sociais. A seguir, discutimos alguns trabalhos que fizeram o uso dessas estratégias Servidores Proxy Figura 2.5. Exemplo de um Servidor Proxy Intermediando o Tráfego entre Clientes e Servidores Coletar dados de um servidor proxy tem sido uma estratégia utilizada em vários estudos sobre o tráfego da Internet [52, 65, 82, 117]. A Figura 2.5 ilustra como um servidor proxy funciona como um agregador de tráfego de seus clientes, podendo ser utilizados para delimitar uma porção da rede, composta por computadores em uma mesma localização geográficas. Dado o crescente interesse por vídeos na Web, alguns trabalhos recentes utilizaram servidores proxy para obter dados do tráfego gerado por sistemas de compartilhamento de vídeos, como o YouTube. Gill e colaboradores [61] caracterizaram o tráfego do YouTube coletando dados de um servidor proxy localizado na universidade de Calgary, no Canadá. Eles mostraram que requisições de HTTP GET, utilizadas para fazer o download de conteúdo do YouTube, correspondem a 99.87% do total das requisições que passam pelo servidor proxy. Eles ainda caracterizaram diversas métricas relacionadas a estas requisições tais como a duração, a idade e a categoria dos vídeos. Mais recentemente, os mesmos autores caracterizam sessões de usuários no YouTube [62]. Eles mostraram que uma sessão típica dura cerca de 40 minutos, caracterizando também o tempo entre sessões e os tipos de conteúdo transferidos em cada sessão. Finalmente, Zink e colaboradores [119] também estudaram o tráfego de vídeos do YouTube coletado no servidor proxy de uma universidade. Eles também analisaram, via simulação, os benefícios da adoção de abordagens de caches locais e globais para vídeos bem como do uso de arquiteturas P2P para

94 XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos - SBRC distribuição de vídeos. De maneira geral, eles mostraram que essas abordagens poderiam reduzir significativamente o volume de tráfego, permitindo acesso aos vídeos de forma mais rápida. Em um trabalho recente, Schneider e colaboradores [105] extraíram dados de redes sociais online de um provedor de acesso a Internet e reconstruíram ações realizadas pelos usuários em suas navegações por diferentes redes sociais online. Em outras palavras, eles criaram o que foi chamado de clickstream [44] para redes sociais online, capturando cada passo da navegação dos usuários do ISP. Eles discutiram amplamente a metodologia de reconstrução dos acessos dos usuários e, com base nesses dados, analisaram as seqüências de requisições realizadas pelos usuários vários sistemas, incluindo o Facebook Agregadores de Redes Sociais Agregadores de redes sociais são sistemas que permitem acesso a várias redes sociais simultaneamente, através de um portal único. Esses sistemas ajudam usuários que utilizam várias redes sociais online a gerenciar seus perfis de uma forma mais simples e unificada [70, 106]. Ao se conectarem a um agregador de redes sociais online, usuários podem acessar suas contas através de uma interface única, sem precisar se conectar em cada rede social separadamente. Isto é feito através de uma conexão HTTP em tempo real realizada em duas etapas: a primeira etapa ocorre entre o usuário e o agregador de redes sociais, enquanto a segunda etapa ocorre entre o sistema agregador e as redes sociais. Agregadores tipicamente comunicam com redes sociais online através de APIs, como o OpenSocial [7], e todo o conteúdo é exibido através da interface do sistema agregador. A Figura 2.6 descreve o esquema de interação entre os usuários, um sistema agregador e algumas redes sociais online. Através dessa interface, um usuário pode utilizar várias funcionalidades de cada rede social que ele está conectado, tais como checar atualizações de amigos, enviar mensagens e compartilhar fotos. Figura 2.6. Ilustração de um Usuário se Conectando a Múltiplas Redes Sociais Online Simultaneamente Através de um Portal Agregador Recentemente, a partir de uma colaboração com um agregador de redes sociais online, nós coletamos dados da navegação dos usuários (i.e., clickstream) em 4 redes sociais online: Orkut, Hi5, MySpace e LinkedIn [30]. A Tabela 2.2 mostra o número de usuários, sessões e requisições HTTP para cada uma dessas redes. Baseados nesses dados e em dados coletados do Orkut, nós examinamos o comportamento dos usuários

95 78 Minicursos Livro Texto nas redes sociais online, caracterizando as interações estabelecidas entre eles através das várias atividades realizadas. # usuários # sessões # requisições Orkut Hi MySpace LinkedIn Total Tabela 2.2. Sumário dos Dados Obtidos de um Agregador de Redes Sociais Online Dados de Servidores de Redes Sociais Online Idealmente, servidores de aplicações de redes sociais online são os locais mais adequados para a coleta de dados, uma vez que eles têm uma visão completa de todas as ações e atividades realizadas por todos os usuários do sistema um dado período de tempo. Entretanto, o acesso a dados armazenados por estes servidores, ainda que anonimizados, é tipicamente muito difícil. Dentre os poucos trabalhos que utilizaram dados obtidos diretamente de servidores de redes sociais online, podemos citar o estudo de Chun e seus colaboradores [47] sobre as interações textuais entre os usuários do Cyworld, uma rede social bastante popular na Coréia do Sul. Eles compararam as propriedades estruturais da rede de amizades explícita criada naquela aplicação com as propriedades da rede implícita estabelecida a partir de trocas de mensagens no livro de visitas do Cyworld, discutindo diversas similaridades e diferenças. Citamos também o trabalho de Baluja e colaboradores, que utilizaram dados do histórico de navegação de usuários do YouTube para criar um grafo onde cada vídeo é um nodo e arestas ligam vídeos freqüentemente vistos em seqüência. Baseados nesse grafo, eles criaram um mecanismo capaz de prover sugestões de vídeos personalizadas para os usuários do YouTube. Finalmente, Duarte e seus colaboradores [53] caracterizaram o tráfego em um servidor de blogs do UOL ( enquanto nós estudamos a navegação dos usuários em um servidor de vídeos do UOL, chamado UOL Mais [25]. Dada a dificuldade em se obter dados diretamente de servidores de redes sociais online, uma estratégia comum consiste em visitar páginas de redes sociais com o uso de uma ferramenta automática, que chamamos de crawler ou robô, e coletar sistematicamente informações públicas de usuários e objetos. Tipicamente, os elos entre usuários de uma rede social online podem ser coletados automaticamente, permitindo que os grafos de conexões entre os usuários sejam reconstruídos. Essa estratégia tem sido amplamente utilizada em uma grande variedade de trabalhos, incluindo estudos sobre a topologia das redes sociais online [87, 16], padrões de acesso no YouTube [41] e interações reconstruídas através de mensagens trocadas pelos usuários [112]. A seguir discutimos vários aspectos relacionados à coleta de dados de redes sociais online.

96 XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos - SBRC Figura 2.7. Exemplo de Busca em Largura em um Grafo Coleta por Amostragem Idealmente, é sempre mais interessante coletar o grafo inteiro de uma rede social online para evitar que a coleta seja tendenciosa a um grupo de usuários da rede. Entretanto, na maior parte das vezes, não há uma forma sistemática de se coletar todos os usuários de uma rede social online. Para esses casos é necessário coletar apenas parte do grafo. Uma abordagem comumente utilizada, chamada snowball (ou bola de neve), consiste em coletar o grafo de uma rede social online seguindo uma busca em largura, como ilustra a Figura 2.7. A coleta inicia-se a partir de um nodo semente. Ao coletar a lista de vizinhos desse nodo, novos nodos são descobertos e então coletados no segundo passo, que só termina quando todos os nodos descobertos no primeiro passo são coletados. No passo seguinte todos os nodos descobertos no passo anterior são coletados, e assim sucessivamente. Recomenda-se o uso de um grande número de nodos sementes para evitar que a coleta não fique restrita a um pequeno componente do grafo. Um ponto crucial sobre a coleta por snowball é a interrupção da coleta em um passo intermediário, antes que todos os nodos alcançávels pela busca em largura sejam atingidos. Esta interrupção pode ter que ser forçada para tornar a coleta viável. Em particular, a busca completa em componentes muito grandes pode gastar um tempo excessivamente longo e proibitivo. Entretanto, é importante ressaltar que o resultado de uma coleta parcial pode gerar medidas tendenciosas, tais como distribuições de graus dos nodos com uma tendência maior para valores grandes, o que pode, em última instância, afetar as análises e conclusões observadas. Em outras palavras, os dados obtidos via coleta por snowball com interrupção precisam ser tratados e analisados com cautela. Em outras palavras, o tipo de análise a ser feita precisa ser considerado. Por exemplo, se realizarmos 3 passos da coleta, podemos calcular, com precisão, o coeficiente de agrupamento dos nodos semente. Entretanto, se quisermos computar o coeficiente de agrupamento médio de toda a rede ou outras métricas globais como distribuição de graus, distância média, etc., a coleta por snowball pode resultar em números tendenciosos caso ela não inclua pelo menos um componente completo representativo da rede completa [76, 16]. Uma abordagem bastante difundida consiste em coletar o maior componente fracamente conectado (WCC) do grafo. Mislove e colaboradores [87] argumentam que o

97 80 Minicursos Livro Texto maior WCC de um grafo é estruturamente a parte mais interessante de ser analisada, pois é o componente que registra a maior parte das atividades dos usuários. Além disso, eles mostram que usuários não incluídos no maior WCC tendem a fazer parte de um grande grupo de pequenos componentes isolados ou até mesmo totalmente desconectados. A coleta de um componente inteiro pode ser realizada com uma estratégia baseada em um esquema de busca em largura ou busca em profundidade. Quanto maior o número de sementes utilizadas maior a chance de se coletar o maior componente do grafo. Em trabalhos recentes, nós realizamos uma busca por palavras aleatórias no YouTube para verificar se o componente coletado era o maior componente [28, 23]. Como a maior parte dos usuários encontrados nessas buscas estavam no WCC do nosso grafo, os resultados desse teste sugeriram que o componente coletado era o maior WCC. Mislove e colaboradores [87] argumenta que o maior WCC de um grafo é estruturamente a parte mais interessante de ser analisada, pois é o componente que registra a maior parte das atividades dos usuários. Além disso, eles mostram que usuários não incluídos no maior WCC tendem fazer parte de um grande grupo de pequenos componentes isolados ou até mesmo totalmente desconectados. Figura 2.8. Exemplo de Coleta do WCC em um Grafo Direcionado Note que, em algumas redes sociais online como o Twitter ou o Flickr, o conceito de amizade é direcionado. Ou seja, um usuário u pode seguir um outro usuário v, sem necessariamente ser seguido por ele. Em casos como estes, ou seja, em grafos direcionados, é necessário percorrer as arestas do grafo em ambas as direções a fim de coletar o WCC completamente. Caso contrário, se coletarmos o grafo seguindo as arestas em apenas uma direção, não é garantido que consigamos coletar todos os nodos do WCC. A Figura 2.8 mostra que o conjunto de nodos coletados quando seguimos as arestas em ambas as direções é maior do que quando seguimos apenas uma das direções. Em algumas redes não é possível percorrer o grafo em ambas as direções e, portanto, não é possível coletar o maior WCC. Essa limitação é típica de estudos que envolvem a coleta da Web [38]. Ti-

98 XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos - SBRC picamente, a Web é freqüentemente coletada seguindo apenas uma direção dos elos entre páginas, já que não é possível determinar o conjunto de páginas que apontam para uma página. Uma outra estratégia de coleta por amostragem em redes é baseada em caminhadas aleatórias (random walks) [100]. A idéia básica consiste em, a partir de um nodo semente v, prosseguir selecionando aleatoriamente um dos vizinhos de v, e assim sucessivamente até que um número pre-definido B de nodos tenham sido selecionados. Um mesmo nodo pode ser selecionado múltiplas vezes. Esta é a estratégia de caminhada aleatória mais comum disponível na literatura embora existam outras abordagens que diferem em termos de como os vizinhos são selecionados [81, 101] Assim como a coleta por snowball, a coleta através de caminhadas aleatórias também tem suas limitações: a precisão das estimativas depende não somente da estrutura do grafo mas também da característica sendo estimada. Em particular, dependendo da estrutura do grafo, a coleta pode ficar presa"dentro de um subgrafo. Neste caso, as estimativas podem ser imprecisas se as características do subgrafo não forem representativas da rede como um todo. Para mitigar este problema, Ribeiro e Towsley propuseram uma estratégia de coleta por caminhas aleatórias chamado Frontier sampling, que começa com m nodos sementes[100]. Eles ainda propuseram estimadores sem tendência para várias métricas de redes complexas, incluindo o coeficiente de agrupamento global da rede, usando as arestas coletadas pelo método proposto Coleta em Larga Escala A coleta de grandes bases de dados de redes sociais online geralmente envolve o uso de coletores distribuídos em diversas máquinas. Isso acontece não só devido ao processamento necessário para tratar e salvar os dados coletados, mas também para evitar que servidores de redes sociais interpretem a coleta de dados públicos como um ataque a seus servidores. Uma forma de se realizar tal coleta, conforme descrito em [45], está representada na Figura 2.9. A estratégia consiste em utilizar (1) uma máquina mestre que mantém uma lista centralizada de usuários a serem visitados e (2) máquinas escravas, que coletam, armazenam e processam os dados coletados para identificar novos usuários. Novos usuários identificados pelas máquinas escravas são repassados para a máquina mestre, que por sua vez, distribui novos usuários a serem coletados para as máquinas escravas Coleta por Inspeção de Identificadores Como discutido anteriormente, idealmente, a coleta de uma rede social online deveria incluir a rede completa e não somente uma porção dela. Em alguns sistemas como o MySpace e o Twitter é possível realizar uma coleta completa. Esses sistemas atribuem um identificador (ID) numérico e seqüencial para cada usuário cadastrado. Como novos usuários recebem um identificador seqüencial, podemos simplesmente percorrer todos os IDs, sem ter que verificar a lista de amigos desses usuários em busca de novos IDs para coletar.

99 82 Minicursos Livro Texto Figura 2.9. Exemplo de Coleta Realizada de Forma Distribuída Recentemente, nós realizamos uma coleta do Twitter seguindo essa estratégia. Nós solicitamos aos administradores do Twitter a permissão para realizar uma coleta em larga escala. Em resposta, eles adicionaram os endereços IPs de 58 máquinas sob nosso controle em uma lista branca, com permissão para coletar dados. Cada uma das 58 máquinas, localizadas no Max Planck Institute for Software Systems (MPI-SWS), na Alemanha 2, teve permissão para coletar dados a uma taxa máxima de 20 mil requisições por hora. Utilizando a API do Twitter, nosso coletor investigou todos os 80 milhões de IDs de forma seqüencial, coletando todas as informações públicas sobre esses usuários, bem como seus elos de seguidores e seguidos e todos os seus tweets. Dos 80 milhões de contas inspecionadas, nós encontramos cerca 55 milhões em uso. Isso acontece porque o Twitter apaga contas inativas por um período maior do que 6 meses. No total, coletamos cerca de 55 milhões de usuários, quase 2 bilhões de elos sociais e cerca de 1.8 bilhões de tweets. Ao inspecionar as listas de seguidores e seguidos coletadas, nós não encontramos nenhum identificador acima dos 80 milhões inspecionados, sugerindo que nós coletamos todos os usuários do sistema na época. Esses dados foram utilizados recentemente em dois trabalhos, um sobre detecção de spammers no Twitter [24] e o outro sobre medição de influência no Twitter [40]. Torkjazi e colaboradores [108] também exploraram o uso de IDs sequenciais para inspecionar o surgimento de novos usuários no MySpace. 2 Esta coleta foi realizada durante uma visita de 5 meses ao MPI-SWS

100 XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos - SBRC Coleta em Tempo Real Redes sociais online possibilitam que usuários comuns expressem suas opiniões sobre os mais diversos assuntos, e propaguem informações que consideram relevantes em tempo real. É interessante notar como a interatividade e a avaliação do fluxo de informações em tempo real passou a ser um fator importante para várias aplicações Web, que monitoram fenômenos dinâmicos ocorridos na Web. Como exemplo, Google e Bing já indexam tweets públicos como forma de prover busca por informação em tempo real. Do ponto de vista científico, informações disponibilizadas em tempo real na Web têm sido utilizadas de diferentes formas. O Google Insights 3, por exemplo, permite que o usuário consulte informações geográficas e temporais relacionadas ao volume de uma determinada consulta, permitndo também que o usuário salve essas informações em formato CSV. De fato, informações extraídas em tempo real do Google Insights foram utilizadas para demonstrar que o volume de buscas na Web permite monitorar eventos tais como o nível de desemprego e a ocorrência de doenças em tempo real [46, 63]. Em particular, Ginsberg e colaboradores [63] propuseram um método para monitorar ocorrências de gripe baseado em buscas realizadas no Google. Eles mostraram que, em áreas com grande população de usuários de máquinas de buscas, o volume de buscas relacionadas à gripe é proporcional à ocorrência da doença. Em um trabalho recente, Sakaki e colaboradores [103] mostraram o poder da informação disponibilizada em tempo real nas redes sociais online propondo um mecanismo para detecção de ocorrências de terremotos baseado em monitoramento do Twitter. A abordagem, que consiste em simplesmente identificar tweets relacionados a terremotos por região, foi capaz de enviar alertas sobre terremotos mais rapidamente do que agências meteorológicas. Mais recentemente, Tumasjan e colaboradores [110] mostraram que opiniões identificadas em tweets relacionados à eleição federal alemã foi capaz de refletir o sentimento político registrado fora das redes sociais. Para o caso específico do Twitter, é bastante simples coletar informações em tempo real, uma vez que o sistema oferece uma API com diversas opções relacionadas à coleta de dados em tempo real. Como exemplo, para coletar em tempo real uma amostra aleatória de tweets públicos basta executar o seguinte comando em algum terminal UNIX, fornecendo o usuário e senha de um usuário registrado no Twitter. curl -ulogin:senha Utilizando APIs No contexto de desenvolvimento Web, uma API é tipicamente um conjunto de tipos de requisições HTTP juntamente com suas respectivas definições de resposta. Em aplicações de redes sociais online é comum encontrarmos APIs que listam os amigos de um usuário, seus objetos, suas comunidades, etc. APIs são perfeitas para a coleta de dados de redes sociais online, pois oferecem 3

101 84 Minicursos Livro Texto Figura Exemplo da API do Twitter: os dados em formatos estruturados como XML e JSON. Como exemplo, a Figura 2.10 mostra o resultado de uma busca por informações de um usuário no Twitter. Além dessa função, o Twitter ainda oferece várias outras funções em sua API. Com a API do Twitter é possível coletar 5000 seguidores de um usuário através de uma única requisição. A coleta dessa informação através do sítio Web convencional necessitaria de centenas de requisições, visto que o Twitter só mostra alguns seguidores por página. Além disso, cada página conteria uma quantidade muito grande de dados desnecessários, que deveriam ser tratados e excluídos. Vários sistemas possuem APIs, incluindo Twitter, Flickr, YouTube, Google Mapas, Yahoo Mapas, etc. Com tantas APIs existentes, é comum ver aplicações que utilizam duas ou mais APIs para criar um novo serviço, que é o que chamamos de Mashup. Uma interessante aplicação chamada Yahoo! Pipes [13], permite a combinação de diferentes APIs de vários sistemas para a criação automatizada de Mashups Ferramentas e Bibliotecas Desenvolver um coletor pode ser uma tarefa bastante complicada devido à diversidade de formatos de páginas. Entretanto, coletar redes sociais online é, e m geral, diferente de coletar páginas da Web tradicional. As páginas de uma rede social online são, em geral, bem estruturadas e possuem o mesmo formato, pois são geradas auto maticamente, enquanto que, na Web tradicional, as páginas podem ser criadas por qualquer pessoa em qualquer formato. Além disso, como cada indivíduo ou objeto em uma rede social, em geral, possui um identificador único, temos certeza sobre quais as informações obtivemos quando coletamos uma página. Existem várias ferramentas que podem ser utilizadas para se coletar dados de redes sociais online. Como cada pesquisa requer um tipo de coleta e cada coleta de dados possui sua particularidade, desenvolver o próprio coletor pode ser necessário. A Figura 2.11 mostra o uso da biblioteca LWP na linguagem Perl. Este código realiza a coleta dos seguidores de um usuário no Twitter através de sua API. De maneira similar, o código

102 XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos - SBRC em Python da Figura 2.12 utiliza a biblioteca URLLIB para realizar a mesma tarefa. O resultado da execução dos coletores é a lista de seguidores de um usuário do Twitter em formato XML, como ilustra a Figura Figura Exemplo de Uso da Biblioteca LWP em Perl Figura Exemplo de Uso da Biblioteca URLLIB em Python Ética dos Coletores É importante ressaltar que o uso de ferramentas automáticas de coleta (coletores ou robôs), se feito sem o devido cuidado, pode causar problemas de sobrecarga nos servidores alvos da coleta, o que, em última instância, pode afetar a qualidade de serviço da aplicação alvo. Para evitar que isto aconteça, muitos servidores adotam um protocolo conhecido como Robots.txt, no qual sítios Web regulamentam o que pode e o que não pode ser coletado do sistema. Este método é bastante utilizado pelos administradores de sistemas para informar aos robôs visitantes quais diretórios de um sítio Web não devem ser coletados. Ele se aplica a qualquer tipo de coleta, seja ela parte de uma pesquisa sobre redes sociais online, ou um dos componentes centrais de uma máquina de busca como o Google [37]. O Robots.txt nada mais é do que um arquivo que fica no diretório raiz dos sítios e contém regras para coleta. Estas regras podem ser direcionadas a robôs específicos ou podem ser de uso geral, tendo como alvo qualquer robô. Ao visitar um site, os robôs devem primeiramente buscar pelo arquivo Robots.txt a fim de verificar suas permissões. Exemplos desses arquivos são:

103 86 Minicursos Livro Texto Figura Resultado da Execução dos Coletores em Perl e Python A seguir mostramos um exemplo simples de regra em um arquivo Robots.txt. Essa regra restringe todos os crawlers de acessarem qualquer conteúdo no sistema. User-agent: * Disallow: / É possível ainda especificar restrições a alguns robôs específicos ou restringir o acesso a alguns diretórios específicos. Como exemplo, o sítio Web oferece restrições para todos os robôs nos seguintes diretórios. User-agent: * Disallow: /PPZ/ Disallow: /Portal/ Disallow: /Java/ Disallow: /Servlets/ Disallow: /GMC/foto/ Disallow: /FotoShow/ Disallow: /Esportes/foto/ Disallow: /Gente/foto/ Disallow: /Entretenimento/Ego/foto/

104 XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos - SBRC No caso de coleta de redes sociais online, é importante verificar não só o arquivo Robots.txt dos sistemas, mas também os termos de uso do sistema Dados de Aplicações Em uma tentativa bem sucedida de enriquecer a experiência dos usuários de redes sociais online, o Facebook realizou uma de suas maiores inovações: abriu sua plataforma para desenvolvedores de aplicações [4]. Com esta inovação, desenvolvedores são capazes de criar diferentes tipos de aplicações. Com o sucesso no Facebook, outros sistemas como Orkut e MySpace também adotoram essa estratégia. Como consequência, o número e a variedade de aplicações criadas nestes sistemas cresceram significativamente. O Facebook sozinho possui atualmente mais de 81,000 aplicaçõess 4 [2]. Empresas como a Zynga, especializadas em desenvolver essas aplicações, contam com mais de 80 milhões de usuários registrados em suas aplicações [2]. Figura Funcionamento de Aplicações no Facebook e no Orkut A Figura 2.14 mostra o funcionamento de uma aplicação terceirizada em execução em redes sociais online como o Facebook ou o Orkut. Aplicações são caracterizadas pela presença de um servidor da rede social intermediando toda a comunicação entre o cliente e o servidor da aplicação. Tipicamente, o cliente envia a requisição ao servidor da rede social online, que a repassa ao servidor da aplicação. Então, o servidor da aplicação manda de volta a resposta ao servidor da rede social, que a repassa ao cliente [90]. Aplicações podem ser utilizadas para o estudo de interações entre os usuários que utilizam as aplicações e também podem ser úteis para coletar outras informações dos usuários, tais como lista de amigos e atividades executadas durante uma sessão. Alguns trabalhos fizeram uso dessa estratégia para estudar os usuários de redes sociais online. Nazir e colaboradores [89] analisaram características de aplicações no Facebook, desenvolvendo e lançando suas próprias aplicações. Em particular, eles estudaram a formação 4 Uma grande lista de aplicações do Facebook pode ser encontrada na seguinte referência [3].

105 88 Minicursos Livro Texto de comunidades online a partir de grafos de interação entre os usuários de suas aplicações. Mais recentemente, os mesmos autores estudaram várias características relacionadas ao desempenho de suas aplicações no Facebook [90] Extração de Informação A extração e o tratamento de informação a partir dos dados coletados são etapas essenciais para permitir diferentes análises incluindo identificação de padrões de comportamento de usuários em diferentes sistemas, identificação de tópicos de interesse dos usuários, etc. Nesta seção, discutimos brevemente os principais desafios relacionados a essas etapas. Em particular, a identificação de entidades nomeadas, tais como pessoas, organizações e produtos, encontradas em porções de texto, assim como a derivação de relacionamentos entre estas entidades, representam importantes problemas, com diversas aplicações interessantes. O nosso objetivo nesta seção não é detalhar todas as particularidades e soluções para estes problemas, que são tipicamente abordados por pesquisadores de outras áreas tais como Bancos de Dados, Recuperação de Informação, Mineração de Dados e Processamento de Linguagem Natural. Entretanto, reconhecendo a necessidade de expertises complementares para o estudo de redes sociais online, achamos benéfico para o leitor o contato, ainda que superficial, com estes tópicos Visão Geral As redes sociais online são atualmente importantes plataformas para produção, processamento e fluxo de informação. Tal informação pode se originar dentro das redes ou fora delas e pode ser utilizada como fonte primária ou complementar para derivar conhecimento sobre a própria rede, seus membros, seus temas, suas comunidades, etc. No entanto, esta informação quase sempre ocorre em um formato textual, não estruturado, em linguagem natural e até mesmo em estilo telegráfico ou informalmente codificado. Isso é um grande empecilho para que esta informação possa ser processada de maneira automática e para que dela se possa derivar conhecimento latente. Como exemplo, uma mesma entidade (p.ex: uma pessoa ou uma localidade) pode ser referenciada de várias formas, devido às variações introduzidas por diferentes formas de grafia, aspectos regionais ou culturais, uso de abreviaturas, erros tipográficos e outras razões associadas com o uso convencional. Em contextos já bastante explorados como sítios e páginas da Web, técnicas de áreas como Recuperação de Informação, Mineração de Dados e Processamento de Linguagem Natural têm sido aplicadas com muito sucesso para extrair informação e derivar conhecimento de corpus textuais. No entanto, no contexto de redes sociais online, este corpus tem uma natureza totalmente diversa. De fato, nestas redes, o corpus textual é formado por micro-documentos como tweets, blog posts, comentários, feeds, tags, cujo tratamento deve ser necessariamente diferente do que é normalmente aplicado a, por exemplo, páginas Web. Além disto, dado o caráter informal de várias informações disponibilizadas em redes sociais online, técnicas de processamento de linguagem natural são difíceis de serem aplicadas devido à ausência de padrões linguísticos. Além disso, nos corpora textuais encontrados em redes sociais online existe muito lixo e ruído informacional (palavras escritas erradas, de baixa qualidade sintática ou semântica) dificultando esta tarefa ainda mais.

106 XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos - SBRC Por exemplo, técnicas de extração aberta de informações na Web [55] que se baseiam em modelos linguísticos gerais de como relacionamentos são expressos em um idioma, são o estado da arte em extração de entidades e relacionamentos de páginas Web. No entanto, como os modelos utilizados nestas técnicas são construídos a partir de características linguísticas através da identificação de partes de discurso nos documentos-alvo, elas dificilmente poderiam ser aplicadas em micro-documentos (por exemplo, tweets), onde estas características podem não se apresentar. Apesar das dificuldades mencionadas, a extração de informações contidas no corpus textual de redes sociais pode ajudar a responder de forma automática e efetiva questões como: Quem fala com quem sobre que assunto? Quem são os atores principais nas redes? Onde estão localizados? Que assuntos e tópicos emergem, se disseminam e desaparecem nos eco-sistemas sociais digitais? Que indivíduos e grupos promovem e suprimem estes assuntos e tópicos? Qual a polaridade (positiva, negativa ou neutra) das opiniões emitidas na rede sobre assuntos, pessoas, empresas, etc.? Um Exemplo: Observatório da Web Um exemplo de como a identificação de entidades é uma tarefa importante para a análise de redes sociais online é o Observatório das Eleições , que é uma instância do Observatório da Web [104], projeto desenvolvido no âmbito do InWeb (Instituto Nacional de Ciência e Tecnologia para a Web). Este observatório foi desenvolvido para monitorar, em tempo real, o que estava sendo veiculado sobre as eleições de 2010 nas várias mídias e pelos vários usuários da Web. O seu objetivo era ajudar a traçar um panorama do cenário eleitoral do ponto de vista das informações e das opiniões que circulavam na Web e nas redes sociais online, incluindo jornais, revistas, portais e o Twitter. Foi implementado como um portal utilizando dezenas de ferramentas softwares inéditas de captura e análise de dados baseadas em código livre ou aberto. As entidades correlatas ao contexto das eleições foram o alvo principal do monitoramento. Isso incluía além dos candidatos à presidência, políticos com influência na eleição, como o ex-presidente Lula. Em muitos casos, o monitoramento era concentrado em eventos, ou seja, acontecimentos importantes no contexto observado, tais como um debate, por exemplo, e que pudessem ter um grande efeito no conteúdo das fontes observadas. A partir da identificação das entidades no textos coletados em tempo real, é possível gerar uma série de produtos de análise e visualização. Um exemplo de um destes produtos é apresentado na Figura

107 90 Minicursos Livro Texto Figura Exemplo de Visualização de Dados Gerados a Partir da Identificação de Entidades no Observatório das Eleições. No observatório, antes da extração propriamente dita, é realizado um préprocessamento dos textos coletados, incluindo a padronização da codificação dos caracteres, a eliminação de código HTML, cabeçalhos e anúncios de páginas coletadas através de feeds, e o uso de métodos tradicionais de pré-processamento de textos [83] tais como a remoção de stop words (palavras de pouco valor informacional como artigos, preposições e conjunções) e o stemming, que consiste na extração dos radicais das palavras do texto. A identificação de entidades nos textos é feita através da ferramenta Illinois Named Entity Tagger [98], que utiliza técnicas de processamento de linguagem natural para identificar referências a entidades (pessoas, organizações, locais, etc.) em texto livre. Apos a fase de identificação, segue-se uma fase de desambiguação de entidades. Isso é necessário porque os métodos identificação de entidades têm dificuldade, em geral, de diferenciar José Serra de Serra da Piedade, ou Lula presidente de Lula Molusco. Para isso, um método de classificação foi utilizado para aprender a associar entidades a determinados contextos. A Figura 2.16 ilustra um RSS feed processado para identificação de entidades pelo Observatório das Eleições. As tags são usadas como identificadores para distinguir as duas entidades em todos os textos processados. A pré-candidata do PT à Presidência da República <Person2> Dilma Rousseff </Person2>, quer juntar ao seu redor o maior número de legendas que hoje estão na base aliada do presidente <Person1> Luiz Inácio Lula da Silva </Person1> Figura Exemplo de RSS Feed com Entidades Identificadas no Observatório das Eleições

108 XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos - SBRC Identificação de Entidades O problema de identificação de entidades nomeadas (Named Entity Recognition NER) consiste em encontrar palavras que ocorrem em um documento ou trecho de texto não estruturado e que façam referência a entidades do mundo real. Este problema tem sido estudado em vários contexto como identificação de nomes de pessoas e companhias em notícias, identificação de genes e proteínas e publicações biomédicas, etc. [48]. A Figura 2.17(a) ilustra o resultado típico da aplicação de um método de extração de entidades. <pessoa> Odorico Paraguaçu <pessoa> foi <cargo> prefeito </cargo> eterno de <local> Sucupira </local>, cidadezinha localizada em algum lugar da <local> Bahia </local>, a qual governou com muita sabedoria e inteligência. Dotado de uma habilidade incrível com as palavras fruto de seu curso na <organização> Universidade de Sourbone </organização>), cativava as massas numa época em que os comícios não tinham nem fanfarra, quanto mais bandas completas. 6 (a) Odorico Paraguaçu foi prefeito eterno de Sucupira pessoa pessoa outro cargo outro outro local (b) Figura Exemplo de um trecho de texto com entidades identificadas (a) e como uma sequência rotulada (b) Uma abordagem comum para o problema de NER é a de rotulamento de sequências. Um documento é representado como uma sequência x de tokens x 1,...,x n e um classificador associa x a uma sequência paralela de rótulos y = y 1,...,y N, onde cada y i é um rótulo pertencente a um conjunto Y. Uma atribuição correta dos rótulos permite a identificação direta das entidades. Por exemplo, na sequência ilustrada na Figura 2.17(b), cada token recebe um rótulo, sendo que um rótulo especial outro é associado aos tokens que não são partes de nomes de entidades. A construção do classificador pode ser feita usando técnicas de aprendizagem de máquina, ou seja, utilizando dados de treinamento que representam exemplos de mapeamento de sequências x para sequências y. Isso é feito, em geral, através de documentos manualmente anotados de forma similar ao que está ilustrado na Figura 2.17(b). Estes classificadores são gerados pelo no aprendizado de modelos sequenciais tais como Hidden Markov Models [58] ou Conditional Random Fields [74] ou suas variações (por exemplo, [49]) Resolução de Entidades Uma vez que as referências a entidades são identificadas em um certo corpus, algumas aplicações podem requerer ainda que sejam estabelecidas correspondências entre referências distintas que se refiram a uma mesma entidade do mundo real. Este problema é conhecido como Resolução de Entidades [31]. Existem na realidade dois subproblemas relacionados ao problema de resolução

109 92 Minicursos Livro Texto de entidades, os quais ilustramos pelos trechos de texto apresentados na Figura D 1 D 2 O Acre é o estado mais à oeste do Brasil, seu território é inteiramente recoberto pela Floresta Amazônica. É também berço de grandes nomes como <pessoa>marina Silva</pessoa>, política, e <pessoa>glória Perez</pessoa>, novelista. Ao lado da então ministra da Casa Civil, <pessoa>dilma Rousseff</pessoa>, <pessoa>lula</pessoa> acabou recebendo uma amostra do óleo na <pessoa>marina</pessoa> da <pessoa>glória</pessoa>, no Rio, para onde o evento foi transferido. D 3 A candidata <pessoa>dilma</pessoa>, vencedora do primeiro turno das eleições, telefonou hoje para a candidata <pessoa>marina</pessoa> do PV e a parabenizou pelo seu desempenho nas urnas. Figura Exemplo de um Trecho de Texto com Entidades Identificadas (a) e como uma Sequência Rotulada (b). O primeiro subproblema consiste em determinar o conjunto de referências distintas no corpus que são utilizadas para se referir a mesma entidade no mundo real. Este é caso de Marina Silva em D 1 e Marina em D 3, e também de Dilma Rousseff em D 2 e Dilma em D 3. Este subproblema é conhecido como Identificação [31] ou Coreferência [68]. Note que este problema também pode ser causado por erros de escrita, formatação, etc., ou mesmo pelo uso de apelidos (p.ex., Dilma ) e anáforas (p.ex., a ministra ). O segundo subproblema consiste em distinguir quando referências muito similares, ou até mesmo exatamente iguais, se referem a diferentes entidades do mundo real. Esse é o caso de Marina em D 3 e em D 2 e também de Glória Perez em D 3 e Glória em D 2. Este problema é chamado de Desambiguação [31]. Note que neste caso específico o problema foi causado por uma falha do processo de identificação de entidades em D 2. Tais problemas são comuns e, dependendo do domínio de aplicação, podem ser exacerbados pelo uso de abreviações. A solução do problema de resolução de entidades pode ser determinante para a qualidade dos resultados obtidos a partir da análise das entidades extraídas. Por outro lado, se neglicenciado, este problema pode comprometer o conhecimento derivado destes resultados. Por exemplo, as análises realizadas pelo Observatório das Eleições poderiam ser seriamente afetadas se referências ao candidato José Serra e à Serra da Piedade não sofressem desambiguação. Na literatura recente, o problema de resolução entidades tem sido tratado através do cálculo da similaridade entre os atributos associados às entidades (no caso de bancos de dados) [51] ou utilizando, quando possível, grafos de co-ocorrência de entidades [31]. Em corpora textuais, ferramentas linguísticas têm sido usadas para solução deste problema [96]. No caso do Observatório das Eleições, o problema foi tratado através de uma solução simples baseada em classificação usando centroides [67], que neste caso são usado para representar o contexto em que determinada entidade é tipicamente encontrada

110 XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos - SBRC em termos de vocabulário recorrente Bases de Dados Disponíveis na Web Vários trabalhos que coletaram dados de redes sociais online oferecem disponibilizam os dados coletados para a comunidade acadêmica. A seguir, algumas bases contendo dados públicos disponíveis na Web são relacionadas. Dados sobre Orkut, Flickr, LiverJournal e YouTube. Foram utilizados no trabalho [87] e estão disponíveis em data-imc2007.html Dados sobre os vídeos de duas categorias inteiras do YouTube. Coletados em 2007 e utilizados no artigo [41]. Disponível em traces/imc2007.html. Dados do Flickr coletados ao longo do tempo. Esses dados foram utilizados na referência [86] e estão disponíveis em org/data-wosn2008.html. Dados sobre a popularidade de vídeos do YouTube com registro do crescimento e fontes dos acessos ao longo do tempo. Foram utilizados na referência [57] e estão disponívis em Grafo completo contendo 55 milhões de usuários do Twitter e cerca de 1.8 bilhões de tweets. Esses dados foram utilizados nas referências [40, 24] e estão disponíveis no endereço Dados sobre o grafo de amizade e postagens de amostra de usuários do Facebook. Utilizados na referência [111] e disponíveis em mpi-sws.org/data-wosn2009.html. Coleção de usuários do YouTube, manualmente classificados como spammers, promoters ou usuários legítimos. Esses dados foram utilizados nos seguintes trabalhos [26, 29, 75]. A base de dados está disponível em dcc.ufmg.br/~fabricio/testcollectionsigir09.html. Coleção de dados do Del.icio.us e do Digg. Coleção utilizada em diferentes artigos e disponível em datasets.html Conclusões Redes sociais online se tornaram extremamente populares e parte do nosso dia a dia, causando o surgimento de uma nova onda de aplicações disponíveis na Web. A cada dia, grandes quantidades de conteúdo são compartilhadas, e milhões de usuários interagem através de elos sociais. Apesar de tanta popularidade, o estudo de redes sociais ainda está em sua infância, já que estes ambientes estão ainda experimentando novas tendências e enfrentando diversos novos problemas e desafios.

111 94 Minicursos Livro Texto Redes sociais online compõem ambientes perfeitos para o estudo de vários temas da computação, incluindo sistemas multimídia e interação humano-computador. Além disso, por permitir que usuários criem conteúdo, aplicações de redes sociais vêm se tornando um tema chave em pesquisas relacionadas à organização e tratamento de grandes quantidades de dados, além de constituírem um ambiente ideal para extração de conhecimento e aplicação de técnicas de mineração de dados. Este trabalho oferece uma introdução ao pesquisador que pretende explorar o tema. Inicialmente, foram apresentadas as principais características das redes sociais mais populares atualmente. Em seguida, discutimos as principais métricas e tipos de análises utilizadas no estudo dos grafos que formam a topologia das redes sociais. Finalmente, sumarizamos as principais abordagens utilizadas para se obter dados de redes sociais online e discutimos trabalhos recentes que utilizaram essas técnicas. Agradecimentos Este trabalho foi parcialmente financiado pelo Instituto Nacional de Ciência e Tecnologia para a Web (InWeb), pelo CNPq, FAPEMIG e UOL ( Referências [1] comscore: Americans viewed 12 billion videos online in may Acessado em Março/2010. [2] Developer analytics. Acessado em Março/2010. [3] Facebook application directory. Acessado em Março/2010. [4] Facebook platform. Acessado em Março/2010. [5] Facebook Press Room, Statistics. info.php?statistics. Acessado em Março/2010. [6] Gnuplot. Acessado em Agosto/2010. [7] Google OpenSocial. Acessado em Março/2010. [8] List of social network web sites. List_of_social_networking_websites. Acessado em Março/2010. [9] Matlab. Acessado em Agosto/2010. [10] Needle in a Haystack: Efficient Storage of Billions of Photos. Facebook Engineering Notes, Acessado em Março/2010.

112 XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos - SBRC [11] New york times. a web site born in u.s. finds fans in brazil. Acessado em Março/2010. [12] New york times. uploading the avantgarde. com/2009/09/06/magazine/06fob-medium-t.htm. Acessado em Julho/2010. [13] Yahoo! pipes. Acessado em Agosto/2010. [14] YouTube fact sheet. Acessado em Março/2010. [15] L. Adamic, O. Buyukkokten, and E. Adar. A social network caught in the web. First Monday, 8(6), [16] Y.-Y. Ahn, S. Han, H. Kwak, S. Moon, and H. Jeong. Analysis of topological characteristics of huge online social networking services. In World Wide Web Conference (WWW), pages , [17] R. Albert, H., Jeong, and A. Barabasi. Error and attack tolerance of complex networks. Nature, 406(6794): , [18] R. Albert, H. Jeong, and A. Barabasi. Diameter of the world wide web. Nature, 401: , [19] N. Ali-Hasan and L. Adamic. Expressing social relationships on the blog through links and comments. In AAAI Conference on Weblogs and Social Media (ICWSM), [20] A. Amaral, A. Scala, M. Barthelemy, and E. Stanley. Classes of small-world networks. 97(21): , [21] B. Williamson. Social network marketing: ad spending and usage. EMarketer Report, Acessado em Março/2010. [22] A. Barabasi and R. Albert. Emergence of scaling in random networks. Science, 286(5439), [23] F. Benevenuto, F. Duarte, T. Rodrigues, V. Almeida, J. Almeida, and K. Ross. Understanding video interactions in YouTube. In ACM Conference on Multimedia (MM), pages , [24] F. Benevenuto, G. Magno, T. Rodrigues, and V. Almeida. Detecting spammers on twitter. In Annual Collaboration, Electronic messaging, Anti-Abuse and Spam Conference (CEAS), [25] F. Benevenuto, A. Pereira, T. Rodrigues, V. Almeida, J. Almeida, and M. Gonçalves. Characterization and analysis of user profiles in online video sharing systems. Journal of Information and Data Management, 1(2): , 2010.

113 96 Minicursos Livro Texto [26] F. Benevenuto, T. Rodrigues, V. Almeida, J. Almeida, and M. Gonçalves. Detecting spammers and content promoters in online video social networks. In Int l ACM Conference on Research and Development in Information Retrieval (SIGIR), pages , [27] F. Benevenuto, T. Rodrigues, V. Almeida, J. Almeida, M. Gonçalves, and K. Ross. Video pollution on the web. First Monday, 15(4), April [28] F. Benevenuto, T. Rodrigues, V. Almeida, J. Almeida, and K. Ross. Video interactions in online video social networks. ACM Transactions on Multimedia Computing, Communications and Applications (TOMCCAP), 5(4):1 25, [29] F. Benevenuto, T. Rodrigues, V. Almeida, J. Almeida, C. Zhang, and K. Ross. Identifying video spammers in online social networks. In Workshop on Adversarial Information Retrieval on the Web (AIRWeb), pages 45 52, [30] F. Benevenuto, T. Rodrigues, M. Cha, and V. Almeida. Characterizing user behavior in online social networks. In ACM SIGCOMM Internet Measurement Conference (IMC), pages 49 62, [31] I. Bhattacharya and L. Getoor. Collective entity resolution in relational data. ACM Trans. Knowl. Discov. Data, 1, [32] J. Binder, A. Howes, and A. Sutcliffe. The problem of conflicting social spheres: effects of network structure on experienced tension in social network sites. In ACM SIGCHI Conference on Human factors in Computing Systems (CHI), pages , [33] S. Boll. Multitube where web 2.0 and multimedia could meet. IEEE MultiMedia, 14(1):9 13, [34] D. Boyd. Why Youth (Heart) Social Network Sites: The Role of Networked Publics in Teenage Social Life. Cambridge, MA, [35] D. Boyd and N. Ellison. Social network sites: Definition, history, and scholarship. Journal of Computer-Mediated Communication, 13(1-2), [36] V. Braitenberg and A. Schüz. Cortex: Statistics and Geometry of Neuronal Connectivity. Springer-Verlag, [37] S. Brin and L. Page. The anatomy of a large-scale hypertextual web search engine. Computer Networks and ISDN Systems, 30(1-7): , [38] A. Broder, R. Kumar, F. Maghoul, P. Raghavan, S. Rajagopalan, R. Stata, A. Tomkins, and J. Wiener. Graph structure in the web. Computer Networks, 33: , [39] M. Burke, C. Marlow, and T. Lento. Feed me: Motivating newcomer contribution in social network sites. In ACM SIGCHI Conference on Human factors in Computing Systems (CHI), pages , 2009.

114 XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos - SBRC [40] M. Cha, H. Haddadi, F. Benevenuto, and K. Gummadi. Measuring user influence in twitter: The million follower fallacy. In In 4th International AAAI Conference on Weblogs and Social Media (ICWSM), [41] M. Cha, H. Kwak, P. Rodriguez, Y.-Y. Ahn, and S. Moon. I tube, you tube, everybody tubes: Analyzing the world s largest user generated content video system. In ACM SIGCOMM Conference on Internet Measurement (IMC), pages 1 14, [42] M. Cha, A. Mislove, and K. Gummadi. A measurement-driven analysis of information propagation in the Flickr social network. In World Wide Web Conference (WWW), pages , [43] C. Chapman and M. Lahav. International ethnographic observation of social networking sites. In ACM SIGCHI Conference on Human factors in Computing Systems (CHI), pages , [44] P. Chatterjee, D. L. Hoffman, and T. P. Novak. Modeling the clickstream: implications for web-based advertising efforts. Marketing Science, 22(4): , [45] D. Chau, Pandit, S. Wang, and C. Faloutsos. Parallel crawling for online social networks. In World Wide Web Conference (WWW), pages , [46] H. Choi and H. Varian. Predicting the present with google trends. ly/2iujv3. Accessed in Jan/2011, [47] H. Chun, H. Kwak, Y. Eom, Y.-Y. Ahn, S. Moon, and H. Jeong. Comparison of online social relations in volume vs interaction: a case study of Cyworld. In ACM SIGCOMM Internet Measurement Conference (IMC), pages 57 70, [48] W. Cohen and S. Sarawagi. Exploiting Dictionaries in Named Entity Extraction: Combining Semi-Markov Extraction Processes and Data Integration Methods. In Proc. 10th ACM SIGKDD Intl. Conf. on Knowl. Discov. and Data Mining, pages 89 98, [49] E. Cortez, A. S. da Silva, M. A. Gonçalves, and E. S. de Moura. Ondux: ondemand unsupervised learning for information extraction. In Proceedings of the 2010 international conference on Management of data, SIGMOD 10, pages , [50] X. Dale and C. Liu. Statistics and social network of YouTube videos. In Int l Workshop on Quality of Service (IWQoS), [51] J. de Freitas, G. L. Pappa, A. S. da Silva, M. A. Gonçalves, E. S. de Moura, A. Veloso, A. H. F. Laender, and M. G. de Carvalho. Active learning genetic programming for record deduplication. In IEEE Congress on Evolutionary Computation, pages 1 8, [52] F. Duarte, F. Benevenuto, V. Almeida, and J. Almeida. Locality of reference in an hierarchy of web caches. In IFIP Networking Conference (Networking), pages , 2006.

115 98 Minicursos Livro Texto [53] F. Duarte, B. Mattos, A. Bestavros, V. Almeida, and J. Almeida. Traffic characteristics and communication patterns in blogosphere. In Conference on Weblogs and Social Media (ICWSM), [54] H. Ebel, L. Mielsch, and S. Bornholdt. Scale free topology of networks. Physical Review E, 66(3):35103, [55] O. Etzioni, M. Banko, S. Soderland, and D. S. Weld. Open information extraction from the web. Commun. ACM, 51(12):68 74, December [56] M. Faloutsos, P. Faloutsos, and C. Faloutsos. On power-law relationships of the Internet topology. In Annual Conference of the ACM Special Interest Group on Data Communication (SIGCOMM), pages , [57] F. Figueiredo, F. Benevenuto, and J. Almeida. The tube over time: Characterizing popularity growth of youtube videos. In Proceedings of the 4th ACM International Conference of Web Search and Data Mining (WSDM), [58] D. Freitag and A. McCallum. Information Extraction with HMM Structures Learned by Stochastic Optimization. In Proc. of the 17th Nat. Conf. on Art. Intell. and 12th Conf. on Innov. Appl. of Art. Intell., pages , [59] E. Gabrilovich, S. Dumais, and E. Horvitz. Newsjunkie: Providing personalized newsfeeds via analysis of information novelty. In World Wide Web Conference (WWW), pages , [60] D. Garlaschelli and M. Loffredo. Patterns of link reciprocity in directed networks. Physical Review Letters, 93(26):268701, [61] P. Gill, M. Arlitt, Z. Li, and A. Mahanti. YouTube traffic characterization: A view from the edge. In ACM SIGCOMM Conference on Internet Measurement (IMC), pages 15 28, [62] P. Gill, M. Arlitt, Z. Li, and A. Mahanti. Characterizing user sessions on YouTube. In IEEE Multimedia Computing and Networking (MMCN), [63] J. Ginsberg, M. H. Mohebbi, R. S. Patel, L. Brammer, M. S. Smolinski, and L. Brilliant. Detecting influenza epidemics using search engine query data. Nature, 457:1012 4, [64] L. Gomes, J. Almeida, V. Almeida, and W. Meira. Workload models of spam and legitimate s. Performance Evaluation, 64(7-8), [65] K. Gummadi, R. Dunn, S. Saroiu, S. Gribble, H. Levy, and J. Zahorjan. Measurement, modeling, and analysis of a peer-to-peer file-sharing workload. In ACM Symposium on Operating Systems Principles (SOSP), [66] Z. Gyöngyi, H. Garcia-Molina, and J. Pedersen. Combating web spam with trustrank. In Int l. Conference on Very Large Data Bases (VLDB), pages , 2004.

116 XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos - SBRC [67] E.-H. Han and G. Karypis. Centroid-based document classification: Analysis and experimental results. In Proceedings of the 4th European Conference on Principles of Data Mining and Knowledge Discovery, pages , [68] J. Hobbs. Coherence and coreference*. Cognitive science, 3(1):67 90, [69] A. Joinson. Looking at, looking up or keeping up with people?: motives and use of Facebook. In ACM SIGCHI Conference on Human factors in Computing Systems (CHI), pages , [70] R. King. When your social sites need networking, BusinessWeek, http: //tinyurl.com/o4myvu. Acessado em Março/2010. [71] B. Krishnamurthy. A measure of online social networks. In Conference on Communication Systems and Networks (COMSNETS), [72] R. Kumar, J. Novak, and A. Tomkins. Structure and evolution of online social networks. In ACM SIGKDD Int l Conference on Knowledge Discovery and Data Mining (KDD), [73] H. Kwak, C. Lee, H. Park, and S. Moon. What is twitter, a social network or a news media? In Int l World Wide Web Conference (WWW), [74] J. D. Lafferty, A. McCallum, and F. C. N. Pereira. Conditional random fields: Probabilistic models for segmenting and labeling sequence data. In Proceedings of the Eighteenth International Conference on Machine Learning, ICML 01, pages , [75] H. Langbehn, S. Ricci, M. Gonçalves, J. Almeida, G. Pappa, and F. Benevenuto. A multi-view approach for detecting spammers and content promoters in online video social networks. Journal of Information and Data Management, 1(3):1 16, [76] S. Lee, P. Kim, and H. Jeong. Statistical properties of sampled networks. Physical Review E, 73(30): , [77] K. Lerman. Social information processing in news aggregation. IEEE Internet Computing, 11(6):16 28, [78] J. Leskovec, L. A. Adamic, and B. A. Huberman. The dynamics of viral marketing. ACM Transactions on the Web (TWEB), 1(1): , [79] J. Leskovec and E. Horvitz. Planetary-scale views on a large instant-messaging network. In World Wide Web Conference (WWW), [80] L. Li, D. Alderson, J. Doyle, and W. Willinger. Towards a theory of scale-free graphs: Definition, properties, and implications. Internet Mathematics, 2(4), [81] L. Lovász. Random Walks on Graphs: A Survey. Combinatorics, 2:1 46, 1993.

117 100 Minicursos Livro Texto [82] A. Mahanti, D. Eager, and C. Williamson. Temporal locality and its impact on web proxy cache performance. Performance Evaluation Journal, 42(2-3): , [83] C. D. Manning, P. Raghavan, and H. Schütze. Introduction to Information Retrieval. Cambridge University Press., [84] S. Milgram. The small world problem. Psychology Today, 2:60 67, May [85] A. Mislove. Online Social Networks: Measurement, Analysis, and Applications to Distributed Information Systems. PhD thesis, Rice University, Department of Computer Science, [86] A. Mislove, H. Koppula, K. Gummadi, P. Druschel, and B. Bhattacharjee. Growth of the flickr social network. In ACM SIGCOMM Workshop on Social Networks (WOSN), pages 25 30, [87] A. Mislove, M. Marcon, K. Gummadi, P. Druschel, and B. Bhattacharjee. Measurement and analysis of online social networks. In ACM SIGCOMM Conference on Internet Measurement (IMC), pages 29 42, [88] C. Moore and M. Newman. Epidemics and percolation in small-world networks. Physical Review E, 61(5):5678, [89] A. Nazir, S. Raza, and C. Chuah. Unveiling facebook: A measurement study of social network based applications. In ACM SIGCOMM Conference on Internet Measurement (IMC), pages 43 56, [90] A. Nazir, S. Raza, D. Gupta, C. Chua, and B. Krishnamurthy. Network level footprints of facebook applications. In ACM SIGCOMM Conference on Internet Measurement (IMC), pages 63 75, [91] M. Newman. The structure of scientific collaboration networks. 98(2): , [92] M. Newman. Assortative mixing in networks. Physical Review E, 89(20):208701, [93] M. Newman. The structure and function of complex networks. SIAM Review, 45: , [94] M. Newman. Coauthorship networks and patterns of scientific collaboration. 101(1): , [95] M. Newman and M. Girvan. Finding and evaluating community structure in networks. Physical Review E, 69(2):26113, [96] V. Ng. Shallow semantics for coreference resolution. In Proceedings of the 20th International Joint Conference on Artificial Intelligence, pages , 2007.

118 XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos - SBRC [97] J. Otterbacher. helpfulness in online communities: a measure of message quality. In ACM SIGCHI Conference on Human factors in Computing Systems (CHI), pages , [98] L. Ratinov and D. Roth. Design challenges and misconceptions in named entity recognition. In Proceedings of the Thirteenth Conference on Computational Natural Language Learning, CoNLL 09, pages , [99] N. O. Report. Social networks & blogs now 4th most popular online activity, Acessado em Março/2010. [100] B. Ribeiro and D. Towsley. Estimating and Sampling Graphs with Multidimensional RandomWalks. In Proceedings ACM SIGCOMM Internet Measurement Conference, [101] C. P. Robert and G. Casella. Monte Carlo Statistical Methods. Springer-Verlag, second edition, [102] P. Rodriguez. Web infrastructure for the 21st century. WWW 09 Keynote, Acessado em Março/2010. [103] T. Sakaki, M. Okazaki, and Y. Matsuo. Earthquake shakes twitter users: realtime event detection by social sensors. In WWW 10: Proceedings of the 19th international conference on World wide web, pages , [104] W. Santos, G. Pappa, W. Meira Jr., D. Guedes, A. Veloso, V. Almeida, A. Pereira, P. Guerra, A. Silva, F. Mourão, T. Magalhães, F. Machado, L. Cherchiglia, L. Simões, R. Batista, F. Arcanjo, G. Brunoro, N. Mariano, G. Magno, M. T. Ribeiro, L. Teixeira, A. S. Silva, B. W. Reis, and R. H. Silva. Observatório da web: Uma plataforma de monitoração, síntese e visualização de eventos massivos em tempo real. In Anais do XXXVII Seminário Integrado de Hardware e Software, SEMISH 10, pages , [105] F. Schneider, A. Feldmann, B. Krishnamurthy, and W. Willinger. Understanding online social network usage from a network perspective. In ACM SIGCOMM Internet Measurement Conference (IMC), pages 35 48, [106] S. Schroeder. 20 ways to aggregate your social networking profiles, Mashable, Acessado em Março/2010. [107] J. Thom-Santelli, M. Muller, and D. Millen. Social tagging roles: publishers, evangelists, leaders. In ACM SIGCHI Conference on Human factors in Computing Systems (CHI), pages , [108] M. Torkjazi, R. Rejaie, and W. Willinger. Hot today, gone tomorrow: On the migration of myspace users. In ACM SIGCOMM Workshop on Online social networks (WOSN), pages 43 48, [109] K. S. Trivedi. Probability and statistics with reliability, queuing and computer science applications. John Wiley and Sons Ltd., Chichester, UK, 2002.

119 102 Minicursos Livro Texto [110] A. Tumasjan, T. Sprenger, P. Sandner, and I. Welpe. Predicting elections with twitter: What 140 characters reveal about political sentiment [111] B. Viswanath, A. Mislove, M. Cha, and K. Gummadi. On the evolution of user interaction in facebook. In Proceedings of the 2nd ACM SIGCOMM Workshop on Social Networks (WOSN 09), [112] B. Viswanath, A. Mislove, M. Cha, and K. P. Gummadi. On the evolution of user interaction in Facebook. In ACM SIGCOMM Workshop on Online Social Networks (WOSN), pages 37 42, [113] S. Wasserman, K. Faust, and D. Iacobucci. Social Network Analysis: Methods and Applications (Structural Analysis in the Social Sciences). Cambridge University Press, [114] D. Watts. Small Worlds: the Dynamics of Networks Between Order and Randomness. Princeton University Press, [115] D. Watts. A simple model of global cascades on random networks. 99(9): , [116] J. Weng, E.-P. Lim, J. Jiang, and Q. He. Twitterrank: finding topic-sensitive influential twitterers. In ACM international conference on Web search and data mining (WSDM), pages , [117] C. Williamson. On filter effects in web caching hierarchies. ACM Transactions on Internet Technology (TOIT), 2(1):47 77, [118] J. Zhang, M. Ackerman, and L. Adamic. Expertise networks in online communities: Structure and algorithms. In World Wide Web Conference (WWW), pages , [119] M. Zink, K. Suh, Y. Gu, and J. Kurose. Watch global, cache local: YouTube network traces at a campus network - measurements and implications. In IEEE Multimedia Computing and Networking (MMCN), 2008.

120 Capítulo 3 Web das Coisas: Conectando Dispositivos Físicos ao Mundo Digital Tiago C. de França, Paulo F. Pires, Luci Pirmez, Flávia C. Delicato, Claudio Farias Abstract In the near future the number of physical devices (also called smart objects) connected to the internet will be massive. Those devices can be wireless sensors, mobile phones or any other electronic device of people's daily lives. The Web of Things (WoT) proposal is to integrate smart objects into the Web so that user will be able to access those physical objects via URLs, browse them, and reuse the resources provided by them in the building of composite Web applications, called mashups. This short course introduces the concepts and technologies involved in the WoT. Following, we present the underlying software architecture currently employed in WoT projects. Finally, we present practical examples of application development using the Sun SPOT platform. Resumo Brevemente será imenso o número de dispositivos físicos (chamados objetos inteligentes) conectados a internet. Esses dispositivos podem ser sensores sem fio, celulares ou qualquer outro aparelho eletrônico do cotidiano das pessoas. A Web das Coisas (WoT, do inglês, Web of Things) propõe que os objetos inteligentes sejam integrados a Web, permitindo, desta forma, que os usuários possam acessar tais objetos através de URLs, realizando pesquisas e reutilizando os recursos dos mesmos em aplicações Web chamadas mashups. Este minicurso introduz os conceitos e tecnologias da WoT e apresenta a arquitetura de software subjacente atualmente empregada. Em seguida, são apresentados exemplos práticos de construção de aplicações baseadas no paradigma da WoT utilizando a plataforma Sun SPOT.

121 104 Minicursos Livro Texto 3.1. Introdução Graças ao impressionante progresso no campo de dispositivos embarcados, objetos físicos tais como eletrodomésticos, máquinas industriais, sensores sem fio e atuadores podem atualmente se conectar a internet. Exemplos desses pequenos e versáteis dispositivos são: Chumby [Chumby 2011], Gumstix [Gumstix 2011], Sun SPOTs [Sun 2011], Ploggs [Ploggs 2011], Nabaztag [Nabaztag 2011], Pokens [Pokens 2011], etc. Segundo a Aliança IPSO (do inglês, IP for Smart Objects), em um futuro próximo um grande número de dispositivos embarcados irá suportar o protocolo IP [Hui 2008]. Assim, muitos objetos do dia a dia (como geladeiras, equipamentos de arcondicionado, dentre outros) brevemente estarão conectados diretamente a internet. A conexão desses objetos do dia a dia com a internet é denominada Internet das Coisas (do inglês, Internet of Things - IoT) [Duquennoy 2009]. A IoT oferece novas oportunidades de projetos para aplicações interativas as quais, além de conter documentos estáticos, conterão informação em tempo real referentes a lugares e objetos do mundo físico. Recentemente surgiu um novo paradigma de desenvolvimento de aplicações inspirado na idéia da IoT, conhecido como Web das Coisas (do inglês Web of Things - WoT) [Duquennoy 2009], [Guinard 2010]. Esse novo conceito se baseia no uso de protocolos e padrões amplamente aceitos e já em uso na Web tradicional, tais como HTTP (Hypertext Transfer Protocol) e URIs (do inglês, Uniform Resource Identifier). O objetivo da WoT é alavancar a visão de conectividade entre o mundo físico e o mundo digital, fazendo com que a Web atual passe a englobar também objetos do mundo físico (chamados objetos inteligentes, do inglês smart things ) os quais passarão a ser tratados da mesma forma que qualquer outro recurso Web. Na WoT, o protocolo HTTP não é utilizado apenas como protocolo de comunicação para transportar dados formatados em conformidade com alguma especificação (como no caso das tecnologias de serviços Web). Em vez disso, o protocolo HTTP é utilizado como mecanismo de suporte padrão a toda interação com os objetos inteligentes. Essa interação ocorre por meio dos principais métodos (GET, POST, PUT e DELETE) desse protocolo, os quais permitem que as funcionalidades dos objetos sejam expostas em interfaces Web bem definidas. Tais interfaces são construídas de acordo com os princípios REST (do inglês, Representational State Transfer) [Fielding 2000], [Guinard e Trifa 2009] os quais permitem que os serviços dos objetos inteligentes sejam expostos como recurso em uma abordagem ROA (do inglês, Resource-Oriented Architecture) [Guo 2010], [Mayer 2010]. Além da padronização e simplificação no processo de desenvolvimento, a utilização do protocolo HTTP também elimina problemas de compatibilidade entre diferentes fabricantes, protocolos e formatos específicos [Duquennoy 2009]. A realização da visão da WoT requer, portanto, que a World Wide Web atual seja estendida de modo que objetos do mundo real e dispositivos embarcados possam ser incorporados a ela de forma transparente. Essa extensão é obtida através da utilização do protocolo HTTP e dos princípios REST na criação de APIs (do inglês, Application Programming Interface) RESTful que façam com os objetos inteligentes se tornem recursos Web. A forma como tais objetos inteligentes são representados e expostos como recursos na Web tem diferentes granularidades, podendo um recurso ser definido como sendo um objeto ou dispositivo sensor individual, como uma rede de

122 XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos - SBRC sensores sem fio (RSSF), ou até mesmo como dados agregados oriundos de diferentes RSSFs. Além disso, através do uso de plataformas de middleware, por exemplo, podem ser providos serviços no topo dos recursos conectados a Web, de modo a facilitar a rápida combinação de múltiplos recursos para criar aplicações de valor agregado denominadas mashups físicos [Delicato et al. 2010], [Guinard et al. 2009]. Esses mashups são aplicações ad-hoc da Web 2.0 que permitem colaboração e compartilhamento de informações através da composição de recursos disponíveis na Web [Bezerra et al. 2009]. O objetivo geral deste minicurso é apresentar o estado da arte no desenvolvimento de aplicações para a Web das Coisas. Seus objetivos específicos são: (i) fornecer uma visão geral do conceito de Internet das Coisas e sua evolução para a Web das Coisas ; (ii) apresentar a arquitetura de software atualmente empregada nos projetos de Web das Coisas ; (iii) apresentar soluções atuais da WoT; e, por fim, (iv) apresentar como aplicações baseadas no conceito da Web das Coisas podem ser desenvolvidas. A plataforma alvo abordada no curso para os dispositivos embarcados será a Sun SPOT [Sun SPOT 2011] Da Internet das Coisas a Web das Coisas Espera-se que em um futuro próximo tanto computadores como objetos físicos estejam conectados a internet [Atzori et al. 2010]. Essa interconexão de dispositivos na internet, chamada Internet das Coisas (IoT, do inglês Internet of Things), possibilitará que tais dispositivos sejam utilizados remotamente por humanos ou até mesmo por outros dispositivos [Tan e Wang 2010]. Dentre as propostas existentes na IoT, está a Web das Coisas, a qual propõe a adoção dos padrões Web a fim de oferecer uma base comum para que diferentes tipos de dispositivos possam ser beneficiados pelas tecnologias existentes na Web, além de facilitar o desenvolvimento de aplicativos para tais dispositivos. Nesta Seção são descritas as principais características da Internet das Coisas, seguida da apresentação da Web das Coisas Internet das Coisas Atualmente, a Internet das Coisas (IoT) vem ganhando grande destaque no cenário das telecomunicações e está sendo considerada a revolução tecnológica que representa o futuro da computação e comunicação [Tan e Wang 2010], [Atzori et al. 2010]. Devido a importância da IoT, o Conselho Nacional de Inteligência dos EUA (NIC) a considera como uma das seis tecnologias civis mais promissoras e que mais impactarão a nação no futuro próximo. O NIC prevê que em 2025 todos os objetos do cotidiano (por exemplo, embalagens de alimento, documentos e móveis) poderão estar conectados a internet [NIC 2008]. Graças ao paradigma IoT, estima-se que uma grande quantidade de objetos estarão conectados à internet, se tornando os maiores emissores e receptores de tráfego da rede. Esses objetos podem ser quaisquer dispositivos, tais como eletrodomésticos, pneus, sensores, atuadores, telefones celulares, entre outros, que possam ser identificados e interligados a internet para trocar informações e tomar decisões para atingir objetivos comuns [Atzori et al. 2010]. A ITU (International Telecommunication Union) Internet Reports (2005) apontou que na Internet das Coisas qualquer objeto capaz de ser conectado em rede poderá se comunicar a qualquer tempo e em qualquer lugar. A Figura 3.1 mostra as novas dimensões do mundo das tecnologias da

123 106 Minicursos Livro Texto comunicação e informação da internet no futuro. Nessa figura é possível observar o que pode ser conectado a internet, quando pode ser conectado e onde pode se conectar. Obviamente, a ampla difusão do paradigma IoT acarretará um forte impacto na vida cotidiana dos usuários. Isso ocorrerá porque diversas aplicações estarão a disposição desses usuários, entre elas: aplicações de controle de ambiente; aplicações de assistência a vida em ambientes de saúde; aplicações de automação e produção industrial, logística, segurança, entre outras [Atzori et al. 2010], [Yun e Yuxin, 2010]. As mudanças proporcionadas pela IoT também trarão novas oportunidades de negócio que, impulsionadas pelas demandas da população, contribuirão de maneira inestimável para a economia [ITU Internet Reports 2005], [Tan e Wang 2010], [Yongjia 2010]. Figura Uma Nova Dimensão, adaptado de [ITU Internet Reports 2005] O termo IoT recebeu diferentes definições na literatura. Algumas definições e pesquisas focaram no termo internet [Atzori et al. 2010] e observaram a IoT do ponto de vista de redes [Atzori et al. 2010]. Outras definições focaram no termo genérico coisas e as pesquisas que focam nesse termo buscam a integração de objetos em um arcabouço comum. Também surgiram definições que focaram em questões semânticas, observando a IoT do ponto de vista da comunicação entre dispositivos distintos. De fato, para a TIC (Tecnologia da Informação e Comunicação), a expressão composta Internet das Coisas representa uma rede mundial de objetos heterogêneos e endereçáveis, interligados e se comunicando através de protocolos de comunicação padronizados. A Figura 3.2 ilustra o fato exposto acima, de que o paradigma da IoT pode ser visto de acordo com três visões principais: uma focada nas coisas, outra focada na semântica e ainda outra cujo foco é a internet [Atzori et al. 2010]. Os trabalhos focados nas coisas buscam apresentar propostas que garantam o melhor aproveitamento dos recursos dos dispositivos e sua comunicação [Atzori et. al 2010]. Por outro lado, os trabalhos que apresentam propostas focadas na semântica dos objetos da IoT são importantes devido a grande quantidade de itens que estarão conectados a internet em um futuro próximo. Tais trabalhos apresentam propostas que estão focadas na representação, armazenamento, interconexão, pesquisa e organização da informação gerada na IoT, buscando soluções para a modelagem das descrições que permitam um tratamento adequado para os dados gerados pelos objetos [Atzori et al. 2010].

124 XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos - SBRC Os trabalhos que focam na visão orientada a internet procuram criar modelos e técnicas para a interoperabilidade dos dispositivos em rede. Um exemplo é o padrão IPSO (IP for Smart Objects), o qual apresenta a proposta 6LowPAN, na qual o protocolo IP é adaptado para ser utilizado em dispositivos que possuem recursos de hardware reduzidos [RFC ], [Hui e Culler 2008]. Figura "Internet of Things" como resultado de diferentes visões [Atzori et al. 2010] Apesar de existirem diversos trabalhos na literatura que tratam temas relacionados à IoT, ainda é necessário superar uma série de desafios tecnológicos e sociais para que tal paradigma seja amplamente utilizado e difundido. Um tipo de desafio tecnológico está relacionado com os baixos recursos computacionais e de energia dos dispositivos da IoT. Portanto, os trabalhos nessa área, além de apresentarem propostas que sejam escaláveis, dado que será potencialmente enorme o número de dispositivos que farão parte da IoT, precisam também apresentar soluções que utilizem os recursos dos dispositivos de forma eficiente. Um outro tipo de desafio consiste na definição de modelos de desenvolvimento de aplicações que tratem questões tais como a padronização do acesso aos serviços e informações oferecidos pelos dispositivos, segurança e privacidade, modelo de programação, etc. O paradigma Web das Coisas, descrito na seção a seguir, se preocupa em apresentar soluções para esse tipo de desafio Web das Coisas A inclusão de dispositivos físicos e aparelhos eletrônicos (redes de sensores sem fio, telefones celulares, etc.) na internet traz consigo inúmeras possibilidades de novas aplicações, as quais podem utilizar as informações e serviços desses dispositivos com diferentes propósitos. Entretanto, a maioria dos objetos são atualmente conectados a internet (e algumas vezes a Web) utilizando softwares e interfaces proprietárias, o que

125 108 Minicursos Livro Texto torna onerosa a criação de aplicações que integram dados e serviços providos por diferentes dispositivos [Guinard 2010]. Além disso, o uso das linguagens, protocolos e interfaces específicas de cada tipo de dispositivo também faz com que o desenvolvimento de aplicativos para os mesmos seja uma tarefa complexa, pois é necessário que o desenvolvedor possua conhecimento especializado para cada dispositivo utilizado no projeto. Dessa forma, para facilitar o desenvolvimento de serviços no topo desses dispositivos, permitindo também que os serviços e os dados dos mesmos sejam compostos em diferentes aplicações, é necessário utilizar uma linguagem comum a diferentes dispositivos [Guinard e Trifa 2009], [Guinard 2010]. A WoT propõe que os protocolos Web sejam utilizados como linguagem comum para integração de dispositivos físicos no meio digital. A inclusão dos dispositivos físicos na Web permite que os seus dados e serviços sejam reutilizados em diferentes aplicações [Duquennoy et al. 2009]. A integração dos dispositivos a Web ocorre no nível de aplicação, isto é, acima da conectividade de rede [Guinard et al. 2010]. Tal integração permite que ferramentas e técnicas da Web (por exemplo, navegadores, ferramentas de busca e sistemas de cache), linguagens da Web (por exemplo, HTML e JavaScript) e técnicas de interação com o usuário (por exemplo, navegação, vinculação e bookmarking) possam ser aplicadas para objetos do mundo real [Guinard e Trifa 2009], [Guinard et al. 2010]. Desta forma, a WoT possibilita a agregação de valor às informações providas pelos objetos físicos através da utilização de todos os recursos disponíveis na Web (por exemplo, cache, balanceamento de carga, indexação e pesquisa), o que por sua vez alavanca a concretização da visão da IoT [Guinard e Trifa 2009]. Atualmente é possível encontrar trabalhos que apresentam propostas de sistemas que integram objetos com a internet. Um exemplo são os projetos que promovem a integração de redes de sensores com a internet, tais como o SenseWeb [SenseWeb 2011] e o Pachube [Pachube 2011]. Ambos oferecem uma plataforma para que as pessoas compartilhem os dados coletados por sensores através de serviços Web. Porém, essas abordagens não são tão abrangentes quanto à proposta da Web das Coisas, pois elas utilizam servidores que recebem e armazenam dados de sensores de forma centralizada. A WoT por outro lado, preconiza que qualquer objeto físico pode enviar seus dados para pontos descentralizados e esses dados podem ser utilizado e reutilizados em diferentes aplicações [Guinard 2010]. Uma possível abordagem para implementar o conceito de WoT são os padrões WS-* (como o SOAP). Os WS-* geralmente utilizam o protocolo HTTP para realizar tarefas de comunicação na pilha de protocolos utilizada pelos dispositivos. Nesse caso, o HTTP é utilizado para transportar a mensagem SOAP (a qual é codificada em XML), evitando assim possíveis problemas com firewalls, já que geralmente a porta 80 (usada pelo HTTP) é liberada nos firewalls [Guinard e Trifa 2009], [Shelby 2010]. Contudo, a interoperabilidade obtida através do emprego dos padrões WS-* é alcançada através da adição de uma camada de software nas aplicações. Tal adição implica uma maior complexidade de software, não sendo, desta forma, a solução mais adequada para ser aplicada em dispositivos com recursos limitados [Guinard e Trifa 2009]. Diferentemente da abordagem WS-*, a Web das Coisas propõe que a Web atual seja estendida de modo a incorporar objetos e dispositivos embarcados do mundo real como qualquer outro serviço Web. A extensão da Web proposta pela WoT é realizada

126 XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos - SBRC através da adoção do protocolo HTTP como protocolo de aplicação. Isso significa que esse protocolo deve ser utilizado como interface base para realizar toda a interação com os recursos disponíveis [Guinard e Trifa 2009], [Shelby 2010], e não apenas para transportar passivamente as mensagens trocadas. Uma abordagem que está sendo bastante utilizada juntamente com protocolo HTTP na criação de sistemas distribuídos na Web é o estilo arquitetural REST [Mayer 2010] (do inglês, Representation State Transfer). Esse estilo arquitetural pode ser empregado para desenvolver sistemas que seguem uma arquitetura orientada a recursos (ROA, do inglês Resource Oriented Architecture) [Mayer 2010]. O REST define um conjunto de princípios que, ao serem adotados, dão origem a sistemas RESTful. Os sistemas RESTful são menos acoplados, mais leves, eficientes e flexíveis do que os sistemas Web baseados em WS-* e podem ser facilmente reutilizados [Guinard e Trifa 2009], [Sandoval 2009]. Além disso, os princípios REST podem ser mapeados nos métodos básicos do protocolo HTTP (GET, POST, UPDATE e DELETE) para criar sistemas CRUD (Create, Read, Update, Delete) de uma aplicação RESTful. Os recursos dos sistemas RESTful são identificados e encapsulados por um URI. A utilização do protocolo HTTP como protocolo de aplicação admite que os recursos possuam várias representações e permite que os clientes selecionem, dentre as representações disponíveis, aquela que melhor se adéqüe as necessidades da aplicação [Sandoval 2009]. Essas características fizeram do REST a opção mais adequada para construção de APIs Web para acesso a objetos do mundo real [Guinard e Trifa 2009], [Ostermaier et al. 2010]. A Web das Coisas emprega os princípios REST para disponibilizar as funcionalidades dos dispositivos inteligentes na Web utilizando duas abordagens. Na primeira abordagem, são implantados servidores Web embarcados em dispositivos inteligentes e as funcionalidades desses dispositivos são disponibilizadas na forma de recursos RESTful. Na segunda abordagem, quando um objeto inteligente não possui recursos de hardware suficientes para executar um servidor embarcado, é possível utilizar outro dispositivo como ponte para disponibilizar as funcionalidades do dispositivo inteligente na Web através de uma interface RESTful. Embora a utilização de uma arquitetura RESTful permita que objetos físicos se tornem parte da Web, a WoT também propõe a utilização de mecanismos que foquem no desenvolvimento e prototipagem de aplicativos interativos que façam com que os recursos dos objetos físicos sejam utilizados em diferentes aplicações [Guinard e Trifa 2009], [Guinard 2010]. Nesse sentido, os trabalhos da WoT propõem que sejam utilizadas aplicações da Web 2.0 chamadas mashups. Os mashups são aplicativos criados a partir da composição de recursos Web. Como qualquer aplicação da Web 2.0, os mashups são construídos com base em um conjunto de tecnologias (por exemplo, Atom [Atom 2011]) que dão suporte ao desenvolvimento de interfaces altamente interativas e simples ao usuário, semelhante ao que acontece com aplicativos desktop [Bezerra et al. 2009]. Os mashups criados a partir da composição de dados e serviços de dispositivos físicos com outros recursos Web são chamados mashups físicos. Esse tipo de mashup foca no reuso e prototipagem de objetos físicos do mundo real em diferentes aplicações. [Duquennoy et al. 2009], [Guinard 2010]. Logo, é possível resumir que na WoT o protocolo HTTP é adotado como linguagem comum entre diferentes dispositivos e o seu emprego em conformidade com

127 110 Minicursos Livro Texto o princípio arquitetural REST permite que as funcionalidades desses dispositivos sejam expostas como recursos Web que possuem interfaces bem definidas. Isso irá permitir que os dados e recursos dos dispositivos sejam reutilizados em diversas aplicações. A função dos mashups físicos é permitir que os usuários construam aplicações formadas a partir da composição dos recursos e dados desses dispositivos os quais se tornam passíveis de serem combinados e recombinados em tempo de execução para resolverem requisitos de mais alto nível Concretizando a Web das Coisas: REST & ROA Para uma melhor compreensão da Web das Coisas, esta Seção apresenta os conceitos envolvidos com o desenvolvimento de aplicações Web RESTful. Além dos conceitos, também é apresentada uma abordagem prática da aplicação dos mesmos no contexto de aplicações RESTful REST O termo REST, descrito por Roy Fielding (2000) em sua tese de doutorado, define um conjunto de princípios que podem ser aplicados na construção de sistemas com uma arquitetura orientada a recursos (ROA). O REST é um estilo de arquitetura de software que pode ser aplicado no desenvolvimento de sistemas denominados sistemas RESTful [Sandoval 2009]. ROA e REST são utilizados na concepção da implementação de sistemas focados em recursos [Mayer 2010]. Um recurso pode ser qualquer componente de uma aplicação que seja importante o suficiente para ser endereçado na Web através de pelo menos uma URI. Ou seja, um recurso é tudo aquilo que deve ser acessado pelo cliente e transferido entre o mesmo e um servidor [Mayer 2010]. Por exemplo, um recurso pode ser uma lista de cursos de uma instituição, ou mesmo cada curso dessa instituição, os quais possuem disciplinas que por sua vez são subrecursos do curso e assim por diante. Esta Subseção aborda os princípios REST, o modelo de arquitetura orientada a recursos e a construção de sistemas RESTful Princípios REST Os princípios REST podem ser facilmente empregados (e explicados) com o protocolo HTTP [Pautasso 2009]. Por esse motivo, esse protocolo tem sido amplamente utilizado no desenvolvimento de sistemas RESTful [Lucchi et al. 2008]. O HTTP é um protocolo da camada de aplicação para sistemas de hipermídia, colaborativos e distribuídos, baseado no modelo de comunicação requisição/resposta que pode ser utilizado para realizar diferentes tarefas. O HTTP é um protocolo sem manutenção de estado (stateless) e define como é feita a troca de mensagens entre o cliente e o servidor; ou seja, esse protocolo define como um cliente requisita recursos em um servidor e como este responde a tais requisições. O HTTP define um conjunto de métodos que são utilizados nas requisições, dentre os quais se destacam os métodos GET, POST, PUT e DELETE [Lucchi et al. 2008]. Outra característica importante desse protocolo é a negociação da representação de dados, a qual pode ser feita através da utilização dos cabeçalhos (por exemplo, Accept ou Accept-Language) da requisição. A Figura 3.3 mostra o formato de uma requisição HTTP. Nessa figura é possível observar os campos do cabeçalho de uma requisição HTTP contendo o método GET, o caminho (path) do recurso solicitado e a versão do protocolo HTTP. Uma requisição

128 XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos - SBRC contendo o método GET pode possuir dados incluídos no path da requisição. Esses dados são separados do path do recurso pelo caractere de interrogação? e diferentes dados são separados pelo caractere & (cada dado possui uma variável e um valor os quais são separados pelo sinal de igualdade). O campo Host especifica o endereço do servidor na internet e o número da porta do recurso solicitado. O campo User-Agent contém informações sobre o agente de usuário (nessa figura, o agente é o mozilla/5.0) que originou a requisição. O campo Accept indica quais representações o cliente espera receber (nesse caso as representações podem ser HTML, XML OU JSON [JSON 1999]). O campo Connection permite que o emissor da requisição especifique algumas informações concernentes a uma requisição em particular (o valor keep-alive que aparece na requisição apresentada na figura é utilizado para indicar que uma conexão do protocolo de transporte deve permanecer aberta para ser reusada no envio e recepção de múltiplas requisições e respostas). Para maiores detalhes sobre o protocolo HTTP ver [RFC ] e [RFC ]. Figura Requisição HTTP contendo o método GET Como o HTTP possibilita a utilização de diferentes representações, as aplicações podem ser construídas independentemente da forma como os dados serão transferidos [RFC ]. As características do HTTP fornecem o suporte necessário para a realização dos princípios REST. Esses princípios são: identificação única e global para os recursos, uma interface uniforme de acesso aos recursos, endereçabilidade dos recursos (permite que os mesmos sejam vinculados), suporte a múltiplas e independentes representações para o recurso e interação sem manutenção de estado [Sandoval 2009]. O princípio da identificação dos recursos está relacionado ao uso de URIs que fornecem endereços únicos e globais para identificação de um recurso [Pautasso et al. 2008]. URIs também são utilizadas para indicar o escopo da informação provendo meios que permitem a navegação entre recursos que interagem entre si. Isso significa que um identificador pode indicar os subrecursos relacionados com um recurso em um dado momento. Por exemplo, o path do recurso /spot-1265/light presente na requisição da Figura 3.3 indica que light é um subrecurso de spot Uma URI também é utilizada para endereçar a interação entre recursos sem a necessidade do uso do corpo da resposta. No contexto da Web, o uso de URIs possibilita a utilização de links para recursos os quais podem ser estabelecidos utilizando esquemas bem conhecidos [Mayer 2010]. O princípio da interface uniforme define que o servidor deve ser capaz de determinar o que deve ser feito ao receber uma requisição HTTP em uma URI apenas

129 112 Minicursos Livro Texto observando do método presente nessa requisição [Pautasso et al. 2008], [Mayer 2010]. Os métodos das requisições HTTP (GET, POST, PUT ou DELETE) são utilizados para indicar ao provedor do recurso a ação que deve ser realizada. Assim, cada método representa uma ação específica sobre o recurso, podendo ser executadas quatro ações (operações): obter a representação de um recurso (GET), criar um novo recurso (POST), alterar um recurso (PUT) e remover um recurso (DELETE). Essas operações geralmente são descritas como sendo o CRUD (Create, Retrieve, Update e Delete) da aplicação [Sandoval 2009]. Por exemplo, o método GET da requisição exemplificada na Figura 3.3 indica ao servidor (localizado em que o cliente espera receber uma representação do recurso /light o qual é subrecurso de /spot Essa figura é um exemplo de uma requisição que está em conformidade com os princípios de endereçabilidade e interface uniforme. O princípio da vinculação de recursos está relacionado com o uso da abordagem HATEOAS (do inglês, Hypermedia as Engine Of Application State). Nessa abordagem, a vinculação dos recursos é realizada através de links que são criados a partir das URIs dos recursos. Os links podem apontar para qualquer recurso na Web, até mesmo recursos externos ao provedor que está sendo acessado em um dado momento. Isso é possível graças a utilização de um esquema de nomes global que possibilita que qualquer recurso Web seja ligado a outro. Tal característica permite que o servidor ofereça links para que o cliente mude de um estado da aplicação para outro, tornando a aplicação dinâmica. Ou seja, as aplicações são consideradas como uma máquina de estado onde cada página representa um estado e os links representam todas as possíveis transições de estado a partir do estado corrente. Sempre que possível, os links de navegação entre recursos relacionados devem ser disponibilizados na representação do primeiro recurso acessado. Por exemplo, considere um sistema de uma instituição de ensino que possui um recurso chamado lista_cursos, o qual lista todos os cursos dessa instituição quando tal recurso é acessado. O provedor do recurso deve oferecer links criados a partir da URI de identificação de cada recurso que representa um curso da instituição. Esses links são oferecidos com o objetivo de permitir que cada curso possa ser acessado a partir da representação obtida do recurso lista_cursos. O princípio da representação de um recurso define como serão os formatos das mensagens trocadas entre cliente e servidor. A representação de um recurso representa o valor do dado no momento em que foi recebida a requisição [Sandoval 2009]. Um recurso pode possuir várias representações. As opções de representações de recurso permitem que o consumidor do recurso escolha, entre as representações disponíveis, aquela que ele deseja receber. Exemplos de representações de recurso são o XML, JSON, HTML, entre outros. A especificação das representações que o cliente deseja receber podem ser passadas no campo Accept do cabeçalho HTTP. Por exemplo, o campo Accept da requisição apresentada na Figura 3.3 indica três opções de representações que o cliente espera receber, as quais são: text/html (indicando formato HTML), application/xml (formato XML) e application/json (indicando formato JSON). O último princípio REST define que um servidor deve ser stateless, ou seja, sem estado. Esse princípio define que não pode haver manutenção de informações sobre o usuário em sessões no lado do servidor. Assim, cada requisição enviada ao provedor do recurso deve ter todas as informações necessárias para a sua compreensão. Se alguma informação deve ser mantida sobre um recurso, esta deve ser mantida no lado do cliente. Essa abordagem está relacionada principalmente a escalabilidade do sistema,

130 XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos - SBRC pois se um servidor mantivesse as sessões com informações para cada usuário ele poderia ter seu desempenho afetado quando estivesse tratando de muitos acessos concorrentes [Pautasso et al. 2008]. Além disso, esse princípio diminui a dependência do cliente com relação ao provedor do recurso, pois as requisições submetidas são independentes de um servidor específico. Um exemplo dessa situação ocorre quando um cliente que recebeu um link ao acessar o recurso em um servidor, o qual ficou inativo logo após responder ao cliente (por problemas de hardware, por exemplo) e foi automaticamente substituído por outro servidor, pode utilizar esse link, pois ele irá funcionar da mesma forma que antes e a troca do servidor será transparente para o usuário [Webber et al. 2010] ROA Apesar dos princípios REST terem sido apresentados neste minicurso juntamente com o uso das estruturas de URI e dos mecanismos do HTTP, como também fazem muitos outros autores ([Sandoval 2009], [Webber et al. 2010], [Mayer 2010]), o REST é independe de tecnologia e seus princípios não estão obrigatoriamente interligados a Web. O REST também não é um si uma arquitetura, mas possui termos genéricos que podem ser utilizados para definir uma arquitetura. A falta de uma arquitetura que possa ser empregada no desenvolvimento de aplicações que seguem os princípios REST pode levar o desenvolvedor ou arquiteto de software a empregar de forma equivocada esses princípios [Pautasso et al. 2008]. Por exemplo, as aplicações que empregam os princípios REST podem se tornar um híbrido de REST com RPC (Remote Procedure Call) [Richardson e Ruby 2007], [Pautasso et al. 2008], o que não é desejável. Em 2007, Richardson e Ruby apresentaram uma arquitetura orientada a recursos (do inglês, Resource-Oriented Architecture ROA) especificando em detalhes como empregar os princípios REST juntamente com as tecnologias da Web (HTTP e URI) em um modelo de boas práticas que podem ser aplicadas no desenvolvimento de serviços RESTful. Esta Subseção apresenta as principais características dos conceitos e propriedades de ROA conforme propostos por [Richardson e Ruby 2007] URIs Em uma abordagem ROA, as URIs dos recursos devem possuir uma correspondência intuitiva com o recurso que elas identificam e a sua estrutura deve variar de forma previsível. Por exemplo, as URIs ou redesemfio/zigbee permitem que o cliente infira quais são os subrecursos disponíveis em um diretório da URI. Ou seja, ao observarem essas URIs, os clientes esperarão que um dado de temperatura possa ser acessado a partir do diretório rssf/temperatura e que um aluno (por exemplo, John) possa ser acessado a partir do diretório alunos. Outra característica relacionada ao uso de URIs abordada em ROA diz respeito ao relacionamento entre URIs e recursos. Um recurso deve possuir no mínimo uma URI, mas nada impede que ele possua várias. Porém, sempre que possível, um recurso deve possuir apenas uma URI. Isso porque, utilizar várias URIs para identificar o mesmo recurso diminui a importância de uma URI, pois dificulta o relacionamento da URI com o recurso que ela identifica [Richardson e Ruby 2007]. Por exemplo, se um recurso possui várias URIs será mais difícil para um proxy HTTP, por onde passam as requisições de uma rede, identificar se uma resposta contendo uma representação de um

131 114 Minicursos Livro Texto recurso já está armazenada em seu cache. Do ponto de vista de um usuário, é mais difícil associar a URI com um recurso quando este possui vários URIs Endereçabilidade A propriedade ROA que define que um recurso deve ser endereçável pode ser facilmente observada na Web. Essa propriedade está relacionada com o uso de uma URI para identificar e localizar um recurso de um sistema RESTful. A endereçabilidade também é comum para as aplicações REST-RPC (aplicações que são um híbrido entre REST e RPC), pois toda aplicação na Web precisa ser endereçável para poder ser acessada. Richardson e Ruby (2007) apontaram que, para o usuário final, a endereçabilidade é o aspecto mais importante das páginas ou serviços Web. Um recurso endereçável pode ser acessado sempre que sua URI for utilizada na Web. Por exemplo, esses recursos podem ser acessados através de links de hipertexto, ou mesmo quando a URI é enviada de um usuário para outro através do . Ser endereçável também permite que um documento enviado como resposta a uma requisição possa ser mantido em cache nos proxies HTTP. Por exemplo, a página endereçada pela URI pode ser mantida em cache para ser devolvida como reposta a uma segunda requisição HTTP que passe por esse proxy e que seja enviada para a mesma URI Sem Estado Enquanto o REST define que uma aplicação RESTful deve ser sem estado, ROA define como construir uma aplicação sem estado. Ser sem estado significa que uma requisição HTTP deve ser independente de outras requisições anteriores. Para que isso seja possível, as requisições HTTP devem ser auto-contidas, ou seja, uma requisição HTTP deve ter em si toda informação necessária para que possa ser processada. Um servidor que não mantém estado deve ser capaz de processar uma requisição sem precisar utilizar informações de requisições anteriores. Se uma informação é suficientemente importante para ser mantida como uma sessão no servidor, então esta informação deve ser transformada em um recurso. Apesar da expressão sem estado, ROA define dois tipos de estado: o estado da aplicação, o qual deve ser mantido no cliente; e o estado do recurso, que deve ser mantido no servidor. Um exemplo de estado da aplicação pode ser observado nos sistemas de busca da Web (por exemplo, o sistema de busca do Google). Nesses sistemas, o cliente faz uma busca enviando os parâmetros da consulta (geralmente esses parâmetros são passados na URI) para o provedor do recurso. Ao receber o resultado da consulta, o cliente poderá navegar entre páginas que mostram esses resultados. A navegação ocorre quando o cliente passa de uma página contendo um subconjunto do resultado da busca para outra página contendo outro subconjunto do resultado dessa busca. Para tanto, o cliente mantém os parâmetros da consulta (as palavras chave utilizadas) e a identificação da página atual na qual está localizado (página um, dois, três, etc.). Ao navegar entre as páginas que contêm o resultado da busca, o cliente deve incluir nas requisições os parâmetros da consulta e a página que está querendo acessar. Dessa forma, o servidor só precisará tratar o estado da aplicação ao receber uma requisição. O estado do recurso deve ser mantido no servidor e deve ser igual para todos os clientes. Por exemplo, quando um serviço de fotos da Web (como o Flickr) salva uma

132 XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos - SBRC nova foto, essa deve ser considerada um novo recurso. Essa figura ganha sua própria URI e por isso poderá ser acessada nas próximas requisições. Ao ser transformada em um recurso, a figura poderá ser pesquisada, acessada, alterada ou apagada pelos clientes. A figura é parte do estado do recurso e permanece no servidor até que o cliente que possui as permissões necessárias a apague Representação As representações de um recurso podem ser enviadas tanto do cliente para o servidor quanto do servidor para o cliente. As representações são enviadas pelo cliente quando este deseja criar ou atualizar um recurso no servidor (é isso que acontece quando um cliente envia uma foto para ser salva no Flickr). O sentido contrário do envio de uma representação ocorre quando um cliente envia uma requisição para o servidor interessado em obter uma representação de um recurso. Quando o cliente deseja obter uma representação de um recurso do servidor, esse cliente deve ser o mais explícito possível sobre qual representação deseja receber, já que um recurso pode possuir mais de uma representação. ROA define duas formas de especificar uma representação. A primeira forma é utilizar a URI para indicar qual é a representação que o cliente deseja receber. Por exemplo, na requisição json, rss} a URI é utilizada para especificar o tipo de representação (XML, JSON ou RSS). Segundo Richardson e Ruby (2007) utilizar URI é a forma mais explícita com que o cliente anuncia o tipo de representação que ele espera receber. A segunda forma de especificar a representação é utilizar os cabeçalhos Accept ou Accept-Language do protocolo HTTP para indicar ao servidor a representação (XML ou JSON, por exemplo) ou o idioma (inglês, português, etc.) do recurso que o cliente deseja receber Links e Conectividade As representações dos recursos podem ser utilizadas para fornecer links para outros recursos relacionados com o primeiro recurso acessado. Por exemplo, quando uma busca é feita no serviço de busca do Google, a representação enviada para o cliente contém links para cada resultado dessa consulta. O termo conectividade definido pelo ROA é um sinônimo de HATEOAS, visto que o conceito é o mesmo: os recursos podem conter links para outros recursos em suas representações Interface Uniforme Em uma abordagem ROA as operações realizadas sobre os recursos são mapeadas nos quatro métodos básicos do protocolo HTTP. O método GET é utilizado para recuperar a representação de um recurso. A resposta a uma requisição GET inclui em seu corpo uma representação do recurso. O método DELETE é utilizado para apagar um recurso já existente. A resposta para uma requisição DELETE pode conter uma mensagem indicando o status da operação solicitada ou apenas um código HTTP. Em ROA os métodos utilizados para criar recursos são o PUT e o POST. O PUT também é utilizado para atualizar um recurso já existente. Apesar do ROA especificar as situações quando utilizar o método POST ou PUT para criar um novo recurso, muitos sistemas RESTful utilizam apenas o POST com essa finalidade, visto que o método PUT também é utilizado para atualizar um recurso [Sandoval 2009], [Webber et al.

133 116 Minicursos Livro Texto 2010]. As requisições PUT e POST podem conter em seu corpo uma representação do recurso que será criado ou atualizado. Além desses métodos, ROA define como utilizar os métodos HEAD e OPTIONS do HTTP para obter informações sobre um recurso. O HEAD é utilizado para obter metadados sobre um recurso sem que a resposta para uma requisição possua a representação completa desse recurso. O OPTIONS é utilizado para verificar qual método HTTP um recurso suporta. A resposta a uma requisição que contém o método OPTIONS fornece o subconjunto da interface uniforme (HTTP) que este recurso suporta através do cabeçalho Allow (por exemplo, Allow: GET, HEAD indicam que um recurso suporta esses dois métodos). Outra definição apresentada em ROA diz respeito aos efeitos que uma requisição causa sobre um recurso. As requisições podem ser seguras (Safe) ou idempotente. As requisições seguras são aquelas que são utilizadas para obter uma representação de um recurso ou alguma outra informação sobre esse recurso sem causar alteração no estado do servidor. Por exemplo, uma requisição GET pode ser enviada centenas de vezes para obter uma representação de um recurso sem que nenhuma dessas requisições cause alterações no recurso solicitado. As requisições que alteram o estado do recurso são consideradas idempotente quando outras requisições iguais a primeira não são capazes de causar uma alteração diferente a causada pela primeira requisição. O conceito de idempotente é análogo ao da matemática, que utiliza esse termo para indicar, por exemplo, que na multiplicação o zero é idempotente, pois qualquer número multiplicado por zero sempre vai ser igual zero. Analogamente, uma requisição é idempotente se a alteração ocasionada por essa requisição for mantida mesmo que outras requisições semelhantes sejam enviadas em seguida. Por exemplo, ao apagar um recurso ele continuará sem existir ainda que outras requisições DELETE sejam enviadas para esse recurso Desenvolvimento de Serviços RESTful Desenvolver um serviço Web RESTful não é diferente de desenvolver uma aplicação Web tradicional. É necessário se preocupar com os requisitos do negócio, satisfazer as necessidades dos usuários os quais manipularão os dados e lidar com limitações de hardware e arquiteturas de software. A principal diferença, contudo, é que o foco reside na identificação dos recursos e na abstração sobre as ações específicas a serem tomadas por esses recursos. É possível comparar o desenvolvimento de serviços Web RESTful com o desenvolvimento orientado a objetos, pois existem algumas similaridades. No desenvolvimento orientado a objetos é realizada a identificação dos dados que se deseja representar juntamente com as ações que esse objeto pode realizar. Porém, as similaridades acabam na definição da estrutura do dado, porque com os serviços Web RESTful existem chamadas específicas que fazem parte do próprio protocolo de troca de mensagens. Os princípios do desenvolvimento de um serviço web RESTful podem ser resumidos em quatro passos: 1. Levantamento de requisitos Esse passo é similar às tradicionais práticas de coleta de requisitos do desenvolvimento de software.

134 XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos - SBRC Identificação de recursos Esse passo é similar ao desenvolvimento orientado a objetos onde é realizada a identificação dos objetos, mas sem se preocupar com a troca de mensagens entre objetos. 3. Definição de representação de recursos Para viabilizar a troca de mensagens entre clientes e servidores, é necessário definir o tipo de representação que será usada. Geralmente o XML é utilizado, porém atualmente o formato JSON está sendo cada vez mais popular [Sandoval 2009]. Porém, qualquer forma de representação de recursos pode ser utilizada. Por exemplo, é possível utilizar o XHTML ou qualquer outra forma binária de representação, embora seja necessário deixar os requisitos serem os guias das escolhas sobre as representações. 4. Definição de URI O último passo é a definição do ponto de acesso ao recurso, o qual consiste em especificar as URIs para que os clientes possam endereçar os servidores a fim de trocar as representações de recursos. Esse processo de desenvolvimento não é feito de forma estática, pelo contrário, ele deve ser realizado através de passos iterativos os quais giram em torno dos recursos [Sandoval 2009]. Por exemplo, pode acontecer que, durante a etapa de definição das URIs, descobre-se que uma das repostas da URI não é coberta em um recurso identificado. Nesse caso, deve-se voltar para definir um recurso adequado. Na prática, o que acontece é que na maioria dos casos os recursos já definidos cobrem os requisitos da aplicação, então basta combinar os recursos dentro de meta-recursos para tratar os novos requisitos [Sandoval 2009] Requisitos do Serviço Web de Exemplo Para explicar melhor como funciona o desenvolvimento de serviços RESTful, é descrita nesta Subseção a modelagem de um desses serviços. O serviço Web RESTful modelado é uma aplicação Web de um laboratório de faculdade formado por um grupo de pessoas (usuários) onde cada pessoa é responsável por um ou vários trabalhos. Esse simples exemplo permite que seja apresentado o emprego dos princípios REST na prática, sem preocupações com regras complexas de lógica do negócio. A modelagem da aplicação é feita seguindo um processo orientado a objetos [Sandoval 2009] e apenas o necessário para o entendimento do desenvolvimento de sistemas RESTful é apresentado. Desta forma, várias questões existentes na modelagem de software e assuntos afins foram omitidas. Considere-se que, após a etapa inicial de levantamento de requisitos, foram especificados os seguintes casos de uso da aplicação (essas são as principais funcionalidades da aplicação): (i) um usuário pode criar uma conta com um nome de usuário e uma senha; (ii) um usuário pode publicar os trabalhos sob sua responsabilidade (uma publicação nesse caso consiste de uma página Web contendo uma descrição do trabalho); (iii) qualquer pessoa, registrada ou não, pode ver os trabalhos publicados na página do laboratório; (iv) qualquer pessoa, registrada ou não, pode ver o perfil dos usuários; (v) os usuários cadastrados podem atualizar seus dados (por exemplo, alterando sua senha); e (vi) qualquer pessoa pode pesquisar por termos para encontrar publicações cadastradas.

135 118 Minicursos Livro Texto Nas próximas Subseções são endereçados os passos seguintes do desenvolvimento de nosso sistema Web de exemplo Identificação de Recursos A especificação dos recursos dos serviços é uma etapa posterior a listagem dos casos de uso. Com base nos requisitos, é possível perceber que serão necessários usuários e trabalhos. O recurso usuários retorna um usuário ou uma lista de usuários. Além disso, cada usuário pode publicar seus trabalhos. Assim, também serão necessários recursos para um trabalho e para uma lista de trabalhos. Com base nessa observação os seguintes recursos foram identificados: usuário, lista de usuário, trabalho e lista de trabalhos Representação de Recursos Nesta etapa são definidas as representações dos recursos da aplicação. Sabe-se que o protocolo HTTP permite a definição de qualquer tipo de representação (inclusive formatos proprietários de dados). Contudo, é recomendado que sejam utilizadas estruturas padrões, entre as quais estão o XML e o JSON. Logicamente, essa escolha deve ser feita com base nos requisitos da aplicação, os quais irão ditar que tipo de representações devem ser providas [Sandoval 2009]. Sempre que possível, é desejável que sejam fornecidas várias representações para um mesmo recurso. Assim, os consumidores do recurso poderão escolher dentre as opções disponíveis, aquela que é mais adequada para ele. O formato ideal de uma representação é uma questão de concepção. É necessário considerar quais ações serão realizadas pelo servidor e a finalidade com a qual os clientes utilizarão os recursos. Como regra geral, XML deve sempre ser considerada como potencial representação, porque muitas linguagens oferecem bibliotecas para processar streams XML [Sandoval 2009] (isso facilita o processamento das mensagens e favorece a interoperabilidade entre as aplicações). Após a definição do formato, é necessário definir o encadeamento (linkability) das representações. O encadeamento das representações define o um tipo de mecanismo de descoberta de recursos, o qual permite que os recursos possam ser ligados a outros recursos. Por exemplo, a lista de usuarios retornada pelo provedor dos recursos pode conter URIs (disponibilizada por meio de links) para cada elemento usuário da lista. O servidor do exemplo desta Subseção irá utilizar XML e JSON para representar os recursos. A representação XML será utilizada pelo servidor para enviar uma representação do estado de um recurso. O cliente utiliza o XML para criar e atualizar os recursos no lado do servidor. O JSON será utilizado apenas no envio de representações de recurso do servidor para o cliente. A Figura 3.4 ilustra uma representação do recurso usuario no formato XML. Apenas o conteúdo dos elementos nome, nome_usuario e senha são armazenados no servidor, pois eles são parte de um recurso do usuário. O nome indica apenas o nome do usuário. O nome_usuario deve ser único em todo sistema, pois ele será utilizado para identificar o usuário. O elemento link é utilizado para apontar algum recurso no serviço Web e esse link é criado pelo servidor com base em nome_usuario.um link para um recurso pode ser associado a esse recurso assim que o mesmo é criado ou quando uma representação do recurso é solicitada. Por exemplo, o link para o usuário identificado pelo nome_usuario johnsmith pode ser criado assim que o provedor do recurso

136 XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos - SBRC recebe uma requisição para criar esse novo usuario ou quando o provedor recebe uma requisição para um recurso que lista todos os usuários do sistema. <usuario> <nome> john </nome> <nome_usuario> johnsmith </nome_usuario> <senha> abc123 </senha> <link> /johnsmith </link> </usuario> Figura Representação XML do recurso usuario A segunda estrutura criada define uma lista de usuários (Figura 3.5). O documento XML da Figura 3.5 declara uma lista de usuários dentro do elemento usuarios. Nessa estrutura é possível observar o conceito de encadeamento na prática: com a lista de usuários é possível buscar por um usuário específico usando o valor do elemento link. Por exemplo, o primeiro usuario da lista apresentada na Figura 3.5 (identificado por johnsmith) pode ser acessado no path /johnsmith. Dessa forma, quando o cliente obtiver uma representação contendo os usuários do sistema ele poderá acessar cada usuario da lista através do seu respectivo link. <usuarios> <contagem> 50 </contagem> <link></link> <usuario> <nome> john </nome> <nome_usuario> johnsmith </nome_usuario> <senha> abc123 </senha> <link> /johnsmith </link> </usuario>... <usuario> <nome> henrique </nome> <nome_usuario> hribeiro </nome_usuario> <senha> ribeir0123 </senha> <link> /hribeiro </link> </usuario> </usuários > Figura Representação XML do recurso lista de usuários A estrutura da representação do recurso trabalho é utilizada na inclusão de um novo trabalho. Essa estrutura é apresentada nafigura 3.6. Um trabalho possui o identificador (id_trabalho), o corpo da mensagem (definido pelo elemento conteudo), e o usuário que postou a mensagem. Dependendo do que se pretende fazer com essa representação, não será necessário passar todas as informações desse recurso para o servidor. Por exemplo, quando um cliente cria um novo recurso trabalho, ele não sabe qual é o valor do identificador (id_trabalho), pois na abordagem apresentada aqui, tal valor será criado no lado do servidor. Dessa forma, a estrutura com representação do trabalho será passada para o servidor, o qual irá definir o valor de id_trabalho. A Figura 3.7 apresenta a estrutura XML de representação da lista de trabalhos. Essa estrutura contém uma coleção de trabalhos, e cada trabalho contém o usuário que o postou.

137 120 Minicursos Livro Texto <trabalho> <id_trabalho> WebOfThings </id_trabalho> <conteudo> A Web englobando o mundo físico... </conteudo> <link> /webofthings </link> <usuario> <nome> tiago </nome> <nome_usuario> tcruzfranca </nome_usuario> <senha> abc123 </senha> <link> /tcruzfranca </link> </usuario> </trabalho> Figura Representação XML do recurso trabalho <trabalhos> <contador> 50 </contador> <link> /trabalhos </link> <trabalho> <id_trabalho> smarbuild </id_trabalho> <conteudo> edifícios inteligentes... </conteudo> <link> /smartbuild </link> <usuario> <nome> claudio </nome> <nome_usuario> cmiceli </nome_usuario> <senha> m1c3l1 </senha> <link> /cmiceli </link> </usuario> </trabalho>... <trabalho> <id_trabalho> sutil </id_trabalho> <conteudo>... </conteudo> <link> /sutil </link> <usuario> <nome> jaime </nome> <nome_usuario> jaime </nome_usuario> <senha> </senha> <link> /jaime </link> </usuario> </trabalho> </trabalhos> Figura Representação XML do recurso trabalhos As representações JSON possuem os mesmos elementos chaves para os mesmos recursos. Uma definição da representação JSON do recurso usuario pode ser vista na Figura 3.8, enquanto a representação JSON do recurso lista_usuarios pode ser vista na Figura 3.9. A Figura 3.10 apresenta a estrutura JSON de representação de todos os usuários. {"usuario":{"nome_usuario":"juan","senha":"123456", "link":"/usuario/juan"}} Figura Representação JSON do recurso usuário

138 XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos - SBRC {"lista_usuarios":{"contador":"6","usuarios":[{"nome_usuario":"igor","senha":"zw u987","link":"/usuario/igor"},...,{"nome_usuario":"jane","senha":"abc000","link":"/ usuario/paula"}]}} Figura Representação JSON do recurso lista_usuarios {"usuarios":[{"nome_usuario":"hsalmon","senha":"123456","link":"/usuario/ hsalmon"},...,{"nome_usuario":"erico","senha":"987456","link":"/usuario/ erico"}]} Figura Representação JSON de todos os recursos usuario A representação JSON do trabalho é apresentada na Figura 3.11 e a Figura 3.12 apresenta a estrutura JSON de lista_trabalhos. {"trabalho":{"id_trabalho":"id_1","conteudo":"algumconteudo","link":"/trabalhos/i d_1","usuario":{"usuario":{"nome_usuario":"renato","senha":"rttr0ll","link":"/usuar io/renato"}}} Definição de URI Figura Representação JSON do recurso trabalho {"lista_trabalhos":{"contador":"6","link":"/trabalhos","trabalhos":[{"id_trabalho":"id _1","conteudo":"algum-conteudo","link":"/trabalho/id_1", "usuario":{"nome_usuario":"smelo","senha":"t3nbal","link":"/usuario/smelo"}},...,{"id_trabalho":"id_2", "conteudo":"algum_conteudo", "link":"/trabalho/ id_2", "usuario":{" nome_usuario ":"mmelo", "senha":"4pi4rab", "link":"/usuarios/ mmelo"}}]}} Figura Representação JSON de lista_trabalhos A definição das URIs é uma etapa crucial, pois elas definirão a API do sistema. A API definida deve ser lógica, hierárquica, e o mais estável possível. Uma boa API é aquela que é utilizada facilmente e não muda com freqüência. Além disso, a idéia de uma API RESTful é manter uma URI única e confiável para cada recurso. Na definição da URI, a primeira coisa necessária é um endereço Web, no nosso exemplo utilizaremos o endereço Ainda, serão adotadas duas convenções na definição das URIs RESTful. Primeiro, os itens e identificadores que não mudam serão nomeados utilizando palavras-chave como parte da URI (por exemplo, a palavra usuários foi utilizada para definir a URI que aponta para o recurso lista de usuários). A segunda convenção é a utilização de palavras-chaves entre chaves {}. Ao aplicar essa convenção para definir a lista de URIs para os recursos, as URIs obtidas são: /usuarios - uma requisição com o método GET enviada para essa URI irá retornar uma lista de usuários. Se o método POST for utilizado, será criado um novo usuario. Nesse caso, o corpo da mensagem conterá uma representação XML do usuário que deve ser criado. Os outros métodos (PUT e DELETE) não serão suportados, pois as listas de usuários não podem ser alteradas ou apagadas;

139 122 Minicursos Livro Texto /usuarios/{nome_usuario} - uma requisição contendo o método GET enviada para essa URI irá retornar uma representação de um usuário contendo um identificador nome_usuario. Se o método PUT for utilizado, o recurso acessado (usuario) será atualizado. Já o método DELETE é utilizado para excluir um usuário; - uma requisição com o método GET enviada para essa URI retornará uma lista com todos os trabalhos. Se o método POST for utilizado, um novo trabalho será criado; se o método GET for utilizado, o acesso a essa URI retornará uma representação para um trabalho associado ao id_trabalho enviado. O método DELETE irá indicar ao servidor que o cliente espera que o trabalho seja apagado. Os métodos POST e PUT não serão utilizados para esse recurso; e se o método GET for utilizado em uma requisição submetida para essa URI, uma lista de todos os trabalhos do usuário com o nome_usuario será retornada (nenhum outro método é suportado). O uso adequado da URI (conforme os princípios REST e ROA) fornece a informação semântica necessária para interação com os recursos. O uso inadequado da URI pode causar interpretações confusas. Por exemplo, quando uma URI é utilizada para indicar o tipo de representação do recurso, como faz o twitter, por exemplo, dúvidas podem ser geradas no consumidor do recurso. O twitter oferece diferentes representações através da URI json, rss}. Essa abordagem poderá gerar dúvidas no cliente que consome o recurso, pois segundo os princípios REST o protocolo de comunicação deveria ser utilizado para indicar o tipo de representação desejado. Por exemplo, o que aconteceria se uma requisição HTTP indicando que o cliente espera receber uma representação XML através do campo Accept do HTTP fosse submetida para a URI Não seria possível especificar se a representação obtida poderia ser um XML ou um JSON. A pesar disso, ROA incentiva o uso de URI para indicar o tipo de representação de um recurso que o servidor deve retornar, porque essa seria a forma mais simples e explícita do cliente indicar o tipo de representação que espera receber. A definição sobre qual abordagem usar para indicar a representação do recurso é uma decisão do desenvolvedor ou arquiteto de software. Essa decisão deve ser tomada com base na observação de qual será a melhor abordagem para os usuários do sistema. Por exemplo, uma abordagem semelhante a do twitter pode facilitar o desenvolvimento de clientes (aplicações que vão utilizar esse recurso), pois, para recursos que são apenas para leitura, é possível utilizar somente uma requisição HTTP (com o método GET) contendo o tipo de representação embutida na URI. Enviar esse tipo de requisição é mais fácil do que instanciar uma nova requisição HTTP e modificar o cabeçalho Accept a cada nova requisição.

140 XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos - SBRC Descritor WADL A linguagem WADL (Web Application Description Language) é uma especificação formal baseada em XML utilizada para descrever aplicações Web baseadas no protocolo HTTP [Hadley 2006]. Quando os provedores de aplicações Web RESTful desejavam fornecer descrições sobre os recursos, eles utilizavam descrições informais e personalizadas ou ofereciam bibliotecas para permitir que os clientes consumissem seus recursos [Hadley 2009], [Ferreira Filho 2010]. A WADL foi proposta para ser um padrão de descrição de aplicações Web RESTful, cujo propósito é semelhante ao do descritor WSDL utilizado para descrever serviços SOAP [WSDL 2011]. Porém, a WADL foi criada especialmente para descrever interfaces RESTful [Ferreira Filho 2010]. Os principais benefícios na utilização de descritores como o WADL é a possibilidade de automatizar a criação de código através de um formato padronizado e portável que independe de linguagem ou aplicação específica [Webber et al. 2010]. A Tabela 3.1 apresenta os principais elementos de um documento WADL juntamente com uma descrição de cada um deles [Hadley 2009], [Ferreira Filho 2010]. Tabela 3.1 Principais elementos de um descritor WADL Elemento application resources resource method response representation Descrição É o elemento raiz e contém os demais elementos do documento WADL Esse elemento atua como um contêiner para cada recurso fornecido pela aplicação, a URI do provedor dos recursos é indicado neste elemento através do atributo base Cada recurso é descrito por este elemento que inclui o atributo path que identifica o recurso naquele provedor de recursos. Esse elemento descreve a entrada e a saída de um método do protocolo HTTP que deve ser aplicado a um recurso. Esse elemento descreve a saída resultante da realização de um método do HTTP no recurso. Esse elemento descreve uma representação do estado de um recurso. A Figura 3.13 é um exemplo de documento WADL gerado pela ferramenta Jersey [Jersey 2011] que é uma ferramenta para implementação de serviços RESTful utilizando a linguagem Java. No exemplo é apresentada a descrição do recurso identificado pelo path /spot-1265/light e que pode retornar dois tipos de representação: XML e JSON. Apesar das vantagens do uso de um descritor, os defensores dos princípios REST vão de encontro à idéia de utilizar documentos formais que estabeleçam contratos entre os clientes e os provedores de recursos. Segundo eles, a idéia de utilizar descritores vem de uma mentalidade herdada dos serviços Web baseados em SOAP cuja filosofia é contrária ao REST. Segundo Webber et al. (2010), o emprego adequado de hipermídia como mecanismo de manutenção do estado da aplicação fornece toda semântica necessária para que o consumidor realize toda manipulação que deseja sobre os recursos. Desta forma, não seria necessária a utilização de um contrato formal (como a WADL) o que resulta em um menor acoplamento entre cliente e servidor. Resumidamente, as principais desvantagens da utilização de WADL são [Webber et al. 2010]: Existem poucas ferramentas para manipulação dessa linguagem;

141 124 Minicursos Livro Texto As aplicações Web passam a ser vistas como aplicações estáticas devido ao uso de uma linguagem de descrição de interfaces; Há um aumento no acoplamento entre o cliente e o servidor, que acaba fazendo com que alterações no lado do servidor gerem conseqüências no lado do cliente como acontece com os serviços Web que utilizam WSDL; e A linguagem de descrição não fornece informações suficientes para direcionar a interação com os recursos, isto é, o consumidor do documento WADL não sabe qual interação que o servidor espera que ocorra sobre um recurso REST versus WS-* SOAP Figura Exemplo de documento WADL O REST e os Serviços Web WS-* (SOAP, WSDL, etc.) são técnicas de integração de aplicações distribuídas que visam manter o baixo acoplamento entre as partes envolvidas [Guinard e Trifa 2009]. Na Web das Coisas os princípios REST têm sido amplamente aplicados na integração dos dispositivos inteligentes a Web porque esses princípios parecem ser mais adequados para dispositivos com poucos recursos de hardware [Wilde 2007], [Guinard e Trifa 2009]. Esta Subseção apresenta algumas comparações entre REST e WS-* SOAP que podem facilitar a compreensão de tal escolha (maiores detalhes sobre essa comparação podem ser vistos em [Pautasso et al. 2008]). A primeira diferença entre o REST e o WS-* SOAP está na forma como o protocolo HTTP é empregado. Com REST, o HTTP é utilizado para definir a interação entre o cliente da aplicação e o provedor do recurso. Nesse caso, toda a semântica presente nos quatro métodos (GET, POST, PUT, DELETE) do protocolo HTTP é utilizada na definição da interface do sistema [Pautasso et al. 2008]. Os WS-* SOAP, por outro lado, utilizam o protocolo HTTP para transportar as mensagens no formato SOAP com objetivo de integrar aplicações. Nessa abordagem, as mensagens SOAP são adicionadas ao corpo do HTTP para comunicação remota através de firewalls [Pautasso et al. 2008], [Guinard e Trifa 2009]. Nos WS-* SOAP o método POST do HTTP é utilizado na troca de mensagens entre clientes e servidores e a informação sobre qual funcionalidade deve ser executada está presente na mensagem SOAP e não na requisição HTTP [Pautasso et al. 2008]. É por esse motivo que se diz que para os

142 XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos - SBRC serviços Web SOAP o protocolo HTTP desempenha funcionalidade de transporte mesmo ele sendo um protocolo do nível de aplicação. Enquanto as aplicações WS-* SOAP utilizam a Web como meio de troca de mensagens, as aplicações Web RESTful são parte da Web a qual é vista como um terreno comum para as aplicações [Pautasso et al. 2008]. Além do HTTP, as mensagens SOAP também podem ser encapsuladas e transportadas dentro de outros protocolos (por exemplo, os protocolos TCP e SMTP podem ser utilizados para esse propósito) [Pautasso et al. 2008]. Isso é possível porque o SOAP possui um formato próprio de mensagem (baseado em XML), porém ele requer que outro protocolo seja utilizado para transferir essa mensagem. O formato da mensagem SOAP ocasiona um maior consumo de banda do que o ocasionado pelo protocolo HTTP, devido ao tamanho da mensagem SOAP [Tyagi 2006]. Esse é um dos motivos para o REST apresentar vantagens para ser utilizado em dispositivos com pouca capacidade de hardware ou restrição de banda de rede disponível [Tyagi 2006]. Além disso, um formato pré-definido de mensagem força o cliente a tratar aquele tipo de mensagem caso ele deseje utilizar um serviço. Com REST é possível oferecer diferentes tipos de representações. Assim, um cliente pode, por exemplo, escolher se para ele é mais adequado receber uma representação JSON ou um XML. Porém, fornecer vários formatos exige mais esforço no processo de desenvolvimento, pois diferentes tipos de mensagem precisam ser providos. Do ponto de vista do acoplamento, tanto REST quanto o SOAP fomentam o desenvolvimento de sistemas distribuídos com acoplamento fraco entre as partes. Porém, avaliar qual das duas abordagens atinge esse objetivo conseguindo um menor acoplamento é uma tarefa subjetiva, pois para definir o acoplamento vários aspectos devem ser observados (como tempo/disponibilidade, clareza de localização, e evolução do serviço) [Pautasso et al. 2008]. Geralmente o termo fraco acoplamento é relacionado à capacidade de fazer modificações no provedor do serviço sem afetar o cliente. Nesse caso, os serviços Web RESTful são menos acoplados, pois as operações sobre os recursos não mudam, já que tais operações são baseadas nos métodos do HTTP, os quais não mudam mesmo quando ocorre alguma alteração no serviço. Contudo, quando acontecem mudanças nos parâmetros passados nas mensagens, ambos (SOAP e REST) compartilham o mesmo nível de acoplamento [Pautasso et al. 2008]. Outra diferença entre REST e SOAP está na forma como essas abordagens utilizam URIs. Com REST a URI não é utilizada apenas para identificar o recurso, mas também para encapsular toda informação necessária para identificar e localizar os recursos sem a necessidade de um registro centralizado [Pautasso et al. 2009]. Entre outros benefícios, empregar URIs dessa forma permite que os recursos sejam marcados e que links hipermídia sejam fornecidos para o cliente para que o mesmo interaja com os recursos do sistema. O WS-* também utiliza URI, mas não da mesma forma que em uma abordagem REST, o que acarreta na necessidade de utilização de outros mecanismos para agregar informação ao serviço [Pautasso et al. 2009]. Prosseguindo com as comparações entre os serviços Web SOAP e as aplicações RESTful, é possível observar diferenças entre a forma como os clientes consomem os serviços. Com SOAP, os clientes utilizam um documento de descrição formal dos serviços disponíveis. Esse documento é o WSDL (Web Service Description Language) [WSDL 2007]. O uso de descritores fornece aos clientes meios que permitem a geração

143 126 Minicursos Livro Texto automática de código para consumir esses serviços. Porém, sua utilização pode ocasionar falhas no cliente caso ocorram modificações no servidor [Pautasso et al. 2008]. As aplicações RESTful não precisam utilizar um contrato formal (apesar disso ser possível, conforme apresentado na Subseção 3.3.4) entre o cliente e o servidor. Freqüentemente os recursos de uma aplicação RESTful são descritos de forma textual ou por meio da documentação da API da aplicação [Pautasso et al. 2008]. Além dessas abordagens, também surgiram alguns provedores de serviços RESTful que oferecem bibliotecas (em diferentes linguagens de programação) para serem usadas pelos clientes que desejam consumir os recursos que o servidor oferece [Ferreira Filho 2010]. Por ser mais simples, por tornar as aplicações criadas com base em seus princípios parte da Web permitindo que todos os recursos e disponíveis na Web possam ser utilizados para o mundo físico e por causa do menor tamanho das suas mensagens os princípios REST são considerados mais adequados para serem utilizados na integração de dispositivos com baixa capacidade de hardware na Web [Wilde 2007]. Porém, ainda existe uma série de desafios que precisam ser superados. Dentre eles destaca-se o modelo de pull da Web ocasionado pelo HTTP que não prevê um modelo de comunicação assíncrona onde o cliente é notificado da ocorrência de um evento Estendendo ROA para a Web das Coisas Apesar do REST parecer adequado para dispositivos embarcados, estes nem sempre possuem um endereço IP (Internet Protocol) e não são, portanto, diretamente localizáveis/endereçáveis na internet. No entanto, é muito provável que mais e mais dispositivos do mundo real se tornem habilitados para o IP e incorporem servidores HTTP (em especial com 6LoWPAN), tornando-os capazes de compreender as linguagens e protocolos da Web [Mayer 2010]. Desta forma, tais dispositivos poderão ser diretamente integrados a Web e assim as suas funcionalidades serão acessadas através de interfaces RESTful. Embora tais dispositivos habilitados sejam susceptíveis de serem amplamente distribuídos em um futuro próximo, a integração direta de dispositivos do mundo real com a Web ainda é uma tarefa bastante complexa. Principalmente nos casos em que os dispositivos não suportam IP e/ou HTTP, como ocorre normalmente no contexto de redes de sensores sem fio (RSSF), por exemplo. Quando o endereço IP não é suportado, é necessário utilizar um padrão de integração diferente. Nessas situações, nas quais os dispositivos não são capazes de se comunicar via IP, é possível utilizar um dispositivo intermediário chamado Smart Gateway. Smart Gateways possuem duas funções básicas: fornecer uma interface RESTful com URIs que identificam e fornecem acesso aos objetos físicos (dispositivos inteligentes) e seus subrecursos; e realizar a comunicação com os objetos físicos utilizando as APIs destes. Em outras palavras, o Smart Gateway atua como uma ponte entre a Web e os dispositivos inteligentes, ao fornecerem uma interface Web RESTful de acesso aos recursos e subrecursos dos dispositivos e ao se comunicarem com tais dispositivos através de suas APIs. Cada gateway tem um endereço IP, executa um servidor HTTP e compreende os protocolos proprietários dos diferentes dispositivos conectados a ele através do uso de controladores (drivers) dedicados. Como exemplo, considere uma requisição para um nó sensor proveniente da Web através da API RESTful. O gateway mapeia essa requisição em uma solicitação da API proprietária do dispositivo e a transmite usando o

144 XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos - SBRC protocolo de comunicação que tal dispositivo compreende (por exemplo, usando o protocolo Zigbee). Um Smart Gateway pode suportar vários tipos de dispositivos através de uma arquitetura de controladores. A Figura 3.14, mostra um exemplo de Smart Gateway que suporta três tipos de dispositivos, comunicando-se com eles através de seus protocolos de comunicação correspondentes. Os Smart Gateways também podem ser usados para orquestrar a composição de vários serviços de baixo nível em serviços Web de mais alto nível. Esses serviços Web de mais alto nível são mashups criados a partir da composição dos recursos dos dispositivos disponibilizados através da API RESTful oferecida pelo gateway. Por exemplo, se um dispositivo embarcado oferece monitoramento do consumo de energia dos aparelhos, o Smart Gateway poderia fornecer um serviço que retorna a soma de todos os consumos de energia monitorados por todos os dispositivos embarcados conectados ao gateway. Figura Smart Gateway, adaptado de [Guinard e Trifa 2009] Outro dispositivo da WoT muito similar aos Smart Gateways são os Smart Hubs [Mayer 2010]. Os Smart Hubs permitem que sejam criadas infraestruturas que interligam dispositivos inteligentes à Web a fim de prover serviços avançados no topo desses dispositivos. Desta forma, os Smart Hubs oferecem a possibilidade de ter dispositivos interagindo entre si para que sejam fornecidas funcionalidades que vão além do que cada dispositivo poderia prover individualmente. O Smart Hub utiliza serviços de descoberta de dispositivos inteligentes a fim de obter e armazenar informações sobre esses dispositivos. O processo de descoberta e armazenamento de informações sobre novos dispositivos realizado pelo Hub é conhecido como vinculação de recurso (attaching resource). Os Smart Hubs oferecem serviços de consulta e publicação de recursos dentro da infraestrutura da WoT e são implementados para estabelecer conexões entre si de forma que seja mantida uma infraestrutura em árvore. Essa infraestrutura permite que os recursos de diferentes dispositivos não sejam centralizados em um único Hub. Assim como os Smart Gateway, os Smart Hubs utilizam o conceito de controlador para se comunicarem com diferentes dispositivos utilizando as linguagens e protocolos destes [Trifa et al., 2009], [Mayer, 2010].

145 128 Minicursos Livro Texto No contexto da WoT, um controlador é um software utilizado para fazer a ponte entre o mundo físico e a Web com o intuito de expor objetos inteligentes como serviços RESTful. Um controlador é tipicamente formado por: um módulo que controla o dispositivo permitindo que o mesmo seja acessado a partir de um computador; e por um componente que disponibiliza um subconjunto de funcionalidades do dispositivo na Web, estabelecendo a comunicação entre clientes HTTP e esse dispositivo. Porém, a implementação de um controlador WoT pode diferir na forma como o dispositivo é acessado pelo software. Um controlador pode atuar como um proxy reverso encaminhando requisições HTTP para um dispositivo que possui um servidor embarcado ou pode dissociar o processo de comunicação entre o cliente HTTP e o dispositivo (nesse caso, o objeto físico é acionado por meio de sua API para realizar a tarefa especificada na requisição HTTP) Comunicação Orientada a Eventos Os Smart Hubs e Smart Gateway fornecem serviços de comunicação orientada a eventos. Esse serviço é importante porque a comunicação com o protocolo HTTP é síncrona (o modelo de comunicação é requisição e resposta request/reply), o que não permite que o cliente seja notificado da ocorrência de um evento. Um exemplo de evento pode ser observado quando sensores utilizados para monitorar a temperatura de uma área detectam que está ocorrendo um incêndio. Não é possível prever quando ocorrerá um incêndio, por isso é necessário prover meios que permitam que o cliente saiba da ocorrência dos eventos de interesse (no caso, a ocorrência de incêndio). Para monitorar a ocorrência de um evento, os clientes podem consultar os dispositivos constantemente utilizando AJAX, por exemplo. Porém, essa abordagem não é adequada, pois poderia fazer com que a bateria dos dispositivos se esgotasse rapidamente. Para evitar tal situação, é possível utilizar o Smart Gateway e o Smart Hub para fornecer um modelo de comunicação assíncrona baseado no modelo publish/subscribe. Nesse modelo, o cliente publica um interesse para ser notificado com uma resposta assincronamente [Guinard et al. 2010]. Um modelo de comunicação assíncrona que pode ser utilizado é o Atom Publishing Protocol (AtomPub) [Atom 2004], [RFC ]. O Atom é um formato XML que encapsula dados para serem publicados na Web (esse formato de disponibilização de conteúdo é chamado Syndication). O AtomPub é o protocolo utilizado para publicar mensagens Atom. Nessa abordagem, o cliente deve assinar os feeds para monitorar as mensagens dos dispositivos. Assim, os clientes deixam de consultar os dispositivos e passam a consultar um servidor a parte. Os dispositivos, por sua vez, publicam os dados referentes a ocorrência de um evento nesse servidor. Outros meios de comunicação assíncrona também podem ser utilizados, tais como: , twitter e URIs de serviços externos que devem ser acessados pelo gateway ou hub para publicação do evento. Por exemplo, se um usuário deseja que os dados do dispositivo sejam publicados em sua conta no twitter, ele deve fornecer informações sobre a sua identificação e as credenciais do twitter. Então, qualquer cliente que deseje obter as informações do dispositivo precisa apenas se associar a conta do mesmo no twitter. Outra alternativa de comunicação assíncrona na Web é o modelo Comet, o qual pode ser utilizado para que o servidor envie dados para o cliente [Duquennoy et al.

146 XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos - SBRC ]. Porém esse modelo consome mais recurso no lado do servidor, pois é necessário que o servidor armazene informações sobre cada cliente para poder anunciar os dados referentes a um evento [Duquennoy et al. 2009] Web das Coisas: Desenvolvendo Aplicações na Plataforma Sun SPOT Esta Seção descreve como dispositivos físicos e suas funcionalidades podem ser disponibilizados na Web conforme as soluções propostas na WoT. Para tal, são apresentados exemplos práticos utilizando os dispositivos embarcados Sun SPOT (Sun Small Programmable Object Technology), os quais são programados usando a linguagem Java [Sun SPOT 2011]. Nesta Seção também são apresentados dois mashups que compõe os recursos dos SPOTs com outros recursos da Web. A Subseção apresenta a plataforma Sun SPOT. A Subseção apresenta como os objetos físicos podem ser integrados a Web, incluindo exemplos práticos de como disponibilizar as funcionalidades de dispositivos Sun SPOT na forma de recursos RESTful. A Subseção apresenta a construção de mashups físicos que compõem os dados e funcionalidades disponibilizados pelos SPOTs Introdução a Plataforma Sun SPOT O dispositivo Sun SPOT é uma plataforma de sensores desenvolvida pela Sun Microsystems/Oracle [Sun SPOT, 2011]. Esse dispositivo é acionado por código Java e pode ser utilizado em diversos projetos com os mais variados propósitos. Eles podem, por exemplo, ser utilizado em carros robóticos ou no monitoramento de fenômenos físicos devido aos dispositivos de sensoriamento acoplados a eles [Sun SPOT, 2011]. Existem dois tipos de dispositivos Sun SPOT: os free-range SPOTs e a estação base [Sun SPOT, 2011]. A Figura 3.15 ilustra esses dois tipos de dispositivos (uma estação base e dois free-ranges SPOTs). Figura Utilizando uma EB e dois free-range SPOTs Os free-range SPOTs (ou simplesmente SPOTs) possuem uma bateria recarregável, dispositivos de sensoriamento, sendo um de temperatura, outro de luminosidade e um acelerômetro. Além disso, eles também possuem dois botões (os botões podem ser utilizados para acender leds do SPOT ou até mesmo para mudar algum parâmetro na aplicação), oito leds de três cores (vermelho, verde e azul), quatro pinos genéricos de entrada e saída (que podem ser utilizados para acoplar outros

147 130 Minicursos Livro Texto dispositivos eletrônicos), quatro pinos de saída de alta tensão e uma interface USB [Sun SPOT, 2011]. Atualmente os SPOTs possuem as seguintes configurações de hardware: um processador ARM de 32 bits que opera a uma freqüência de 400 MHz; 1 MB de memória RAM; 4 ou 8 MB de memória flash; e um Chipcon 2420 para comunicação a rádio em redes aderentes ao padrão IEEE dispondo de 11 canais de 2,4 GHz [Sun SPOT, 2011]. Os SPOTs podem ser identificados pelo seu endereço MAC IEEE de 64 bits. Além disso, esse dispositivo oferece um protocolo de roteamento o LQRP (do inglês Link Quality Routing Protocol), o qual pode ser utilizado ou estendido pelo usuário. O código Java da aplicação é executado em uma máquina virtual chamada Squawk VM (Virtual Machine), compatível com a plataforma Java ME (Micro Edition) na configuração CLDC1.1 (do inglês, Connected Limited Device Configuration), que permite que o código seja executado sem depender de um sistema operacional. Portanto, é a Squawk que realiza todas as funcionalidades necessárias para execução de uma aplicação, a qual deve possuir uma classe que estende a classe MiDlet [Sun SPOT, 2011]. A estação base (EB) possui apenas uma interface de comunicação sem fio baseada em rádio e uma interface USB. A EB comunica-se com os free-range SPOTs usando o radio e com um dispositivo de maior poder computacional (um computador, por exemplo) via interface USB. Aplicações para a plataforma Sun SPOT podem ser desenvolvidas em um computador pessoal e posteriormente instaladas nos SPOTs. Para tal, é necessário instalar no computador o JDK (Java Development Kit), o SDK (Sun Development Kit) e o Ant [Ant 2010], [Oracle 2010], [Sun SPOT 2011]. O Ant é uma ferramenta que independe de sistema operacional e pode ser utilizada na automatização do processo de compilação, implantação, geração de documentos e execução de uma aplicação. Essa ferramenta é usada principalmente na construção de aplicações Java e pode ser utilizada em conjunto com IDEs (Integrated Development Environment) [Ant 2010]. Desse modo, o desenvolvedor pode utilizar IDEs bem conhecidas tais como NetBeans [NetBeans, 2011] e Eclipse [Eclipse, 2011] para desenvolver aplicações para Sun SPOT. A implantação do código de uma aplicação nos SPOTs pode ser feita transferindo o código através da interface USB ou utilizando uma abordagem OTA ( over the air ). A implantação do código através do cabo USB exige que o SPOT esteja conectado fisicamente ao computador que contém o código compilado. A implantação de código via OTA utiliza o enlace de rede sem fio IEEE para enviar o código a um SPOT específico. Utilizando essa última abordagem, a estação base é utilizada para enviar esse código e o endereço MAC do SPOT de destino deve ser especificado. Uma aplicação para Sun SPOT deve possuir uma classe que estende a classe MiDlet. A classe MiDlet possui três métodos abstratos que devem ser implementados pela classe que a estende: startapp(), pauseapp(), e destroyapp(boolean unconditional). O método que é executado inicialmente pela Squawk é o startapp, sendo executado assim que o SPOT for iniciado. Os outros dois métodos pauseapp e destroyapp podem conter uma implementação vazia. A Figura 3.16 mostra um exemplo básico de uma classe que estende MiDlet. A Squawk executa uma aplicação por vez; isto significa que apenas uma classe estendendo MiDlet pode ser executada. Porém, a Squawk permite que uma aplicação execute várias

148 XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos - SBRC threads de forma paralela. Maiores detalhes sobre a plataforma Sun SPOT podem ser obtidas em [Sun SPOT, 2011], onde também é possível obter informações sobre um emulador que pode ser utilizado para testar a maioria dos projetos desenvolvidos para o Sun SPOT. package br.ufrj.labnet; import javax.microedition.midlet.*; import java.io.ioexception; import com.sun.spot.io.j2me.udp.udpconnection; import com.sun.spot.io.j2me.udp.udpdatagram; import javax.microedition.io.connector; import javax.microedition.io.datagramconnection; import com.sun.spot.resources.transducers.ilightsensor; import com.sun.spot.resources.resources; public class Exemplo extends MIDlet { public static DatagramConnection conn = null; public static int maxlen = 0; public static int port = 100; protected void startapp() throws MIDletStateChangeException { } try { conn = (UDPConnection) Connector.open("udp://:" + port); int response = 0; ILightSensor lightsensor = (ILightSensor) Resources.lookup(ILightSensor.class); UDPDatagram dg = (UDPDatagram) conn.newdatagram(conn.getmaximumlength()); response = lightsensor.getvalue(); dg.write(response); conn.send(dg); } catch (IOException ex) { ex.printstacktrace(); } protected void pauseapp() {} protected void destroyapp(boolean unconditional) throws MIDletStateChangeException {} } //fim da classe Exemplo Figura Classe de exemplo de uma aplicação para a plataforma Sun SPOT Integração de Dispositivos na Web Essa Subseção apresenta os procedimentos de como os dispositivos físicos podem ser disponibilizados na forma de serviços Web RESTful. A disponibilização dos dispositivos pode ocorrer de duas formas: através da inclusão de um servidor embarcado executado diretamente no dispositivo; ou por meio de Smart Gateways, que permitem que até mesmo os dispositivos que não possuem um servidor embarcado (devido a restrições de hardware ou por restrição do projeto) tenham suas funcionalidades disponibilizadas na Web [Trifa et al. 2009]. Os dispositivos que possuem um servidor embarcado podem ter seus recursos acessados por requisições HTTP. Além disso, o servidor também permite que esses

149 132 Minicursos Livro Texto recursos sejam acessados por meio de uma interface RESTful [Guinard e Trifa 2009]. No caso dos dispositivos não suportarem a pilha de protocolo IP, é necessário fazer uso de um proxy para receber as requisições Web da rede TCP/IP e enviar tais requisições para o dispositivo por meio do enlace da rede utilizado pelo mesmo[guinard e Trifa 2009]. Nesse proxy podem ser implementadas outras funcionalidades as quais agregam valor aos serviços do dispositivo. Por exemplo, o proxy pode implementar serviços de descoberta, que permitem que os dispositivos de um mesmo tipo sejam adicionados (quando estiverem na área de atuação do proxy) e removidos do proxy (se o dispositivo se tornar inacessível) [Guinard e Trifa 2009], [Mayer 2010]. A Subseção apresenta um servidor embarcado para plataforma Sun SPOT que permite que as funcionalidades desse dispositivo sejam providas na forma de serviços RESTful. Nessa mesma Subseção é apresentado um proxy que permite que requisições Web sejam encaminhadas para os SPOTs. A Subseção apresenta o protótipo de um Smart Gateway e demonstra a associação de dois SPOTs ao Gateway. Um SPOT possui um servidor embarcado enquanto o outro SPOT não. Dessa forma, é exemplificado um cenário básico da inclusão de dispositivos físicos na Web. A Subseção apresenta como os SPOTs associados ao Smart Gateway são acessados na Web. A Subseção mostra como obter representações dos estados dos recursos através de exemplos dessas representações Técnica de Implementação de Servidores Web em Dispositivos Embarcados A utilização de servidores embarcados em objetos físicos permite que as funcionalidades de tais objetos sejam disponibilizadas como recursos Web. Porém, as metodologias utilizadas na criação de serviços Web não foram projetadas para serem empregadas em dispositivos que possuem hardwares restritos e são alimentados por bateria (por exemplo, sensores sem fio) [Shelby, 2010]. Portanto, para que os servidores Web sejam utilizados em dispositivos embarcados, eles devem atender uma série de requisitos. Em [Shelby, 2010] foram apresentados os requisitos e padronizações para servidores embarcados. Um exemplo de requisito a ser atendido de forma padronizada é a compressão das mensagens do protocolo HTTP. Esta Subseção apresenta as principais características de um servidor embarcado desenvolvido para a plataforma Sun SPOT disponibilizado entre os projetos de demonstração que acompanham a nova versão do SDK lançada em Outubro de 2010 [Gupta 2010], [Gupta e Simmons, 2010], [Sun SPOT, 2011]. Esse servidor faz parte do projeto WebOfThings e está disponível em [Sun SPOT, 2011]. O projeto WebOfThings da plataforma Sun SPOT segue os drafts Chopan (Compressed HTTP Over PANs, 2009) e Reverse HTTP (2009) e a RFC 5785 (2010) da IETF [Gupta 2010], [Gupta e Simmons, 2010]. O draft Chopan descreve como o protocolo HTTP pode ser compactado em mensagens binárias a fim de reduzir o tamanho das mensagens que utilizam esse protocolo. As mensagens HTTP compactadas são transmitidas sobre UDP em redes sem fio de baixa taxa de transmissão e pequena largura de banda como, por exemplo, as redes IEEE /ZigBee. O draft Reverse HTTP descreve um método que permite que as requisições HTTP sejam enviadas para dispositivos que não podem ser acessados diretamente (por exemplo, dispositivos que estejam atrás de um firewall ou de NAT - network address translation). A RFC 5785

150 XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos - SBRC descreve como serviços Web podem obter meta-informações sobre o servidor acessando o path /.well-know/ que simboliza as localizações dos recursos. O projeto WebOfThings provê uma solução para que as funcionalidades dos SPOTs sejam disponibilizadas sob a forma de recursos Web. Conforme apresentado na Subseção 3.5.1, os SPOTs se comunicam entre si e com a EB utilizando padrão IEEE e esses dispositivos não suportam o protocolo IP. Por isso, no projeto WebOfThings a EB (conectada a um computador que é capaz de se comunicar utilizando o protocolo IP) é utilizada para receber as requisições Web retransmitindo-as para os SPOTs [Gupta 2010], [Gupta e Simmons, 2010]. Para isso, a EB deve manter uma referência para cada SPOT. Para tal, a EB utiliza como registro de identificação do SPOT parte do endereço físico (MAC) desse SPOT. O serviço de descoberta é o responsável por realizar o registro dos SPOTs na EB. Esse serviço envia mensagens em broadcast em uma porta pré-definida e aguarda mensagens de algum SPOT que deseja se registrar. A mensagem de registro de um SPOT deve conter sua identificação. Essa identificação é utilizada para disponibilizar o SPOT como um recurso Web e as funcionalidades desse SPOT são subrecursos do mesmo. Por exemplo, o dispositivo de sensoriamento de temperatura do spot-1265 (identificação de um SPOT) é um subrecurso desse SPOT. Após a etapa de registro, os SPOTs podem receber requisições Web. As requisições advindas da Web são enviadas para a estação base, a qual faz uso da URI da requisição para identificar qual recurso está sendo solicitado. Um exemplo de URI é O trecho spot-1265 é utilizado para identificar o SPOT, enquanto o trecho light é utilizado para identificar qual o recurso desse SPOT que o cliente deseja acessar (nesse caso, o recurso é o dispositivo de sensoriamento de luminosidade desse SPOT). Após a EB identificar qual SPOT está sendo solicitado na requisição HTTP, ela comprime a requisição recebida e a retransmite através do enlace de rede sem fio IEEE para o respectivo SPOT e fica aguardando uma resposta do dispositivo solicitado (como exemplificado na Figura 3.17). Figura Tratamento de uma requisição HTTP para um SPOT que contém um servidor embarcado. Quando uma requisição HTTP é recebida pelo SPOT, o servidor HTTP é utilizado para descompactar essa requisição e criar um objeto contendo todas as informações incluídas nessa mensagem (por exemplo, o objeto criado, dentre outras

151 134 Minicursos Livro Texto informações, pode ter o path de um recurso e o método presente na requisição). Esse objeto que representa a requisição HTTP é utilizado para identificar o recurso solicitado por meio do path, além de indicar qual operação deve ser realizada sobre esse recurso. As operações que podem ser executadas sobre um recurso são: criar, recuperar, atualizar e apagar. Essas operações são executadas com base no respectivo método da requisição HTTP (GET, POST, PUT ou DELETE) em conformidade com a propriedade ROA e o princípio REST de interface uniforme. É necessário ressaltar que os recursos não precisam tratar todos os métodos HTTP utilizados em serviços RESTful. Por exemplo, os dispositivos de sensoriamento apenas enviam o valor sensoriado; logo esses recursos são acessados por requisições que contém o método GET do HTTP e os demais métodos não são suportados, pois não possuem utilidade para esse recurso. Os leds por outro lado, podem retornar uma representação contendo as cores com que eles estão acesos (por exemplo, utilizando valores RGB red, green, blue) quando recebem uma requisição com o método GET. Ou podem alterar sua cor com base em parâmetros de uma requisição que contém o método PUT. Após o tratamento da requisição HTTP, o servidor do SPOT envia uma mensagem de resposta HTTP com um código de sucesso ou um código de erro (por exemplo, um 200 OK que indica que o conteúdo da requisição foi processado com sucesso ou um 404 que indica que o recurso não foi encontrado). As mensagens HTTP de sucesso podem conter uma representação do recurso solicitado (por exemplo, as requisições HTTP que contém o método GET). Nesse caso, o próprio recurso retorna uma representação (em HTML, JSON ou XML, por exemplo) que é incluída na mensagem de resposta HTTP. Em seguida, a mensagem HTTP de resposta deve ser compactada e enviada para a EB onde será descompactada e enviada ao cliente que fez a requisição. A Figura 3.18 e a Figura 3.19 apresentam as principais classes do projeto WebOfThings que fazem com que os SPOTs disponibilizem suas funcionalidades na Web na forma de serviços RESTful. A Figura 3.18 apresenta as principais classes do projeto WebOfThings que são executadas na EB. Essas classes implementam as funcionalidades que permitem que os SPOTs registrados sejam acessados como qualquer serviço Web RESTful. Nessa classe é criada uma instância de NanoAppServer. Em NanoAppServer estão implementadas as funcionalidades que permitem que as requisições sejam encaminhadas para o SPOT adequado, como se esse dispositivo fosse um recurso Web. A classe Main também instancia TCPHandle passando a referência do objeto NanoAppServer criado anteriormente. TCPHandle tem como objetivo receber as requisições HTTP advindas da Web em uma porta pré-definida. Para cada requisição advinda da Web, TCPHandle devolve uma resposta via Web ao emissor de tal requisição. Por exemplo, ao receber uma requisição HTTP advinda da Web, TCPHandle cria um objeto do tipo HttpRequest que contém todas as informações da requisição HTTP recebida da Web. Para tal, TCPHandle utiliza o método estático parse da classe HttpRequest passando como parâmetro a requisição HTTP recebida da Web. A instância de HttpRequest que equivale a requisição HTTP advinda da Web possui todos os campos da mensagem HTTP compactados (por exemplo, os campos do cabeçalho da requisição são representados por bytes específicos). Em seguida, TCPHandle acessa NanoAppServer para obter a resposta para essa requisição HTTP.

152 XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos - SBRC Em NanoAppServer é acessado o método processrequest da classe MainApp passando como parâmetro a instância de HttpRequest criada anteriormente. Em MainApp é utilizado o path do recurso que identifica o SPOT que deve ser acessado (por exemplo, spot-1265 ). Esse path é passado para a instância de DeviceManager que identifica se o SPOT solicitado está entre os SPOTs cadastrados na EB. Se um SPOT for identificado, a instância de HttpRequest é encaminhada para esse SPOT por meio do método sendandgetresponse de UDP6Forwarder. O método sendandgetresponse de UDP6Forwarder encaminha a requisição e aguarda a resposta do SPOT. Finalmente, a resposta enviada pelo SPOT é entregue por TCPHandler ao cliente que fez a requisição (qualquer erro em algumas das etapas anteriores fará com que uma resposta contendo um código de erro seja enviada para o cliente Web). Figura Principais classes do projeto WebOfThings executadas na Estação Base A Figura 3.19 apresenta as principais classes que são executadas no Sun SPOT para que as funcionalidades dessa plataforma sejam disponibilizadas como recursos RESTful. A classe WoTServer estende MIDlet, logo essa classe MIDlet é utilizada pela Squawk para iniciar a aplicação. Em WoTServer é instanciada a classe NanoAppServer que implementa as funcionalidades do servidor HTTP. Nos SPOTs, NanoAppServer armazena as instâncias das classes que implementam as funcionalidades dos recursos, bem como uma identificação para cada uma dessas instâncias. Essa identificação é utilizada para relacionar um recurso com o path de uma requisição. Por exemplo, uma instância da classe LightSensor que permite que o dispositivo de sensoriamento de luminosidade seja disponibilizado como recurso Web é identificada pela String /light e uma requisição para esse recurso deve conter o path /light, pois é esse path que será utilizado para identificar o recurso. Cada classe que implementa as funcionalidades de um recurso deve estender WebApplication (por exemplo, a classe LightSensor estende a classe WebApplication). A classe WebApplication é uma classe abstrata que define a interface necessária para as classes que implementam as funcionalidades de um recurso.

153 136 Minicursos Livro Texto Figura Principais Classes do projeto WebOfThings Executadas nos SPOTs Em WoTServer também é instanciada a classe UDP6Handler que realiza a tarefa de comunicação utilizando os níveis de rede da plataforma Sun SPOT. As mensagens no nível de rede são recebidas em UDP6Handler e o conteúdo de cada mensagem é um array de bytes que equivale a requisição HTTP compactada. Esse array de bytes é passado para o método estático parse da classe HttpRequest que retorna uma referência para um objeto do tipo HttpRequest que representa a requisição descompactada. UDP6Handler faz uso do objeto que equivale a requisição para obter um objeto HttpResponse que equivale a resposta adequada para a requisição recebida. Em seguida, UDP6Handler solicita que a resposta HTTP seja compactada para finalmente enviá-la à EB. As classes HttpRequest e HttpResponse estendem a classe abstrata HttpMessage e contêm todas as funcionalidades necessárias para manipulação das requisições e respostas, respectivamente. A classe HttpMessage contém os métodos que realizam a compressão e descompressão das mensagens HTTP (cabeçalhos, tipos MIME, entre outros). A classe HttpRequest fornece todos os métodos para acesso aos cabeçalhos e parâmetros da requisição HTTP (por exemplo, obtenção do método da requisição HTTP). Os objetos do tipo HttpResponse são criados com base no recurso indicado no path da requisição (por exemplo, uma requisição utilizada para obter uma representação do valor da temperatura faz com que uma resposta seja gerada na instância da classe que implementa as funcionalidades desse recurso). Quando um recurso não existe ou o método indicado na requisição não é suportado pelo recurso, é criada uma instância de HttpResponse com um código de erro. A Figura 3.20 apresenta o diagrama de seqüência das mensagens trocadas durante a execução do servidor embarcado nos SPOTs: da etapa de inicialização ao tratamento das requisições dos clientes que desejam obter uma representação de algum recurso disponibilizado. A classe WoTServer instancia a classe NanoAppServer e todas

154 XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos - SBRC as classes dos recursos. Em seguida, as instâncias das classes que implementam os recursos são passadas para NanoAppServer juntamente com o path que os identifica através do método registerapp dessa classe. A próxima classe a ser instanciada é UDP6Handler que recebe um parâmetro do tipo int e uma referência para a instância de NanoAppServer. O parâmetro int indica a porta onde deve ser aberta a conexão no nível de rede da plataforma Sun SPOT. Essa porta deve ser a mesma utilizada pela EB para encaminhar as requisições Web para o SPOT. Figura Diagrama de seqüência das mensagens trocadas durante a execução do servidor embarcado nos SPOTs O objeto do tipo UDP6Handler deve permanecer em um laço contínuo ouvindo mensagens na porta indicada. As requisições e respostas HTTP trafegam no enlace de rede sem fio dentro de datagramas. A comunicação utilizando datagramas é realizada através dos métodos da classe UDPConnection que estende a interface DatagramConnection disponível no SDK. Após receber o datagrama, UDP6Handler passa o conteúdo do datagrama como parâmetro do método estático parse da classe HttpRequest a fim de receber uma referência para um objeto do tipo HttpRequest que representa a requisição HTTP recebida (mensagem 5 do diagrama de seqüência). A referência para o objeto que representa a requisição é utilizada por UDP6Handler para obter um objeto HttpResponse que equivale a resposta para essa requisição. Essa referência do objeto que representa a requisição é passada para NanoAppServer através do método getresponse (mensagem 6 do diagrama de seqüência). Então, NanoAppServer utiliza a instância do objeto que representa a requisição como parâmetro do método findmatchingappandadjustpath para buscar entre a coleção dos recursos aquele que está sendo solicitado. Nesse momento, é extraído o path da requisição o qual identifica o recurso desejado. Quando o recurso solicitado é identificado, a instância da classe que implementa as funcionalidades do

155 138 Minicursos Livro Texto recurso processa a requisição gerando uma resposta adequada (se ocorrer algum erro, uma resposta é criada contendo um código de erro). Finalmente, a resposta é compactada (mensagem 7 do diagrama de seqüência) através do método tobytearray da classe HttpResponse que repassa a tarefa de compressão para a classe HttpMessage. Um array de bytes é obtido desse processo o qual é inserido no datagrama, através do método write. Então o datagrama que contém a resposta HTTP é enviado através do método send em UDP6Handler Implementação de Gateways Esta Subseção contém uma descrição do protótipo de um Smart Gateway desenvolvido a partir da extensão do proxy reverso apresentado na Subseção A descrição desse protótipo tem como objetivo fornecer uma visão mais aprofundada sobre um Smart Gateway. No protótipo, dois tipos de dispositivos foram conectados ao gateway através do uso de controladores. Ambos os dispositivos são Sun SPOTs, porém um dispositivo possui um servidor embarcado e o outro não. No segundo caso, o gateway se comunica com o SPOT utilizando a API deste através de um controlador desenvolvido para tal finalidade. Desta forma, pretende-se exemplificar como um dispositivo que não possui servidor embarcado pode ter seus recursos disponibilizados na Web através de um Smart Gateway. A Figura 3.21 mostra os principais componentes do gateway. Os controladores de cada dispositivo possuem um módulo de descoberta personalizado para o tipo de dispositivo que controla. Os controladores enviam mensagens em broadcast periodicamente em uma porta pré-definida. Os dispositivos que querem se associar ao gateway devem responder a essas mensagens enviando uma resposta para o controlador. Quando um novo dispositivo é adicionado ao Smart Gateway, o path de acesso a esse novo recurso é negociado entre um módulo do gateway que faz a gerência de paths e o controlador do dispositivo a fim de evitar paths repetidos. Normalmente o path segue a seguinte estrutura: /{tipodispositivo}/dispositivo-id/recurso (por exemplo, /spotapi/spot-0f40/temperature). Outro módulo apresentado na Figura 3.21 é o DespacharRequisicao. Esse módulo utiliza as URIs das requisições para obter a informação necessária para selecionar o controlador do tipo de recurso (dispositivo) que está sendo solicitado (o tipo de dispositivo pode ser um SPOT com servidor embarcado, por exemplo). Nessa etapa, uma referência de um objeto Java contendo as informações da requisição é passada para o controlador. O controlador, por sua vez, utiliza as informações da requisição para adquirir o recurso diretamente no dispositivo solicitado. O recurso obtido do dispositivo é devolvido ao componente DespacharRequisicao, o qual retorna uma resposta contendo o dado solicitado ao cliente que submeteu a requisição. Se algum erro ocorrer durante esse processo, uma resposta contendo um código de erro é devolvida ao cliente.

156 XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos - SBRC Figura Componentes básicos do Smart Gateway e de dois tipos de dispositivo (um SPOT com servidor embarcado e o outro sem sendo a comunicação realizada através da API deste) As principais classes do Smart Gateway utilizadas para registrar e identificar controladores, além de encaminhar requisições da Web para esses controladores são apresentadas na Figura Nessa figura, a classe MainApp é chamada a cada nova requisição. As requisições são encaminhadas para o controlador adequado com base no path dessas requisições. A Figura 3.23 apresenta as principais classes de um controlador. Tais classes serão explicadas no contexto de um exemplo. O controlador utilizado para SPOTs que possuem um servidor embarcado foi desenvolvido de forma análoga, mas é apresentado na Subseção Os controladores estendem a classe WebApplication e devem ser registrados na classe MainApp quando uma instância do controlador juntamente com o path que será utilizado para identificá-lo são passados para NanoAppServer. Os controladores são Singletons, isto é, só existe uma instância de cada controlador por Smart Gateway. A classe DeviceDiscovery é implementada como uma Thread que executa em intervalos pré-definidos a tarefa de enviar anúncios sobre o gateway a fim de cadastrar novos dispositivos dinamicamente. Essa classe também é utilizada para controlar a saída de dispositivos que não possam mais ser alcançados (devido ao esgotamento da bateria do dispositivo, ou por qualquer outro motivo). Por exemplo, se um dispositivo conectado não responder a três anúncios consecutivos ele pode ser considerado

157 140 Minicursos Livro Texto inalcançável, enquanto nos dois primeiros anúncios o controlador pode considerar que tal dispositivo está em modo sleep para economizar energia. Figura Principais classes do Smart Gateway Figura Principais classe de um controlador A classe DeviceManager mantém uma lista de todos os dispositivos e realiza o acesso aos recursos dos mesmos através da classe DeviceAccess. Uma requisição identifica através do path um recurso (representado pelo controlador), um dispositivo específico (considerado subrecurso do controlador) e alguma funcionalidade do dispositivo (considerada seu subrecurso). Por exemplo, o path /spotapi/spot- 0f40/temperatura, a primeira parte do path /spotapi identifica o controlador desse

158 XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos - SBRC tipo de dispositivo. A segunda parte /dispositivo-0f40 identifica o SPOT onde 0f40 são os quatro últimos dígitos do endereço MAC desse SPOT. Por último, o trecho /temperatura é utilizado para identificar o dispositivo de sensoriamento de temperatura desse SPOT. A classe Device contém toda informação necessária para que seja realizado um acesso específico a um dispositivo. Uma nova instância dessa classe é criada e adicionada a lista de DeviceManager sempre que um novo dispositivo é encontrado. A classe DeviceAccess é utilizada para acessar os dispositivos por meio da API dos mesmos. Essa classe acessa o dispositivo utilizando os dados de uma instância de Device. Um controlador pode evitar o acesso contínuo aos tipos de dispositivo que representa utilizando cache dos dados com o objetivo de diminuir o consumo de energia desses dispositivos. Um controlador utilizado para acessar SPOTs por meio da API destes pode enviar mensagens de anúncio do gateway na porta 201. Neste trabalho, os SPOTs que se comunicam com o Smart Gateway utilizando apenas a API enviam uma mensagem JSON contendo as seguintes informações: MAC, nome, timestamp e uma lista contendo as funcionalidades (recursos) dos SPOT. A Figura 3.24 ilustra a estrutura JSON utilizada para prover as informações necessárias para que os SPOTs sem servidor embarcado possam se cadastrar no gateway. A Figura 3.25 apresenta a estrutura da mensagem utilizada por esses SPOTs para se associarem a um gateway. A Figura 3.26 mostra as classes dos SPOTs que são acessadas por meio de sua API. {"gateway_id": MAC_gateway, timestamp : timestamp } Figura Estrutura JSON utilizada no serviço de descoberta do controlador que se comunicam com os SPOTs por meio da API destes {"spot-api :{ MAC : F F20, nome : spot-api, timestamp : , recursos :{ temperatura : /temperature, luminosidade : l ight }} Figura Estrutura JSON de anúncio de capacidade enviada pelos SPOTs que não possuem servidor embarcado para o gateway Figura Diagrama de classes dos SPOTs que não possuem servidor embarcado A classe SpotAPI é a classe executada pela Squawk, pois estende MiDlet. A classe SPOT_Advertise é responsável pelas tarefas de associação a um Smart Gateway. A classe Resource é responsável por acessar o recurso adequado quando recebe uma mensagem do gateway. A classe SPOTCommunication é utilizada para ouvir e responder mensagens direcionadas aos recursos. Na implementação realizada neste protótipo o SPOT fica ouvindo na porta 200 mensagens cujo conteúdo é um documento

159 142 Minicursos Livro Texto JSON. O JSON indica qual tipo de dado (temperatura ou de luminosidade) que o SPOT deve retornar Exposição de Dispositivos como Recursos REST Como visto extensivamente ao longo deste Capítulo, na Web das Coisas as funcionalidades dos dispositivos são acessadas por meio de URIs. Dessa forma, os recursos de um SPOT associado a um gateway devem ser acessados através de uma URI. Tal URI é utilizada para localizar o gateway, identificar um dispositivo e especificar um recurso do mesmo. A URI permite que os recursos sejam identificados de forma única na Web e fazem com que os SPOTs sejam vistos como recursos do gateway enquanto as suas funcionalidades são vistas como seus subrecursos [Mayer 2010]. A URI de acesso ao recurso de um SPOT tem o formato do gateway}/{identificação do controlador}/{identificação do SPOT}/{recurso do SPOT}. O endereço do Smart Gateway o identifica na Web; a identificação do controlador indica o tipo de dispositivo associado ao gateway que o cliente deseja acessar; e a identificação do SPOT indica qual dispositivo associado ao gateway que deve ser acessado (os SPOTs são identificados pelos quatro últimos dígitos do seu endereço MAC). O recurso especificado na URI indica qual funcionalidade do SPOT o cliente deseja acessar. Por exemplo, o acesso ao sensor de temperatura do SPOT cujos quatro últimos dígitos do MAC são 1265 pode ser feito através da URI onde /light identifica o subrecurso do SPOT. Os SPOTs que não possuem servidor embarcado também são identificados por uma URI com o formato semelhante. Por exemplo, de forma similar ao exemplo do SPOT que possui servidor embarcado, o SPOT sem servidor embarcado que possui os quatro últimos dígitos do MAC 0F20 pode ser acessado em onde other-0f20 identifica um SPOT e /temperatura identifica a funcionalidade desse dispositivo que se deseja acessar. Esse uso de URI também permite que o sistema forneça links para que os clientes naveguem entre os subrecursos de um recurso. Por exemplo, uma requisição enviada para retorna uma listagem com links para todos os recursos disponíveis nesse SPOT. Esses links permitem que o cliente mude da representação do estado de um recurso para outras representações de diferentes recursos. Além disso, também é possível utilizar links que conduzem o cliente nas interações que podem ser realizadas com o recurso Representação de Estado Os dispositivos conectados a Web fornecem dois tipos de representação de recursos: HTML e JSON. A representação HTML foi adotada para simplificar a interação dos clientes (humanos) como os recursos disponibilizados, permitindo a navegação dentro da estrutura por meio de links para os recursos filhos (subrecursos). Esse tipo de representação HTML é retornado pelo gateway e pelo SPOT que possui um servidor embarcado. O gateway retorna um HTML contendo uma lista com os dispositivos conectados a ele separados por tipo. Cada dispositivo da lista possui um link associado a ele que permite que o usuário acesse tal dispositivo (a Figura 3.27 mostra um exemplo da página principal do gateway). Os SPOTs que possuem um

160 XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos - SBRC servidor embarcado enviam uma representação HTML contendo seus subrecursos com links para cada um deles (ver Figura 3.28). As representações JSON são disponibilizadas quando um SPOT que não possui servidor embarcado é acessado ou quando uma requisição especificando que a representação deve ser JSON é submetida a um SPOT com servidor embarcado. No caso dos SPOTs sem servidor embarcado, a representação JSON é utilizada pelo SPOT para retornar seus dados ou a listagem dos seus recursos (a Figura 3.29 mostra um exemplo de dado de temperatura retornado por um desses SPOTs). Figura Representação HTML da página inicial do Smart Gateway Figura Listagem dos recursos disponíveis em um SPOT com servidor embarcado {"resource":{"typeofresource":"temperature","scale":"celsius","value","32", "timestamp":" ","deviceid":"temperatura","link":"/temperatura "}} Figura Representação JSON do recurso temperatura Técnicas de implementação de Mashups Físicos Essa Subseção apresenta dois exemplos de composição, em mashups físicos, dos recursos dos dois SPOTs (com e sem servidor embarcado) conectados ao Smart Gateway. Os mashups físicos têm como objetivo compor as informações e funcionalidades dos dispositivos inteligentes em serviços mais sofisticados agregandolhes valor. Os mashups aqui apresentados foram desenvolvidos com a ferramenta Presto

161 144 Minicursos Livro Texto [Presto 2010] a qual utiliza a EMML [EMML 2010] que é uma linguagem padrão de desenvolvimento de mashups. O primeiro mashup apresenta os dados dos dois SPOTs em um gráfico (ver Figura 3.30). Esse gráfico apresenta a variação da temperatura das últimas doze amostras obtidas antes do momento da requisição. Para a construção do mashups, foi implementado um serviço Web que acessa os dispositivos de sensoriamento de temperatura dos SPOTs a cada hora e armazena a representação do recurso acessado em um repositório (para esses exemplos foi utilizado um banco de dados relacional) que atua como histórico de dados. É importante lembrar que as representações de recursos dos dois SPOTs foram obtidas como as de qualquer outro recurso na Web. O SPOT responsável pela geração dos dados representados pela linha laranja do gráfico foi colocado dentro de um ambiente fechado que possui ar condicionado. O SPOT responsável pela geração dos dados representados pela linha azul do gráfico foi colocado em uma ambiente aberto (e obviamente sem ar condicionado) para coletar a temperatura do ambiente. A integração na Web permitiu que os dados dos SPOTs fossem utilizados em gráficos que podem ser visualizados na maioria dos navegadores Web. O mashup criado possibilita, por exemplo, que o responsável pela central do ar condicionado tenha uma visualização de alto nível sobre os dados de temperaturas obtidos pelos sensores, permitindo que esse usuário possa avaliar de forma simples e rápida se o sistema de refrigeração está mantendo a temperatura interna do laboratório independentemente da variação de temperatura do ambiente externo. Figura Gráfico de Temperaturas coletadas pelos SPOTs colocados em diferentes ambientes em um intervalo de 12 horas A Figura 3.31 apresenta a integração de um SPOT com um mapa Web [Google Maps Api 2010]. O mapa possui uma marcação com um ícone em uma localidade prédefinida. Quando esse ícone é acionado através de um clique do mouse, é aberta uma caixa com uma mensagem contendo a temperatura do local em que se encontra o SPOT no momento do clique. Quando o usuário clica no ícone apresentado no mapa, é obtida uma representação JSON de um dado coletado pelo dispositivo de sensoriamento do