Computação Móvel Suporte à Mobilidade - dpi.ufv.brnacif/cmovel/11_iMode_Databases.pdf ·...

Prof. Mauro Nacif Rocha – DPI/UFV 1

Computação MóvelSuporte à Mobilidade

i-mode Sistemas de Arquivos Bancos de Dados


i-mode


i-mode – antes de tudo um modelo de negócios!

Acesso a serviços de Internet no Japão provido pela NTT DoCoMo (1999) Serviços

Email, SMS, web, picture exchange, horóscopo, ... Grande sucesso – mais de 46 milhões de usuários no Japão e 5 milhões

em outros países Muitos usam i-mode em lugar do PC Para muitos tem sido o 1º contato com a Internet Muito simples de usar, conveniente

Tecnologia 9.6 kbit/s ou 28.8 kbit/s, orientado a pacotes (PDC-P) Compact HTML (cHTML) + tags proprietários, camada de transporte especial (orientado a

conexão)

PDC-P

TLHTTP(S)

cHTML + tags

mobile terminal

PDC-P

TL

mobile network gateway content provider

L1L2IP

TCP

L1L2IP

TCP

L1L2IP

TCP

L1L2IP

TCPHTTP(S)

cHTML + tags


i-Mode: parcerias

Alemanha (E-Plus, O2) Holanda (KPN) Bélgica (Base) França (Bouygues Télécom) Espanha (Telefónica) Itália (Wind) Grécia (Cosmote) Austrália (Telstra) Taiwan (Far East Tone) Reino Unido e Irlanda (O2) Singapura (StarHub) Israel (Cellcom) Bulgária (Globul) Rússia (MTS)


Exemplo (Email): i-mode push com SMS

aplicação

WSP

WTP

WDP

SMS

Operadora envia um SMS contendouma mensagem push se um novo e-mailchegou. Se o usuário quiser ler o e-mail,um HTTP get segue contendo o e-mailcomo resposta.

Desentendimento popular:WAP foi um fracasso, i-mode é diferentee um sucesso – errado do ponto de vistatecnológico, correto do ponto de vista denegócios…

i-mode como modelo de negócios:- provedoras ficam com 80% dareceita.- independente da tecnologia

(GSM/GPRS na Europa,PDC-P no Japão)


Pilha de protocolos i-mode baseado em WAP 2.0

user equipment gateway

i-mode pode usar os protocolos de Internet do WAP 2.0(exemplo: i-mode na Alemanha sobre GSM/GPRS)

server

cHTML

HTTP

WTCP

IP

L2

L1

SSL

WTCP

IP

L2

L1

TCP

IP

L2

L1

cHTML

HTTPSSL

TCP

IP

L2

L1


i-mode – technical requirements (Mandatory / Optional)

Functions Descriptions Status Requirement

WEB Access Portal Site / Internet Access M i-mode HTML (cHTML+tags)

E-mail Internet e-mail and inter-terminal email M HTTP 1.1

Security End-End security O SSL (Version 2, 3), TLS 1

Java Java application made available O Compatible i-mode JAVA

Ringing tone download Ringing melody download M SMF based

Image download Stand-by screen download M GIF (O: JPEG)

Voice call notification during i-mode session

Voice termination notified and responded during i-modecommunications

M 3GPP standard system

Content charge billing Per content charge billed to user M Specifications depend on eachoperator’s billing system

Third party payment collection Content charge collection on behalf of Content Provider M Specifications depend on eachoperator’s billing system

Reverse billing Packet usage charges can be billed to third party O Specifications depend on eachoperator’s billing system

Subscriber ID transmission Hashed subscriber ID from the operator’s portal to the CPtransmission on each content access

M The ID generation algorithmshould be determined by eachoperator and has to be secret

Number of characters per e-mail

Number of characters (byte) per e-mail M To be defined by operators (e.g.500 byte, 1K byte, 10K byte)

Character code set supported Character code set supported by browser and used to develop content M To be defined by operators

User Agent Browser specifications to be notified M HTTP 1.1

i-mode button Dedicated button O Hard or soft key


i-mode exemplos I


i-mode exemplos II


i-mode exemplos III


File Systems / Database Systems


Sistemas de Arquivo - Motivação

Objetivo acesso eficiente e transparente a arquivos compartilhados dentro de um

ambiente móvel, mantendo a consistência dos dadosProblemas

recursos limitados dos dispositivos móveis (memória, CPU, ...) largura de banda baixa e variável, desconexões temporárias alta heterogeneidade dos componentes de hardware e software (sem

arquitetura padrão) rede sem fio e dispositivos móveis não são muito confiáveis sistemas padrão (e.g., NFS, NTFS) são muito ineficientes

Soluções replicação de dados (cópia, clonagem, caching) hoarding, pre-fetching


Sistemas de Arquivo – problemas de consistência

O grande problema de sistemas distribuídos, fracamente acoplados todas as visões dos dados são iguais? como e quando as mudanças devem ser propagadas a quais usuários?

Consistência fraca muitos algoritmos que oferecem consistência forte (e.g., via atualizações

atômicas) não podem ser usados em ambientes móveis invalidação de dados localizados em caches no servidor é problemático se

o dispositivo móvel estiver desconectado da rede inconsistências ocasionais devem ser toleradas, mas estratégias de

resolução de conflitos devem ser aplicadas depois para alcançarconsistência novamente

Detecção de conflitos independente do conteúdo: numeração de versões, time-stamps dependente do conteúdo: grafos de dependência


Sistemas de Arquivo para conectividade limitada

Simetria Relações Cliente/Servidor ou P2P suporte a redes fixas e/ou unidades móveis (UMs) um único file system ou diversos file systems um único namespace para arquivos ou diversos namespaces

Transparência esconder o suporte à mobilidade, aplicações em UMs não devem perceber

a mobilidade usuários não devem perceber os mecanismos adicionais necessários

Modelo de consistência optimistic / pessimistic

Caching / Pre-fetching arquivos, diretórios, sub-árvores, partições, ... permanente ou somente em certos momentos


Sistemas de Arquivo para conectividade limitada

Gerenciamento de dados gerenciamento de dados em buffers e cópias de dados requisições de updates, validação de dados detecção na mudança de dados

Resolução de conflitos geral ou dependente do aplicativo erros

Vários sistemas experimentais existem Coda (Carnegie Mellon University), Little Work (University of Michigan),

Ficus (UCLA) etc.

Muitos deles usam idéias tiradas de sistemas de arquivos distribuídos,e.g., AFS (Andrew File System) – Andrew Project – Carnegie Mellon.


mobile client

Coda File System (desde 1987) – derivado do AFS-2

Extensões p/ cliente e servidor transparentes à aplicação modificações ao gerenciador de cache do cliente aplicações usam réplicas em cache dos arquivos Hoarding extensivo e transparente de coleções de dados para possível

uso futuroConsistência

sistema mantém um registro de mudanças em arquivos e os comparaapós reconexão

se usuários diferentes mudaram um mesmo arquivo, uma reintegraçãomanual do arquivo no sistema é necessário

abordagem otimista, de grão grosso (file size)

cacheapplication server


Coda File System

Hoarding usuário pode pré-determinar uma

lista de arquivos com prioridades conteúdo do cache determinado

pela lista e estratégia LRU (LastRecently Used)

pre-fetching explícito possível updating periódico

Comparação de arquivos assíncrono, em segundo plano sistema avalia velocidade de

atualização x minimização detráfego na rede

Cache misses modelagem da paciência do usuário:

quanto tempo a pessoa espera porum dado sem receber umamensagem de erro?

função do tamanho do arquivo elargura de banda

hoarding

writedisconnected

emulating

disconnection

disconnection

connection

strongconnection

weakconnection

Estados de um cliente


Little Work File System

Só modifica o gerenciador de cache do cliente Modos de conexão e uso

Connected PartiallyConnected

Fetch only Disconnected

Method normal delayed writeto the server

optimisticreplication of files

abort at cachemiss

Networkrequirements

continuoushighbandwidth

continuousbandwidth

connection ondemand

none

Application office, WLAN packet radio cellular systems(e.g., GSM) withcosts per call

independent


Sistemas de Arquivos – outros exemplos

Mazer/Tardo camada de sincronização entre aplicação e sistema de arquivos local caching de subdiretórios inteiros do servidor “Redirecionador” responde a pedidos locais, se necessário, ou via rede, se

possível verificações periódicas de consistência com atualizações bidirecionais

Ficus Não usa abordagem cliente/servidor abordagem otimista baseado em replicações, detecção de write conflicts,

resolução de conflitos Uso de protocolos do tipo “gossip” (fofoca): a UM não precisa

necessariamente estar conectado a um servidor. As outras UMs podemfazer o papel de roteadores na rede

MIo-NFS (Mobile Integration of NFS) Extensão do NFS, abordagem pessimista, somente a UM que possui o

token pode gravar conectado / fracamente conectado / desconectado


Sistemas de BD em ambientes móveis

Processamentos de pedidos conservação de energia, dependência da localização, eficiência de

custo exemplo: encontre o caminho mais rápido até um hospital

Gerenciamento de replicações similar aos sistemas de arquivos

Gerenciamento de localização monitorar UMs para prover informações dependentes de

localização no tempo e local certos (minimizar atrasos no acesso) exemplo: com a ajuda do HLR (Home Location Register) no GSM,

a UM pode encontrar um serviço de guinchoProcessamento de transações

transações “móveis” não precisam necessariamente se basear emmodelos tradicionais (ACID: atomicidade, consistência, isolamento,durabilidade)

Com isso, podemos ter modelos para transações “fracas”



Exemplos: Oracle Lite 10g, 11g (comercial) Metanotion BlockFile (Open Source, Java) SQL Server 2000 CE Edition 2 (free / pago) – Microsoft .NET

Compact Framework (.NET CF) IBM® Mobile Database (free) – p/ Android – integração estreita e

sincronização com DB2 e Informix. SQLite (Open Source, C) – embedded DB – iOS, Windows

Phone 8, Android, Symbian, Maemo, BlackBerry, MeeGo…

Mobile Data Now (http://www.mobiledatanow.com/) – acesso aBDs usando SMS, e-mail ou IM. Free p/ uso pessoal (1 usuário)



Oracle Lite 10g / 11g (comercial)

Cliente: Windows 2003/XP/Vista , Linux, Windows Mobile / Pocket PC,embedded Linux, Symbian OS.

Preço (em 2008): US$23.000 por processador (Lite Mobile Server)(verif. 2011) US$60 (Lite Mobile Client)


World Wide Web e mobilidade

Protocolo (HTTP) e linguagem (HTML) não foi projetada paraaplicações em mobilidade e podem causar muitos problemas

Tamanhos típicos de transferência HTTP request: 100-350 bytes respostas médias <10 kB, cabeçalho 160 bytes, GIF 4.1kB, JPEG

12.8 kB, HTML 5.6 kB mas também temos muitos arquivos grandes que não podem ser

ignoradosA Internet não é um sistema de arquivos

Páginas web costumam não ser simples para baixar conteúdo estático ou dinâmico, interação com servidores através

de formulários, transformação de conteúdo, tecnologias push etc. muitos hyperlinks, carregamento e recarregamento automático,

redirecionamentos um único click pode ter grandes conseqüências!

Computação Móvel Suporte à Mobilidade - dpi.ufv.brnacif/cmovel/11_iMode_Databases.pdf ·...

Documents

Transcript of Computação Móvel Suporte à Mobilidade - dpi.ufv.brnacif/cmovel/11_iMode_Databases.pdf ·...