platform for mobile computing

𝐿

imbo: A distributed systems

platform for mobile computing

Nigel Davis

Gordon Blair Stephen Wade

Introdução

• Adaptative applications:

– Caracterizadas por rápidas alterações na sua infra-estrutura e QoS.

– Requerem suporte de sistema distribuído. – Mobile DCE, MOST platform, Rover Toolkit. – Suportam buffers RPC durante a desconexão.

• Linda: plataforma de espaço de tuplos original.

Quality-of-Service (QoS)

• Redes fixas – Ethernet – largura de banda.

– Superior às redes Móveis (GSM)

• Redes devem ser caracterizadas tendo em conta:

– Acess time – Bit error rates

– Error control strategies – Orientation

– Functionality

– Charge in batteries

– Power consumption (network interface, hardware, display, hard disk)

Mobile DCE

• Baseado no conceito de domínios

• Clientes movem-se pelos domínios e têm acesso a diferentes recursos

• Processo gestor utiliza uma matriz para

garantir o serviço quando o cliente muda de domínio

• Implementado em Windows/NT • Mobile email

MOST platform

• Suporte para aplicação moveis adaptativas numa Open Distributed Processing (ODP) • Utiliza QEX para adaptar alterações no QoS • QEX permite mensagens com deadlines

• Buffers para mensagens

• Implementado em Sun workstations e notebooks (Linux)

Rover Toolkit

• Suporte a desenvolvimento de aplicações móveis

• Realocação dupla da informação dos objectos • QRPC – RPC com filas

• Objectos com interfaces bem definidas • Buffers de mensagens

• Não é baseado em nenhuma plataforma existente

Resumo

• Plataformas utilizam RPC síncrono • Modelo orientado à conexão

• Formas de determinar o QoS da rede underlying

• Construir aplicações que se adaptem a alterações do QoS

Tuples Space

• Generative communication: processos comunicam exclusivamente pelo TS

• Existe desacoplamento espacial e temporal

• Linda embebida em linguagens como C ou Pascal • Operações:

– out: insere um tuplo. – in: remove um tuplo – rd: lê um tuplo

Arquitectura 𝐿

imbo

• Baseada no Linda • Alterações:

– Vários TS que podem ser especializados para reconhecer requisitos de aplicações

– TS hierárquico com suporte a subtipos dinâmicos – Tuplos com QoS e deadlines

– Um número de agentes de sistema para regular serviços.

Vários TS

• Melhoria a nível de performance, partição, e escalabilidade

• System agent que pode criar novos TS através do Universal Tuple Space (UTS)

out (create_tuple_space, QoS, characteristics, request_id) in (tuple_space, ?QoS, ?characteristics, ?handle, request_id)

discard – deitar fora um handle terminate – destruir um TS

Hierarquia de TS

• Tuplos estão associados a um tipo.

• Podem ser organizados de forma hierárquica estabelecendo relações de subcategorias

• Optimização: um tuplo é subtipo de outro, se os campos comuns se apresentarem na

Atributos QoS

• Associação entre tuplos e deadlines

deadline em out – representa o tempo

que o tuplo está autorizado a estar num TS antes de ser eliminado

deadline em in ou rd – representa o

tempo que os pedidos podem ser bloqueados antes de darem time out

System Agents

• Fazem computação específica nos TS

• Não é necessário algoritmo de consistência

– Bridging agents

– QoS monitoring agents – Type management agents

Bridging agents

• Fazem ligação entre TS arbitrários e controlam a propagação de tuplos entre esses TS

• Transportam operações rd num TS e fazem

out correspondente ao tuplo num segundo TS • Podem se basear no tipo dos tuplos e

QoS monitoring agents

• Monitoram aspectos do sistema

• Introduzem tuplos com o estado corrente

Connectivity monitors Power monitors

Cost monitors

• Configurações podem ser diferentes

• A informação de um nó pode estar disponível para toda a rede

Type management agens

• Responsável por determinar as relações entre tuplos de diferentes TS.

• É baseado em tuplos de sistema do tipo add_type

• É autoritário, pois relações de subtipo de tuplos são validados

Suporte à adaptação

• Utilização de filtering agents – tipo de bridging agents

– Fazem transformações nos tuplos para mapear diferentes níveis de QoS

Criação do protótipo

• Utilização de daemon process

– Mantém consistência entre copias de TS em diferentes

hosts

– Comunicação com Distributet Tuple Spaces (DTS) protocol

Utiliza EDF – earliest

deadline first

Responsável pela implementação das requisições da aplicação

Responsável pela comunicação entre 𝐿2imbo daemon e a aplicação

DTS protocol

• Utilizado para manter a distribuição local de caches e de pedidos e assegurar que chega a uma eventual consistência • Não especifica quanto tempo leva um tuplo a ser propagado • Ordem total não tem de ser garantida

• IP multicast

• Cada TS é modelado como um grupo multicast • Cada tuplo tem um identificador único

• Concatenação de mensagens individuais para aumentar a performance

DTS protocol (cont)

• Operações:

– out: propaga o tuplo para todos os membros do grupo

– in: precisa de obter o ownership do tuplo para o poder remover

CHOWN_REQ DELETE

REPAIR_REQ REPAIR_ACK

• Host sem conexão podem continuar a aceder a um TS em cache

• Operações de rd e out são permitidas

Implementação 𝐿

imbo

• Linux 2.0 - SunOS 4.1.4 - Solaris 2.5 (multicast) • Optimizações:

– Piggybacking das mensagens DELETE e ACCESS – Supressão de mensagens IN

Trabalho Futuro

• Experimentar um mecanismo cujas aplicações possam injectar trusted stub code na plataforma para se comportar como uma proxy

• Testar 𝐿2imbo numa rede wireless com tecnologias de comunicação TETRA, GSM e WaveLAN

• Aplicações para suportar trabalho cooperativo por membros de serviços de emergência

Avaliação

• Teste numa rede física

– Plataforma está apta para se aproximar à semântica RPC – Rede com velocidade de 10 Mbps

– 1000 RPS’s (chamada com o respectivo paylod size e sem resposta) – Cada teste foi corrido 10 vezes

– Resultados obtidos pela média dos testes

• Métricas:

– Velocidade com que os tuplos são encontrados

𝐿2imbo 4,4 ms

COOL 3,8 ms

𝐿2imbo 1,9 ms

CORBA 2,6 ms

100 Bytes em cada direcção