Sistemas Distribuídos Anderson Biudes Guilherme Henrique

Apresentação em tema: "Sistemas Distribuídos Anderson Biudes Guilherme Henrique"— Transcrição da apresentação:

1 Sistemas Distribuídos Anderson Biudes Guilherme Henrique
INFERNO OS Sistemas Distribuídos Anderson Biudes Guilherme Henrique

2 Introdução O que é o inferno?
Sistema Operacional que fornece facilidades para o desenvolvimento e a execução de: Serviços Distribuídos Aplicações de Rede Desenvolvido por Lucent Technologies' Bell Labs

3 Alguns requisitos Sistemas pequenos Sistemas médios Sistemas maiores
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: Windows Unix (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 > /net/dns cat /net/dns

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 Em seguida, a comunicação com é 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 para Alocar memória, carregar módulos, criar processos Sincronizaçã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
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