inferno os sistemas distribuídos anderson biudes guilherme henrique 1

1

INFERNO OSSistemas Distribuídos

Anderson BiudesGuilherme Henrique

2

Introdução

O que é o inferno? Sistema Operacional que fornece

facilidades para o desenvolvimento e a execução de:

Serviços DistribuídosAplicações de Rede

Desenvolvido por Lucent Technologies' Bell Labs

3

Alguns requisitos

Sistemas pequenos 1MB RAM

Sistemas médios 4MB RAM

Sistemas maiores 16MB RAM

4

Principais características

Portabilidade: Intel, SPARC, MIPS, PowerPC Design Distribuído Adaptabilidade Dinâmica Aplicações portáteis Utilizado das seguintes maneiras:

Sistema Operacional Nativo Hospedado dentro dos seguintes sistemas:

WindowsUnix (Irix, Solaris, FreeBSD, Linux, AIX, HP/UX)Plan 9

5

Influência

Influência do sistema operacional Plan 9 (três princípios):

Recursos como arquivos

Espaço de nomes

Protocolo de comunicação padrão

6

Recursos como arquivos

Todo recurso é visto como um arquivo Não importa se é local ou remoto

Acesso a recursos através das operações: open, close, read, write

Principais vantagens Interface simples e bem definida Alta portabilidade Segurança

7

Recursos como arquivos

Interface de rede: /dev/tcp, /dev/udp, etc Informações de processos: /prog Sistema de janelas: /dev/draw Informações: /dev/user, /dev/time,

/dev/sysname, /dev/random Cada diretório tipicamente contém dois

arquivos: data ctl

8

Espaço de Nomes (Namespace) Representação uniforme de recursos

Cada conjunto de arquivos é visto como uma estrutura hierárquica

Espaços de nomes podem ser Importados Exportados

Uso do protocolo Styx Transparência de localização

9

Espaço de Nomes (Namespace) Principal vantagem

Aplicações podem usar recursos de maneira totalmente transparente

Exemplo de uso: depuração remota de programas Um depurador gráfico poderia ler

informações presentes em /prog Detalhe: /prog pode ser local ou remoto

No caso de depuração remota, importa-se o espaço de nomes /prog

10

Protocolo de Comunicação

Styx Protocolo para apresentação de recursos Variação do protocolo 9P desenvolvido para

o Plan 9 Idéia básica: codificar operações de arquivos

em mensagens para serem transmitidas via rede

Transparência completa de recursos Usuários (desenvolvedores de aplicações)

não vêem o protocolo, mas apenas aquivos Acima e independente da camada de

comunicação (TCP/IP, ATM, PPP, etc)

11

Protocolo de Comunicação

É o Styx quem provê:

Visão hierárquica de recursos

Informações de acesso: permissões, tamanhos e datas de arquivos (recursos)

Semântica para leitura e escrita

12

Protocolo de Comunicação

Modelo OSI (Open System Interconnection):

7 - Aplicação 6 - Apresentação 5 - Sessão <======= Styx 4 - Transporte 3 - Rede 2 - Enlace 1 - Física

13

Protocolo de Comunicação

Resolvendo nomes:

echo www.ime.usp.br > /net/dns

cat /net/dns

143.107.45.20

14

Protocolo de Comunicação

Estabelecendo uma conexão: Ler o conteúdo de /net/tcp/clone

Resultado: /net/tcp/43 Escreva a mensagem a seguir em

/net/tcp/43/ctl :connect 8080 143.107.45.20

Em seguida, a comunicação com www.ime.usp.br é feita através da leitura e escrita sobre o arquivo /net/tcp/43/data

15

Limbo

Limbo é a linguagem de programação para o Inferno

Sintaxe influenciada pelo C e Pascal Compilador do Limbo semelhante ao

do Java Código objeto gerado (bytecode - aquivo

.dis) é independente de máquina Interpretação do código por uma

Máquina Virtual (Dis) - Segredo da portabilidade das aplicações

16

Limbo

Programação modular Um programa limbo é composto por um conjunto

de módulos que cooperam para realizar uma tarefa

Um módulo consiste basicamente de duas partes: Especificação das interfaces públicas (funções, constantes,

tipos abstratos de dados, etc)Código que implementa as interfaces

Módulos são carregados dinamicamente (load) Checagem de tipagem rígida em tempo de

execução e compilação Tipos de dados abstratos

17

Limbo

Alguns tipos dados presentes na linguagem: Byte unsigned (8-bits) int signed (32-bits) big signed (64-bits) real long float (64-bits) list,array String channel (para comunicação entre processos) adt (análogo ao struct presente em C) pick (análogo ao union presente em C) module

18

Limbo

implement Hello;include "sys.m";sys: Sys;include "draw.m";Hello: module{

init: fn(ctxt: ref Draw->Context, argv: list of string);};init(ctxt: ref Draw->Context, argv: list of string) {

sys = load Sys Sys->PATH;sys->print("hello, world\n");

}

19

Dis

Dis é a Máquina Virtual (MV) do Inferno Desenvolvido também para compilação

on-the-fly (just-in-time) Uso dos bytecodes para produzir código

nativo O design da MV envolve:

Conjunto de instruções Sistema de módulos

20

Dis

Instruções seguem o modelo CISC (Complex Instruction Set Computer): OP src1, src2, dst Exemplo: c = a + b

add a, b, c

Existência de instruções paraAlocar memória, carregar módulos, criar

processosSincronização e comunicação entre

processos

21

Segurança

O Inferno provê segurança de: Comunicação Controle de recursos Integridade de Sistema

Existência do conceito de canais de comunicação entre processos Mensagens criptografadas Mecanismos que evitam mensagens

corrompidas

22

Segurança

Os recursos são acessados somente por chamadas de módulos

Adição e remoção de recursos de um espaço de nomes é controlada Presença de mecanismos de autenticação

Alguns algoritmos de criptografia presentes: SHA, MD4, MD5, Elgamal (assinaturas), RC4,

DES, Diffie-Hellman (chave pública) Criptografia das mensagens é

transparente para as aplicações

23

Inferno/Limbo vs. JavaOS/Java Limbo vs Java

Ambos possuem sintaxe influenciada pelo C Utilização de uma máquina virtual por

ambos Java usa o conceito de objetos Limbo é um pouco mais simples, entretanto

provê alguns tipos de dados sofisticados, como o channel (comunicação), além de mecanismos para controle de concorrência, autenticação, segurança, etc

Biblioteca gráfica do Inferno (Tk) mais completa que o AWT

24

Inferno/Limbo vs. JavaOS/Java Máquina virtual

A arquitetura do inferno segue o modelo de transferência de memória (memory-to-memory)

As instruções do Dis são traduzidas para uma única instrução de máquina (CISC)

Já a JVM (Java Vitual Machine) usa a arquitetura de pilha

Utizando o exemplo c = a + b, teriamos:push a push b add store c

25

Visão geral da arquitetura

26

Ambiente gráfico

27

Aplicações

28

Ferramentas

29

Jogos

30

Plug-in