Universidade de São Paulo Instituto de Matemática e Estatística Departamento de Ciências da Computação Uma Leitura do Artigo: MOSAIC: Stateless Mobility for HTTP-based Applications Ricardo Juliano Mesquita Silva Oda Computação Móvel Ministrante: Prof. Dr. Alfredo Goldman São Paulo, junho de 2013
Uma Leitura do Artigo: MOSAIC: Stateless Mobility for HTTP-based Applications Esta é uma monograa elaborada pelo aluno Ricardo Juliano Mesquita Silva Oda, desenvolvida no curso de Computação Móvel ministrado pelo Prof. Dr. Alfredo Goldman no Instituto de Matemática e Estatística da Universidade de São Paulo. São Paulo, junho de 2013
Resumo W. Song, G. Hampel, A. Rana, T. Klein, H. Schulzrinne, MOSAIC: Stateless mobility for HTTP-based applications, Wimob, page 69-76. IEEE Computer Society, 2012. Esta monograa é uma leitura, análise e tradução do artigo sobre o MOSAIC (Song et al., 2012), uma solução de mobilidade para aplicações que não guardam estado, onde o dispositivo hospedeiro pode mudar de IP, bem como mudar de servidor de conteúdo e continuar com uma sessão ativa. Palavras-chave: Horizontal Hand-over, palavra-chave2, palavra-chave3. i
Sumário 1 Considerações Preliminares 1 2 A Rede Móvel 1 3 O Problema de se Movimentar 1 4 Proposta 2 5 A Solução MOSAIC 2 5.1 Mobilidade Sem Estado.................................. 2 5.2 Arquitetura......................................... 3 5.3 Funcionamento....................................... 3 5.4 Implementação....................................... 5 6 Experimentos 6 6.1 Compatibilidade...................................... 6 6.2 Entrega da Conexão.................................... 7 6.3 Troca de Servidor de Conteúdo.............................. 8 6.4 Desempenho......................................... 9 7 Discussão 10 7.1 Conclusão.......................................... 10 Referências 12 ii
1 Considerações Preliminares Este texto foi desenvolvido durante o curso de Computação Móvel do Instituto de Matemática e Estatística (IME) da Universidade de São Paulo (USP), tendo o intuito de estudar um tópico relacionado ao assunto, computação móvel. Assim, o artigo MOSAIC (Song et al., 2012) foi escolhido como objeto de análise. Todo crédito da solução de mobilidade proposta pertence aos autores do artigo. Essa monograa não propõem soluções, apesar de apresentar algumas ideias, é um documento mais focado em explicar, analisar e criticar o conteúdo apresentado no texto original. 2 A Rede Móvel Atualmente a Internet está em crescimento e evolução contínua como vemos no estudo de Labovitz et al. (Labovitz et al., 2010). Tem um papel cotidiano na vida de grande parte do mundo, sendo presente no dia a dia das pessoas como ferramenta de comunicação e transmissão de dados. Nesse mesmo mundo, o advento dos dispositivos móveis inteligentes possibilita uma alta conectividade móvel. De acordo com um relatório da Cisco, o tráfego de dados globais feitos por dispositivos móveis cresceu em 70% em 2012, de 520 petabytes por mês no nal de 2011 para 885 petabytes ao nal do ano de 2012 (The Cisco R Visual Networking Index (VNI), 2013). É nesse contexto, onde a Internet e os dispositivos móveis estão no palco como atores principais, que surgem problemas com a conexão móvel. O artigo MOSAIC propõem a solução para um deles que será descrito na próxima seção 3. 3 O Problema de se Movimentar Um dispositivo móvel, como o nome diz, foi feito para movimentar-se e ao fazê-lo enfrenta desaos em relação à sua conexão. O fato do dispositivo deslocar-se sicamente introduz o conceito de entrega de conexão (hando ou handover), onde a conexão ativa com um ponto de acesso é substituída por outra em outro ponto. Isso ocorre devido ao limite de alcance de sinal de cada estação distribuidora de sinal. Diálogos ou sessões (session) entre o dispositivo e um servidor, ou até mesmo outro dispositivo, são perdidos nessa transição de conexão. Ao acessar a rede por outra entrada, o dispositivo utiliza um endereço diferente do que possuía anteriormente e a troca de mensagens é rompida, pois um diálogo é caracterizado pela troca de mensagens entre dois endereços determinados. Para exemplicar, imagine que a transferência de um arquivo por uma conexão TCP seria perdida durante a troca da conexão ativa com um ponto de acesso por outro ponto devido à movimentação de seu dispositivo. Há dois tipos de entrega de conexão: a horizontal (horizontal handover) onde a entrega é feita entre estações que utilizam o mesmo tipo de interface de rede sem o; e a entrega vertical da conexão (vertical handover), feita entre redes que utilizam diferentes tipos de tecnologia (Stemm e Katz, 1998). Essa última é um tipo particular de entrega que possibilita o movimento do dispositivo entre diferentes tipos de redes, conhecido como mobilidade vertical (McNair e Zhu, 2004). O artigo do MOSAIC propõem justamente uma solução para esse obstáculo. A necessidade de se preocupar com a mobilidade vertical surgiu junto aos dispositivos móveis inteligentes que podem se conectar à uma multidão de redes com áreas de cobertura sobrepostas, ou seja, possuem capacidades 1
multi-homing. Um exemplo simples e atual seria a conexão de um celular inteligente com a internet pelo Wi-Fi e uma rede de celular 4G ao mesmo tempo. 4 Proposta Song et al. propõem uma solução de mobilidade vertical compatível com a tecnologia atual e transparente para as aplicações do dispositivo do cliente, permitindo que sessões continuem ativas mesmo com a troca de IP do dispositivo, isto é, proporciona uma mobilidade vertical da sessão. Também possibilita a alternância de servidores de conteúdo (CDNs) da sessão no processo de entrega de conexão. Servidores de conteúdo distribuem conteúdo de um servidor principal (origem) para servidores réplicas próximos aos clientes nais (Peng, 2004). CDNs são usadas para diminuir a latência das conexões com os clientes, e também distribuir a carga de conexões no sistema utilizador da CDN. Mas considero isso uma consequência do método utilizado pelo MOSAIC, e não uma característica. Um aspecto importante apresentado no estudo de Labovitz et al. sobre o tráfego da internet é a grande presença das seguintes categorias de uso da mesma: navegação na web, streaming de vídeo e transferência de arquivos. Categorias que, não obrigatoriamente mas, na maioria utilizam o protocolo HTTP em suas aplicações (Labovitz et al., 2010). A solução MOSAIC tira proveito de conexões que não mantém estado, ou conexões sem estado (stateless), e em particular do uso do protocolo HTTP. 5 A Solução MOSAIC 5.1 Mobilidade Sem Estado O artigo introduz o conceito de mobilidade sem estado (stateless mobility) para dispositivos hospedeiros que possuem sessões ativas pertencentes à aplicações sem estado, aplicações que utilizam conexões sem manter o estado da mesma. Mobilidade sem estado permite a troca de IP do hospedeiro bem como da fonte do conteúdo usados pela sessão em andamento. Como a troca de IP pode ser tanto na mesma ou em uma interface diferente de rede, mobilidade sem estado também suporta multi-homing. A solução proposta no MOSAIC baseia no conceito de mobilidade sem estado que atende tanto problemas de mobilidade vertical como mobilidade horizontal. Então por que o MOSAIC é voltado para mobilidade vertical? Apesar de funcionar para na entrega de conexão utilizando a mesma interface, o artigo diz não ser a melhor solução para mobilidade horizontal devido ao atraso associado ao restabelecimento da conexão. Assim pressupõe a presença da característica multi-homing para migração de conexão entre diferentes interfaces de rede, veremos mais adiante como é feita essa transição. Mobilidade sem estado conna todas as operações relacionadas à mobilidade no hospedeiro. Assim, nem o servidor de conteúdo, nem a rede mantém informações relacionadas à mobilidade. Isso evita a necessidade de um protocolo de mobilidade. Ao invés disso, uma nova requisição é feita a cada evento de mobilidade, a qual contém informações sobre o restante do conteúdo sendo transferido na sessão em andamento. Com esse m, a solução tem base no HTTP 1.1, utilizando o 2
método GET parcial que possui um campo Range em seu cabeçalho, que contém índices do byte inicial e nal de um fragmento do conteúdo (Fielding et al., 1999). 5.2 Arquitetura Figura 1: Arquitetura do MOSAIC A gura 1 descreve a arquitetura do MOSAIC para hospedeiros com característica multi-homing. Exemplica uma situação onde um dispositivo móvel (celular, tablet ou notebook) possui conectividade com a Internet tanto pela rede 3G/4G como por um sinal Wi-Fi. Nessa arquitetura o MOSAIC reside entre a aplicação e as interfaces de rede. Assumimos que o conteúdo é replicado em diferentes provedores de conteúdo em cada interface. E que cada interface suporta seu próprio servidor de DNS. É importante notar que nesse ponto o artigo assume que existe um gerenciador de conexões, que monitora a disponibilidade das interfaces e decide quando a entrega de conexão deve haver. Nesse evento, o gerenciador notica o MOSAIC que executa a migração das sessões. 5.3 Funcionamento O funcionamento do MOSAIC é a parte mais interessante do artigo onde há a explicação e esclarecimento de como a solução migra uma conexão entre interfaces sem que a aplicação note. A gura 2 mostra o MOSAIC em operação. Para começar a sessão o cliente resolve o endereço IP do servidor de conteúdo através de uma requisição DNS, estabelece uma conexão TCP, e envia uma requisição HTTP ao servidor(1). Como o MOSAIC reside entre a aplicação e as interfaces e rede, ele inspeciona a requisição HTTP e decide se existe o suporte à mobilidade. No caso de existir, o MOSAIC guarda a requisição HTTP GET e continua a inspecionar todos os dados subsequentes recebidos dessa conexão. O servidor de conteúdo devolve um HTTP response (2), e começar a transmitir o conteúdo (3). O 3
Figura 2: Funcionamento do MOSAIC MOSAIC analisa o HTTP response por motivos que serão apresentados adiante, e conta os bytes do conteúdo sendo recebido. Quando a troca de interface ocorre, o MOSAIC encerra a conexão TCP (4). Inicia o DNS handshake na nova rede para encontrar o servidor de conteúdo ótimo. Para isso, ele insere na consulta DNS o endereço HTTP URL contido na requisição HTTP GET guardada (5). Após obter o DNS response (6), o MOSAIC estabelece uma conexão TCP com o novo servidor, onde ele envia um GET parcial. Essa requisição contém os cabeçalhos do HTTP GET original e o cabeçalho Range (7), no qual o byte inicial é baseado na conta do total de bytes do conteúdo recebido. Da transmissão de dados enviada pelo novo servidor, o MOSAIC extrai e suprimi o HTTP response (8) e retransmite todo a informação de conteúdo para o processo do cliente (9). O MOSAIC continua a contar os bytes recebidos para o caso de novas trocas de interface. Note que o a informação retransmitida pelo MOSAIC precisa ser mascarada para que a aplicação pense que ainda está conversando com o primeiro servidor. Como essa solução utiliza conexões TCP independentes e requisições HTTP em cada rede, ela é compatível com middleboxes como rewalls, tradutores de endereço, sistemas detectores de intrusos, e proxies HTTP. Também suporta redirecionamentos HTTP, que podem ser utilizados para redireção de clientes para servidores de conteúdo ótimos, em adição ao sistema baseado em DNS. Nesses casos o HTTP response inicial provê um URL alternativo do qual o conteúdo deveria ser recuperado. 4
Figura 3: Implementação do MOSAIC no Linux 5.4 Implementação Um ponto importante do MOSAIC é a transparência para qualquer tipo de aplicação. Para atingir tal objetivo o MOSAIC precisou ser implementado abaixo da interfaces de sockets. Assim a implementação foi feita com um ltro de pacotes na camada de rede OSI L3. A implementação foi feita em Linux, utilizando o arcabouço de ltragem de pacotes chamado Netlter, que permite que as modicações dos pacotes sejam feitas no espaço do usuário. Esse desvio para o espaço do usuário permite prototipação rápida, depuração e a realização de experimentos com maior facilidade. Depois um código maduro pode ser fornecido como um módulo do kernel. A gura 3 mostra a implementação no Linux. O Netlter possibilita a injeção de regras de ltragem pacotes através do comando iptables. Os pacotes ltrados são enviados para um la que segue para o espaço de usuário através de um Netlink Socket. O MOSAIC então inspeciona e eventualmente modica o conteúdo dos pacotes e os reinsere no uxo de pacotes. Pacotes também podem ser descartados. Além disso, o MOSAIC pode criar e inserir novos pacotes utilizando uma API de Raw Sockets. Enquanto não há uma recuperação de conteúdo em andamento, o MOSAIC seleciona somente os pacotes TCP SYN para inspeção o que diminui a sobrecarga de processamento. Quando um pacote SYN chega, a seleção de pacotes é ampliada para todos os pacotes pertencentes à essa conexão TCP e o MOSAIC continua a monitorar o TCP handshake. Quando a conexão é estabelecida, o MOSAIC inspeciona a primeira carga útil de pacotes e procura por uma requisição HTTP GET. Se tal requisição não existir ou se o MOSAIC decida omitir suporte à mobilidade para o URL daquela requisição, o monitoramento é encerrado. Caso contrário, o funcionamento do MOSAIC segue como é explicado na seção??. Uma explicação mais detalhada do funcionamento pode ser encontrada no artigo original do MOSAIC (Song et al., 2012). Mas não há mais detalhes em relação à implementação, como por exemplo, não é dita a linguagem de programação utilizada para desenvolver o protótipo do MOSAIC. 5
6 Experimentos Os experimentos foram realizados em três domínios de tráfego HTTP: navegação na web, transferência de arquivos (recepção) e streaming de vídeo. São as três categorias citadas na seção 4, sobre as quais a internet tem maior presença. Esses experimentos foram feitos utilizando sites reais. MOSAIC foi executado em um laptop equipado com uma interface Wi-Fi (802.11g) e uma interface Ethernet (1GB/s). A instalação do experimento foi similar à gura 1, onde as duas interfaces estavam conectadas à Internet via sub-redes independentes. O laptop era um Lenovo T61 com um processador Intel Core 2 Duo 2.1GHz, o qual rodava o Ubuntu 11.04 acimado kernel 2.6.38 do Linux. Como cliente HTTP, foi utilizado o navegador Google Chrome 13.0, o qual possuía plug-ins para o Adobe Flash Player 10.3 e Moonlight 4.0 para suportar os experimentos com streaming de vídeo (Moonlight é a implementação do Microsoft Silverlight no Linux). 6.1 Compatibilidade Qualquer serviço HTTP é compatível com o MOSAIC, desde que suporte o GET parcial do HTTP, que é uma característica opcional do HTTP 1.1. Os primeiros experimentos vericaram a compatibilidade do MOSAIC com alguns sites. Para isso, requisições HTTP GET parciais foram enviadas para cada website, e o código de status no HTTP response era examinado. Se o status foi "206 Partial Content", o GET parcial era suportado. Caso contrário o site responderia com "200 OK". O índice do byte inicial no cabeçalho Range era denido como bem pequeno, para nunca exceder o tamanho total do conteúdo. Para compatibilidade com navegação na web, foram utilizados os top cinco sites mais acessados de acordo com Alexa.com. Esse sites eram: www.google.com, www.facebook.com, www.youtube.com, www.yahoo.com, e www.baidu.com. E foi descoberto que nenhum desses sites suporta o GET parcial. O artigo diz que a falta de suporte desses sites deve ser causada pelo tamanho pequeno das páginas, o que torna desnecessário o GET parcial. A recepção de arquivos foi medida para uma imagem do Ubuntu Linux ISO de 1.5GB, o Oracle Java Development Kit (JDK) de 63.6MB, e o instalador do Adobe Flash Player de 4.5MB. Em contraste com o primeiro experimento, todas esses serviços de transferências de arquivos suportam o GET parcial. Finalmente foram analisados serviços de streaming de vídeo mostrados na tabela 1. O site do YouTube provê vídeos via download progressivo tanto no formato Flash como HTML5. Para o formato Flash o navegador Chrome utiliza o plug-in do Flash Video Player enquanto suporta nativamente o formato HTML5. Para ambos formatos o YouTube suporta GET parcial. O site do TED também suporta download progressivo por Flash e HTML5. Contudo o serviço que utiliza Flash é baseado no protocolo Real-Time Messaging Protocol (RTMP), que é um protocolo que mantém estado (stateful) proprietário da Adobe. Então mobilidade sem estado não é suportada. O serviço baseado em HTML5 é restrito a dispositivos com ios da Apple. Por isso tiveram de alterar o User-Agent do Chrome para "ipad". Assim conseguiram conrmar a compatibilidade do serviço baseado em HTML5. Os serviços da Akamai e Microsoft na tabela 1 são ambos variantes do Dynamic Adaptive Streaming over HTTP (DASH ). Um tipo de streaming onde a reprodução adapta-se dinamicamente 6
Tabela 1: Compatibilidade do MOSAIC com sites de streaming de vídeo. Nome (URL) Tecnologia Compatibilidade com MOSAIC YouTube Progressive Sim (http://www.youtube.com (Flash e /watch?v=plxnfu-pa2c) HTML5) TED Progressive Sim (http://video.ted.com/t (HTML5) alk/stream/2011u/none/m attcutts_2011u-950k.mp4) Akamai HD Network Demo Adobe HTTP Sim (http://wwwns.akamai.com/ Dynamic hdnetwork/demo/ash/hds/ Streaming index.html) MS Experience Smooth MS Smooth Sim Streaming (http://www.iis Streaming.net/media/experiencesmoo thstreaming) ao ambiente dependendo do acesso à banda ou processamento (Stockhammer, 2011). O MOSAIC funcionou em ambos serviços. Por outro lado por limitações do Linux, não foi possível avaliar o Apple HTTP Live Streaming devido a falta de um plug-in do QuickTime. E o Netix, que apesar de usar a tecnologia Microsoft Smooth Streaming, utiliza o Digital Rights Management (DRM ) característica do Silverlight que não é suportada pelo Moonlight. Mas esses são problemas de plataforma, o que não remete a um problema na solução. Não há como tratar da conexão de um vídeo que nem pode ser reproduzido. 6.2 Entrega da Conexão Foi feita uma análise detalhada do comportamento do MOSAIC durante os eventos de mobilidade. No artigo são exibidos somente os resultados do experimento feito com o vídeo do TED. Não justicam o motivo, mas é provável que sejam os resultados mais expressivos, ou todos os resultados foram muito parecidos. A gura 4 mostra o número de sequência dos pacotes contra o tempo da reprodução do vídeo. Figura 4(a) retrata a entrega de uma conexão Ethernet para o Wi-Fi e a gura 4(b) o inverso. As entregas ocorreram nos segundos 6.6 e 24.9 respectivamente, mudando a inclinação do gráco. As diferentes inclinações reetem o rendimento de conexões Ethernet e Wi-Fi em relação à taxa de transferência. O nivelamento entre os 11.0 e 12.4 segundos da gura 4(a) indica perda de pacotes e retransmissões. As guras 4(c) e 4(d) mostram o curto intervalo de tempo onde os eventos de entrega ocorrem. É clara nesses grácos a relação de um atraso de tempo com cada evento. Há uma análise do atraso na seção 6.4. Os número de sequência nas coordenadas dessas guras pertencem ao bloco de controle TCP do hospedeiro. Vemos que todos os pacotes são entregues, devido à continuidade do crescimento do número de sequência TCP. Isso mostra que a implementação do MOSAIC funciona já que torna os 7
Figura 4: Tempo vs. número de sequência TCP eventos de mobilidade transparentes para a camada de transporte do hospedeiro. 6.3 Troca de Servidor de Conteúdo A capacidade de trocar de servidor de conteúdo também será exibida. A tabela 2 mostra o endereço de IP dos servidores de streaming de vídeo durante a reprodução do vídeo do TED, antes e depois de cinco experimentos. Ambos endereços IP de cada teste foram obtidos por DNS, contudo o primeiro foi feito pela interface Ethernet e o segundo por Wi-Fi. No caso da resposta do DNS possuir mais de um endereço, o MOSAIC sempre optou pela primeiro candidato, mas o critério aplicado pelo reprodutor do vídeo é desconhecido, apesar disso acho razoável a decisão deles. Como é visível na tabela 2, nos experimentos 3 e 4, o servidor de conteúdo muda durante a entrega da conexão. O fato de não haverem mudanças nos outros resultados indicam que as sub-redes são topologicamente próximas (se pensarmos na rede como um grafo de sub-redes, os nós dessas sub-redes estão próximos) e provavelmente pertencem à um mesmo AD (administrative domain). As mudanças nos experimentos 3 e 4 para endereço IP diferentes parecem ocorrer devido à priorizações de respostas de DNS. O resultado desses experimentos é positivo, pois os vídeos continuaram com suas reproduções mesmo após as trocas de suas fontes de conteúdo. Considero a troca de servidor de conteúdo algo natural, uma consequência da solução do MOSAIC que efetua uma nova solicitação DNS durante um evento de mobilidade. 8
Tabela 2: IP de destino após um evento de mobilidade. Experimento Interface Endereço de IP do destino 1 eth0 67.148.147.43 wlan0 67.148.147.43 2 eth0 67.148.147.43 wlan0 67.148.147.43 3 eth0 67.148.147.43 wlan0 67.148.147.129 4 eth0 67.148.147.120 wlan0 67.148.147.129 5 eth0 67.148.147.120 wlan0 67.148.147.120 6.4 Desempenho Figura 5: Taxa de transferência média com e sem MOSAIC. Figura 6: Atraso na entrega da conexão. O impacto do MOSAIC foi analisado tanto sobre a taxa de transferência assim como o atraso durante uma entrega de conexão. A gura 5 compara a taxa de transferência média dos downloads do vídeo do TED com e sem o MOSAIC conforme aumentamos o número de transferências em paralelo. A medida mais expressiva foram com três downloads concorrentes, onde a taxa de transferência com o MOSAIC é 4% menor: 3.78MB/s contra 3.94MB/s. O gráco indica que o impacto do MOSAIC é desprezível apesar da inspeção sobre todos os pacotes. O atraso de uma entrega de conexão é denido pelo tempo entre a requisição de uma troca de interface pelo gerenciador de conexões e a recepção do primeiro pacote de conteúdo na nova interface. Não é considerado o tempo que a nova interface leva para conectar-se, consideramos que as duas interfaces estão ligadas à Internet quando o evento de mobilidade ocorre. O atraso total foi analisado com respeito às seguintes contribuições: atraso de processamento, consulta do DNS, TCP handshake, e o HTTP handshake. O atraso de processamento é causado principalmente pela atualização da tabela de roteamento do hospedeiro. A gura 6 mostra os resultados médios das entregas de Ethernet para Wi-Fi e Wi-Fi para Ethernet. O atraso total é ca um pouco abaixo de 100ms. O artigo diz que esse valor poderia ser 9
reduzido para 60 70ms se a consulta de DNS e TCP handshake fossem feitos antes da quebra de conexão. E como isso já necessitária alterar a tabela de roteamento, também diminuiria o tempo de processamento. Note que o HTTP handshake não pode ser feito de antemão, pois o Range de bytes que irá na requisição do GET parcial necessita estar bem denido, ou seja, a conexão precisa ser encerrada a priori. Então uso de métodos mais renados que estimariam esse número poderiam reduzir o atraso mais ainda. O atraso abaixo dos 100ms aceitável para a maioria das aplicações. Principalmente para streaming de vídeo, onde as próprias aplicações já proveem buers para reprodução e esse atraso nem será notado. 7 Discussão O MOSAIC provê suporte à mobilidade para sites reais desde que seus serviços implementem o GET parcial. Isso poem em prática o principal conceito de mobilidade sem estado para aplicações baseadas em HTTP, também mostra a transparência da implementação feita. Considerando que páginas web são relativamente pequenas, podemos desprezar o fato da navegação na web não ser suportada pelo MOSAIC. Podemos notar também que ele não atrapalha o funcionamento dos serviços não suportados, eles agiriam como se o MOSAIC não existisse. Vimos o MOSAIC atuando em serviços de recuperação de conteúdo que consomem tempo, como transferência de arquivos e vídeos. O fato do MOSAIC funcionar para esses serviços apoiam a utilidade da mobilidade sem estado para o mercado. O texto menciona o baixo custo de se implantar o MOSAIC, devido à necessidade de modicar somente os dispositivos. Não é dito, mas considero que isso se aplicaria somente para novos dispositivos, como uma funcionalidade a mais. Apesar dos bons resultados o texto comenta sobre as limitações em relação à mobilidade sem estado: Atuam somente sobre aplicações sem estado; Falham sobre conteúdo sensitivo ao tempo, devido à divisão de requisições; Não servem para aplicações que usam HTTPS por não conseguirem inspecionar seus pacotes. Ao ler o artigo não vi a necessidade da troca de servidor de conteúdo, mas podemos considerá-la fruto da requisição DNS feita durante a solução, que pode devolver um endereço diferente do servidor original. Com isso em mente, considerei a remoção dessa requisição e utilização da resposta do DNS original. Isso reduziria o atraso e sobrecarga do MOSAIC, contudo não sabemos o que acontece com o servidor no espaço de tempo entre o início da conexão original e o evento de mobilidade. O servidor original pode estar indisponível nesse momento, assim a nova requisição de DNS a cada entrega de conexão é aceitável. 7.1 Conclusão O artigo introduz o conceito de mobilidade sem estado e apresenta um protótipo de implementação que aplica esse conceito. A solução é genérica para aplicações baseadas em HTTP e pode ser 10
facilmente migrada para várias plataformas, além de ser implantada comercialmente. No geral os experimentos validam a solução e quanticam a sobrecarga da mesma. Minha opinião geral sobre a solução implementada é positiva, principalmente pelo fato dela atuar sobre serviços que consomem tempo de forma transparente, e por ser compatível com o que existe atualmente. Mas considero que em muitos casos, as próprias aplicações sem estado podem resolver o problema da entrega de conexão pelo mesmo fato de não guardarem estado. Transferências de arquivos podem ser resolvidas com gerenciadores de downloads, e reprodutores de vídeo poderiam implementar internamente um mecanismo parecido com o MOSAIC. Mas pensando pelo lado prático, o MOSAIC resolveria o problema de todas as aplicações sem estado em um lugar só. 11
Referências Fielding et al. (1999) Roy Fielding, Jim Gettys, Jerey Mogul, Henrik Frystyk, Larry Masinter, Paul Leach e Tim Berners-Lee. Hypertext transfer protocolhttp/1.1, 1999. Citado na pág. 3 Labovitz et al. (2010) Craig Labovitz, Scott Iekel-Johnson, Danny McPherson, Jon Oberheide e Farnam Jahanian. Internet inter-domain trac. Em ACM SIGCOMM Computer Communication Review, volume 40, páginas 7586. ACM. Citado na pág. 1, 2 McNair e Zhu (2004) Janise McNair e Fang Zhu. Vertical handos in fourth-generation multinetwork environments. Wireless Communications, IEEE, 11(3):815. Citado na pág. 1 Peng (2004) Gang Peng. Cdn: Content distribution network. arxiv preprint cs/0411069. Citado na pág. 2 Song et al. (2012) Wonsang Song, Georg Hampel, Anil Rana, Thierry Klein e Henning Schulzrinne. Mosaic: Stateless mobility for http-based applications. Em Wireless and Mobile Computing, Networking and Communications (WiMob), 2012 IEEE 8th International Conference on, páginas 6976. IEEE. Citado na pág. i, 1, 5 Stemm e Katz (1998) Mark Stemm e Randy H Katz. Vertical handos in wireless overlay networks. Mobile Networks and applications, 3(4):335350. Citado na pág. 1 Stockhammer (2011) Thomas Stockhammer. Dynamic adaptive streaming over http: standards and design principles. Em Proceedings of the second annual ACM conference on Multimedia systems, páginas 133144. ACM. Citado na pág. 7 The Cisco R Visual Networking Index (VNI) (2013) The Cisco R Visual Networking Index (VNI). Global mobile data trac forecast update, 20122017. Relatório técnico. Citado na pág. 1 12