Conteúdo Sistemas Distribuídos Prof. Fernando Luís Dotti material baseado em slides dos Profs. Avelino Zorzo e Celso Costa Introdução Comunicação entre Processos Algoritmos Distribuídos Gerência do Processador Memória Compartilhada Distribuída Sistema de Arquivos Distribuídos Estudos de Casos Sistemas Distribuídos 2 Introdução INTRODUÇÃO Fatores Motivadores Avanços em microeletronica processadores rápidos, baratos Avanços em comunicações redes eficientes, confiáveis Relação preço/performance melhor usar múltiplos processadores interconectados Sistemas Distribuídos 3 Introdução Introdução Por que Sistemas Distribuídos Melhoria de tecnologias Metáfora ( Us$10M 1i/s > Us$1m 100Mi/s) Rolls Royce (Us$10 > 1B km/l) Redes de computadores de alta velocidade Conectar vários computadores para resolver um problema Problema:???? O que é um sistema distribuído? Um sistema distribuído é uma coleção de computadores independentes que parecem um sistema único para o usuário [Tanenbaum ]. Dois aspectos: Hardware: autonomia Software: sistema único Exemplos: Fábrica com robôs Banco e agências Sistemas Distribuídos 5 Sistemas Distribuídos 6 1
Introdução Introdução Vantagens de S.D. sobre S.C Vantagens de S.D. sobre S.C Economia Grosh s law : performance é proporcional ao custo 2 Mainframes Velocidade 10.000 CPUs x 50MIPS = 500.000 MIPS Uma CPU (??) para isto deve executa 1 instrução a cada 0.002 nanoseg (2 picoseg). (Velocidade da luz 0.6mm em 2 picoseg) Algumas aplicações são naturalmente distribuídas CSCW Confiabilidade (reliability) 5% for a do ar 5% em perda de performance Aviação, reatores nucleares, Expansão Aumentar poder de processamento sem se desfazer daquilo que já possui de maneira gradativa Sistemas Distribuídos 7 Sistemas Distribuídos 8 Introdução Introdução Vantagens de S.D. sobre PCs Desvantagens de S.D. Compartilhamento de dados Compartilhamento de periféricos Economia Comunicação Correio eletrônico Flexibilidade Melhor aproveitamento dos recursos Pouco software disponível Rede pode causar problemas Segurança Sistemas Distribuídos 9 Sistemas Distribuídos 10 Introdução Introdução Conteúdo histórico hardware classificações modelos de sistemas computacionais distribuídos (pradeep) terminologia considerações de projeto INTRODUÇÃO Histórico Sistemas Distribuídos 11 Sistemas Distribuídos 12 2
Introdução (histórico) Introdução (histórico) Computadores iniciais: Caros e grandes Anos 50 e 60: Spooling, multiprogramação otimizar utilização da CPU Início dos anos 60: Sistemas Time Sharing Sistemas Time Sharing Primeiro passo na direção dos Sistemas Distribuídos Incorpora dois conceitos fundamentais: Compartilhamento de recursos Acesso remoto Terminais passam a ter maior capacidade de processamento Tarefas principais/comuns em comp. principal Introdução (histórico) Introdução (histórico) Evolução do hardware: redução do tamanho, do preço, aumento da velocidade Comunicação: velocidades e distâncias maiores, maior confiabilidade Final dos anos 60 e início dos anos 70: Surgimento das redes Ethernet Xerox Palo Alto: 73 LAN ARPANet DoD: 69 WAN final dos anos 70: Protocolo TCP/IP Introdução (histórico) Final dos anos 60 e início dos anos 70: Unix Início dos anos 80: Estações de trabalho INTRODUÇÃO Hardware Sistemas Distribuídos 18 3
Introdução (hardware) Introdução (hardware) Taxonomia de hardware (Flynn 1972) SISD: single instruction single data computadores com um processador SIMD: single instruction multiple data array de processadores (alguns supercomputadores) MISD: multiple instruction single data não existe (?) MIMD: multiple instruction multiple data sistemas distribuídos estão nesta categoria, ou um conjunto de computadores independentes, cada um com seu contador de programa, conjunto de instruções e dados Barramento Fortemente acoplado Multiprocessadores (memória compartilhada) parallel processing systems ( pradeep) Switched MIMD Computadores Paralelos e Distribuídos Barramento Sequent, Encore Ultracomputer, RP3 Estações de Trabalho Fracamente acoplado Multicomputadores (memória privada) distributed computing systems ( pradeep) Switched Transputer, hypercube Sistemas Distribuídos 19 Sistemas Distribuídos 20 Introdução (hardware) Introdução (hardware) Multiprocessadores baseado em barramento Multiprocessadores baseado em switch Memórias CPU cache CPU cache CPU cache Memória CPUs C C C C M M M crossbar switch M C M C M C M C M omega switching network Sistemas Distribuídos 21 Sistemas Distribuídos 22 Introdução (hardware) Introdução (hardware) Multicomputadores em barramento Multicomputadores com switch Estação de trabalho Estação de trabalho Estação de trabalho Memória Local CPU Memória Local CPU Rede Memória Local CPU grid hypercube Sistemas Distribuídos 23 Sistemas Distribuídos 24 4
Introdução (hardware) MIMD: Multiprocessadores UMA: Uniform Memory Access (memória central) NUMA: Non Uniform Memory Access (distribuída) COMA: cache only memory access CCNUMA: cache coherent NUMA NCCNUMA: non cache coherent Multicomputadores (memória privada) NORMA nonremote memory access hwang98 INTRODUÇÃO Modelos de Distributed Computing Systems MIMD/NORMA (Pradeep) Sistemas Distribuídos 26 Modelos de Distributed Computing Systems MIMD/NORMA (Pradeep) Modelo Rede de Minicomputadores Redes de Minicomputadores Redes de Estações de Trabalho Redes de Estações de Trabalho com Estações as (Modelo /) Pool de Processadores / com um Pool de Processadores Micro Computador Micro Computador Rede Micro Computador Micro Computador Modelo Rede de Minicomputadores Modelo Rede de Minicomputadores Extensão do modelo timesharing cada minicomputador tem usuários conectados via terminais interativos rede permite a usuário acessar recursos de outros minicomputadores ex.: ARPANet Objetivo: Compartilhamento de recursos Software Telnet Ftp Acesso remoto à bases de dados 5
Modelo Rede de Estações Modelo Rede de Estações Estação Estação Rede Estação Estação Objetivo Interconectar estações de maneira a otimizar o seu uso Cada estação possui seu próprio sistema operacional, seu próprio disco Usuário se conecta a uma estação O sistema distribui a carga de processamento na rede de estações (Distribuição de carga) Modelo Rede de Estações Modelo / Como achar estação livre? Como transferir processo para outra estação? O que fazer com um processo remoto em uma estação livre, se um usuário se loga na estação? Ex.: Sprite Xerox PARC Estação Estação a Rede Estação Estação Modelo / Modelo / Podem existir estações sem disco Estações servidoras oferecem os serviços (servidor de arquivos, servidor de impressão, servidor de Base de Dados) Usuário se conecta a uma estação O sistema implementa o acesso remoto (transparente) aos serviços EX.: NFS da Sun Serviço: funcionalidade provida por um ou mais máquinas servidoras cooperantes : máquina servidora responsável por um serviço ou parte dele 6
Modelo Pool de Processadores Modelo Pool de Processadores Rede Run Server P1 P2 P3 Pool de Processadores Os processadores são gerenciados globalmente Alocação de um grupo de processadores a um usuário Liberação do grupo de processadores ao término da execução EX.: Sistema Operacional Amoeba Modelo / com Pool de Processadores O modelo mais usado é o / Modelo Híbrido combina o / com o Pool de Processadores Aproxima os ambientes Distribuídos dos Paralelos INTRODUÇÃO Terminologia Sistemas Distribuídos 40 Introdução (terminologia) Introdução (terminologia) Sistema Operacional programa que controla os recursos de um computador e oferece ao usuário uma interface mais conveniente para o uso do que a máquina Em um Sistema Computacional Distribuído podemos utilizar um: Sistema Operacional de Rede Sistema Operacional Distribuído 7
Introdução (terminologia) Introdução (terminologia) Sistema Operacional de Rede visão do sistema não é única, usuário conhece as várias máquinas computadores funcionam de maneira autonoma não há cooperação das máquinas para toleância a falhas DCS com um NOS é dito um Networked System ou Sistema em Rede Sistema Operacional Distribuído um SOD parece aos seus usuários como um único sistema operacional, centralizado, mas rodando em diversas CPUs independentes. O conceito chave é transparência. O uso de múltiplos processadores deve ser transparente ao usuário. Máquinas não são autônomas tolerância a falhas um DCS com um DOS é dito um Distributed System ou True Distributed System Introdução (considerações de projeto) INTRODUÇÃO Considerações de Projeto de um SOD Principal fonte de complexidade: informação completa sobre o sistema não está disponível recursos separados fisicamente não existe relógio comum mensagens podem ser entregues com atraso (variante) mensagens podem ser perdidas(!) inexistência de informação uptodate consistente maior dificuldade/complexidade para realizar tarefas ex.: como escalonar processadores se não se sabe exatamente quais estão rodando e qual sua carga em determinado momento Sistemas Distribuídos 45 Sistemas Distribuídos 46 Introdução (considerações de projeto) Introdução (considerações de projeto) Objetivo usuários devem ver um sistema distribuído como um sistema centralizado virtual que é flexível, eficiente, confiável, seguro e fácil de usar (Pradeep ) Transparência de acesso usuário não distingue entre acesso a recurso local ou remoto interface do usuário conjunto de chamadas de sistema tem que ser projetadas para fazer sentido em sistemas centralizados ou distribuídos acessar recursos locais ou distantes facilidade de esquema de nomeação global de localização movimentação de recursos e usuários a vontade recursos mantém mesmo nome, nome independente de localização usuários acessam mesmos recursos a partir de qualquer nodo Sistemas Distribuídos 47 Sistemas Distribuídos 48 8
Introdução (considerações de projeto) Introdução (considerações de projeto) Transparência de replicação replicação: aumento de desempenho e confiabilidade gerência de réplicas: nomeação de réplicas, mapeamento de nome dado pelo usuário para réplica apropriada do recurso, etc. de falhas mascara dos usuários as falhas parciais do sistema continuidade do funcionamento, talvez de maneira degradada, em presença de falhas de migração razões: manter desempenho, confiabilidade e segurança escolha de objeto (processo) a migrar comunicação deve continuar de maneira transparente Transparência de concorrência competição por recursos necessidade de: ordenação de eventos exclusão mútua nostarvation no deadlock de desempenho reconfiguração da carga do sistema para aumentar desempenho facilidades de alocação de recursos e migração de processos para homogeneizar a carga dos nodos Sistemas Distribuídos 49 Sistemas Distribuídos 50 Introdução (considerações de projeto) Introdução (considerações) Transparência de crescimento/expansão permitir sistema ser estendido sem interromper atividades dos usuários Flexibilidade: kernel monolítico vs. Microkernel Kernel monolítico gerência de processos, memória, dispositivos, arquivos, nomes, e comunicação entre processos provida pelo kernel kernel grande modificação e adição de serviços dificultadas área de usuário kernel monolítico inclui gerenciamento de arquivos, diretório, processos,... Sistemas Distribuídos 51 Sistemas Distribuídos 52 Introdução (considerações) Introdução (considerações) Flexibilidade: kernel monolítico vs. Microkernel Kernel monolítico Núcleo usuário NÚCLEO MONOLÍTICO Tratador usuário Núcleo Flexibilidade: kernel monolítico vs. Microkernel Microkernel kernel pequeno, facilidades mínimas para implementar demais serviços do sistema Funções Básicas em cada nodo : Comunicação entre processos Gerência de memória (básica) Gerência de processos (básica) Operações de E/S de baixo nível Funções Comuns: es gerência de arquivos, nomes, gerência adicional de processos, etc. Modo usuário. área de usuário microkernel sistema de arquivos microkernel servidor de diretórios microkernel servidor de processos microkernel rede Sistemas Distribuídos 54 9
Introdução (considerações) Introdução (considerações) Flexibilidade: kernel monolítico vs. Microkernel Microkernel MICROKERNEL MICROKERNEL MICROKERNEL Confiabilidade (reliability) e.g. 4 servidores 95% probabilidade de os 4 estarem fora do ar = 0,000006 Outras considerações: perda de informações, segurança, tolerância a falhas, Performance Aplicação distribuída não deve ser mais lenta que aplicação centralizada comunicação: agrupar dados e outras informações para mandar através da rede minimizar tráfego (algoritmos distribuídos quanto se comunicam?) cache quando possível minimizar cópias de dados tirar vantagem de multiprocessamento Sistemas Distribuídos 55 Sistemas Distribuídos 56 Introdução (considerações) Escalabilidade (scalability) funciona para 200 funciona para 200.000?? Princípios a serem evitados: componentes centralizados tabelas centralizadas algoritmos centralizados Algoritmos distribuídos nenhum computador deve conter todas informações sobre o estado do sistema falha em um computador não deve prejudicar outro não assumir que exista relógio global COMUNICAÇÃO ENTRE PROCESSOS Sistemas Distribuídos 57 Sistemas Distribuídos 58 Comunicação entre processos Memória Compartilhada: os processo compartilham variáveis e trocam informações através do uso dessas variáveis compartilhadas Sem Memória Compartilhada: os processos compartilham informações através de troca de mensagens P1 Área Compartilhda o S.O é responsável pelo mecanismo de comunicação entre os processos P1 P2 P2 Aspectos importantes para um sistema de troca de mensagens Simplicidade: construção de novas aplicações para interoperar com já existentes deve ser facilitada Semântica Uniforme: comunicação local (processos no mesmo nodo) e comunicação remota (processos em nodos diferentes) através de funções tão próximas quanto possível (=s!) Eficiência: reduzir número de mensagens trocadas tanto quanto possível economizar fechamento e abertura de conexões; usar piggybacking ; etc. Confiabilidade: garantir entrega da mensagem confirmação, eliminação de duplicatas, ordenação Corretude : relacionada principalmente a comunicação em grupo garantia de aspectos como Atomicidade; Ordenação; Survivability Sistemas Distribuídos 59 Sistemas Distribuídos 60 10
Aspectos importantes para um sistema de troca de mensagens Flexibilidade: possibilidade de utilizar somente funcionalidade requerida (em prol de desempenho) necessidade ou não de entrega garantida, ordenada, atomica, etc Segurança: suporte a autenticação, privacidade Portabilidade: disponibilidade do mecanismo de IPC em plataformas heterogêneas Operações: send/receive características de sincronização: bloqueante, não bloqueante Send bloqueante: processo enviador fica bloqueado até recepção de confirmação do receptor problema: ficar bloqueado para sempre mecanismo de timeout Send nãobloqueante: processo enviador pode proceder assim que conteúdo (dados a enviar) for copiado para buffer de envio Sistemas Distribuídos 61 Sistemas Distribuídos 62 Operações: send/receive características de sincronização: bloqueante, não bloqueante Receive bloqueante: processo receptor fica bloqueando na operação de receive até chegada da mensagem problema: ficar bloqueado para sempre mecanismo de timeout Receive nãobloqueante: processo receptor informa ao núcleo onde armazenar mensagem e procede processo receptor fica sabendo da chegada da mensagem por: polling teste periódico interrupção variante: não bloqueante condicional receive retorna mensagem ou informação de que mensagem ainda não chegou Sistemas Distribuídos 63 Operações: send/receive características de sincronização: bloqueante, não bloqueante quando send e receive são bloqueantes a comunicação é dita síncrona senão é dita assíncrona Send(message ) execução suspensa Retoma execução Acknowledgement Receive (message) execução suspensa Retoma execução Send(acknowledgement ) Sistemas Distribuídos 64 Operações: send/receive característica: endereçamento implícito e explícito explícito: processo com o qual se quer comunicar é explicitamente identificado através de um parâmetro implícito: processo com o qual se quer comunicar não é identificado ex.: sender mandando para qualquer receiver que desempenhe uma função/serviço sender nomeia serviço ao invés de processo qualquer processo servidor (de um grupo) que desempenhe esta função pode receber a mensagem receiver quer receber independente do sender: modelo cliente/servidor servidor quer poder servir qualquer cliente Endereçamento explícito: o remetente identifica o recebedor o recebedor identifica o remetente / * task 0 * / main ( ) { send ( t1, m ); } / * task 1 * / main ( ) { receive ( t0, m ); } Sistemas Distribuídos 65 Sistemas Distribuídos 66 11
Endereçamento implícito do lado recebedor: remetente identifica o recebedor recebedor recebe de qualquer remetente / * task 0 * / main ( ) { send ( t2, m ); } / * task 1 * / main ( ) { send ( t2, m ); } / * task 2 * / main ( ) { receive ( 1, m ); } Operações: send/receive característica: identificação de processos machine_id@local_ id segunda parte usada localmente na máquina para achar processo e se processo move? machine_id, local_ id, machine _id nome de criação, máquina onde está a máquina onde o processo foi criado deve manter tabela dizendo onde processo se encontra máquinas que um processo visita tem que manter entrada dizendo a próxima máquina para onde o processo migrou; (ou só máquina origem?) overhead; mensagem alcançar destino pode depender de vários nodos (falhas?) Sistemas Distribuídos 67 Sistemas Distribuídos 68 Operações: send/receive característica: identificação de processos métodos não transparentes: especifica identificador de máquina identificador único do processo não deve ter embutida informação de localização do processo nomeação em dois níveis: nome de alto nível (string ) independente de localização nome de baixo nível: como machine_id@local_id servidor de nomes traduz de um para outro processos usam nomes de alto nível para endereçar outros processos durante o send o servidor de nomes é consultado para achar nome de baixo nível (localização) uso possível para endereçamento funcional: originador diz nome de serviço e servidor de nomes mapeia para servidor apropriado Sistemas Distribuídos 69 Operações: send/receive característica: bufferização transmissão da mensagem: copiar corpo da mensagem do espaço de endereçamento do processo enviador para espaço de endereçamento do receptor processo recebedor pode não estar pronto para receber SO salva mensagem (SO do lado receptor implementa bufferização) relação com o sincronismo da comunicação síncrona null buffer (um extremo) assíncrona buffer de capacidade ilimitada (outro extremo) tipos intermediários de buffers: singlemessage, finitebound or multiple message Sistemas Distribuídos 70 Operações: send/receive característica: bufferização null buffer não há espaço temporário para armazenar mensagem para comunicação síncrona estratégia 1: mensagem permanece no espaço de endereçamento do processo enviador, que fica bloqueado no send; quando receptor faz receive, uma mensagem de confirmação para o enviador é mandada, e o send pode enviar os dados estratégia 2: enviador manda a mensagem e espera confirmação, se processo receptor não está em receive, kernel descarta mensagem se processo receptor está em receice, manda confirmação se não há confirmação dentro de um tempo (timeout) é sinal de que receptor não estava em receive, e a mensagem é repetida Sistemas Distribuídos 71 Operações: send/receive característica: bufferização single message buffer para comunicação síncrona idéia: manter a mensagem pronta para uso no local de destino request message é bufferizada no nodo receptor, caso o processo receptor não esteja pronto para recepção buffer pode estar no espaço do kernel ou do usuário no caso do kernel, caminho da mensagem pode envolver 2 cópias Sistemas Distribuídos 72 12
Operações: send/receive característica: bufferização unboundedcapacity buffer para comunicação assíncrona enviador não espera receptor podem existir várias mensagens pendentes ainda não aceitas pelo receptor para garantir entrega de todas mensagens, um buffer ilimitado é necessário Operações: send/receive característica: bufferização finitebound buffer unbounded capacity buffer: impossível na prática estratégia necessária para buffer overflow comunicação sem sucesso: send retorna código de erro comunicação com controle de fluxo: o enviador fica bloqueado no send até que o receptor aceite alguma(s) mensagem(s); introduz sincronização entre originador e receptor possível deadlock send assíncrono não é assíncrono para todas mensagens Sistemas Distribuídos 73 Sistemas Distribuídos 74 Operações: send/receive característica: codificação e decodificação dos dados da mensagem mesagens entre processos rodando em diferentes arquiteturas bigendian transferência de valores de ponteiros para memória perdem significado identificação necessária para dizer tipo de dado sendo transmitido uso de formato comum de transferência (sintaxe de transferência) representação com tags (tagged): mensagem carrega tipo dos dados transferidos. Ex.: ASN.1 (abstract syntax notation CCITT); sistema operacional Mach representação sem tags: receptor tem que saber decodificar mensagem. Ex.: XDR (external Data Representation Sun); Courier (Xerox) Operações: send/receive característica: tratamento de falhas perda de mensagem de pedido Send request origem Request destino Sistemas Distribuídos 75 Sistemas Distribuídos 76 Operações: send/receive característica: tratamento de falhas perda de mensagem de resposta Operações: send/receive característica: tratamento de falhas execução do pedido no destinatário não tem sucesso Send request origem Request Response destino execução Send response Send request origem Request destino crash restarted Sistemas Distribuídos 77 Sistemas Distribuídos 78 13
Operações: send/receive característica: tratamento de falhas estratégias four message: confirmação das mensagens de pedido e resposta three message : confirmação da resposta two message: resposta é confirmação Operações: send/receive característica: tratamento de falhas estratégia four message: confirmação das mensagens de pedido e resposta origem destino bloqueia execução retoma execução Request Acknowledgement Reply Acknowledgement bloqueia execução retoma execução Sistemas Distribuídos 79 Sistemas Distribuídos 80 Operações: send/receive característica: tratamento de falhas estratégia three message : confirmação da resposta Operações: send/receive característica: tratamento de falhas estratégia two message: resposta é confirmação origem destino origem destino bloqueia execução retoma execução Request Reply Acknowledgement bloqueia execução retoma execução bloqueia execução retoma execução Request Reply Sistemas Distribuídos 81 Sistemas Distribuídos 82 Operações: send/receive característica: tratamento de falhas idempotência e tratamento de requests duplicados idempotência : repetibilidade operação idempotente pode ser repetida inúmeras vezes sem causar efeitos colaterais ao servidor ex.: gettime(), sqrt(x) ex.: conta.deposita(valor); conta.retira(valor) operações não idempotentes necessitam exactelyonce semantics garante que somente uma execução no servidor é realizada ex.: usar identificador único para cada request; lado servidor guarda reply cache para responder mesma resposta a pedido repetido Troca de mensagens: Mecanismos Arquivos (Unix pipes) Sockets RPC (Remote Procedure Call ) RMI (Remote Method Invocation) Java, DCOM, CORBA, Sistemas Distribuídos 83 Sistemas Distribuídos 84 14
Usando Unix pipes int main ( ) { int b [ 2 ] ; int p[2]; char m[128]; p = pipe(); /** cria o pipe para comunicação **/ id = fork () ; /** cria outro processo **/ if ( id!= 0) { /** código do processo pai **/ write ( p[0], message ); } else { /** código do processo filho **/ read( p[1], m ); print ( %s\n,m ); } } COMUNICAÇÃO ENTRE PROCESSOS Sockets Sistemas Distribuídos 85 Sistemas Distribuídos 86 Sockets Conceitos Básicos Conceitos Básicos Sockets são uma forma de IPC (InterProcess Communication ) fornecida pela 4.3 BSD que fornecem comunicação entre processos residentes em sistema único ou processos residentes em sistemas remotos. Sockets criados por diferentes programas usam nomes para se referenciar Esses nomes geralmente devem ser traduzidos em endereços para uso Um endereço é especificado por um domínio Sistemas Distribuídos 87 Sistemas Distribuídos 88 Processo Usuário Processo Usuário Processo Usuário Processo usuário SO IPC em um mesmo sistema SO Comunicação de Processos Remotos SO Sistemas Distribuídos 89 Sistemas Distribuídos 90 15
Tipos de Sockets Tipos de Sockets STREAM SOCKET Provê sequenciamento e fluxo bidirecinal. Este tipo de socket transmite dados sobre um base confiável e com capacidade de transmissão de dados expressos. No domínio UNIX, o SOCKET_STREAM trabalha igual a um pipe. No domínio INTERNET este tipo de socket é implementado sobre TCP/IP. SOCK_DGRAM Suporta fluxo de dados bidirecional mas não oferece um serviço confiável como STREAM_SOCKET. Mensagens duplicadas, perdidas, e em ordem diferente (não sequenciadas ) são problemas que podem aparecer neste tipo de socket. Sistemas Distribuídos 91 Sistemas Distribuídos 92 Tipos de Sockets Domínios e Protocolos RAW_SOCKET permite o acesso a interface de protocolos de rede. Disponível para usuários avançados e que possuam autoridade de usuário root permite que uma aplicação acesse diretamente protocolos de comunicação de baixo nível. permite a construção de novos protocolos sobre os protocolos de baixo nível já existentes normalmente orientados a datagrama O espaço no qual o endereço é especificado é chamado de domínio Domínios básicos: INTERNET AF_INET os endereços consistem do end. de rede da máquina e da identificação do no. da porta, o que permite a comunicação entre processos de sistemas diferentes Unix: AF_UNIX os processos se comunicam referenciando um pathname, dentro do espaço de nomes do sistema de arquivos Sistemas Distribuídos 93 Sistemas Distribuídos 94 Domínios e Protocolos Tipos de Sockets Domínio Internet Implementação Unix do protocolotcp/udp/ip Consiste de: end. de rede da máquina identificação do no. da porta Permite a comunicação entre máquinas diferentes Conexões sob a forma de sockets do tipo stream e do tipo datagramas Socket Stream conexões confiáveis Datagramas não fornecem segurança Sistemas Distribuídos 95 Sistemas Distribuídos 96 16
Protocolos TCP/IP IP Processo A Processo B TCP/UDP IP Interface hardware TCP/UDP Internetwork Protocol Roteamento de mensagens na rede Unidade: datagramas Fragmentação de pacotes (se > MTU) Entrega não confiável de pacotes Sistemas Distribuídos 97 Sistemas Distribuídos 98 TCP UDP Transmission Control Protocol Para comunicação longa (conexão) Confiável Transmissão de fluxo de dados: Não respeita limites de mensagens Baixo desempenho em comunicações curtas (?) Usos típicos: Login remoto Transferência de arquivo User Datagram Protocol Para comunicação curta (sem conexão) Não confiável Transmissão de pacotes: respeita limites de mensagens Pouco prático para comunicações longas (confiabilidade precisa ser programada) Usos típicos: RPC Broadcast Sistemas Distribuídos 99 Sistemas Distribuídos 100 Porta Associação Definida por Endereço para um processo comunicante Inteiro de 16 bits (definido pelo usuário) Portas 1 a 1023 são do sistema Portas de TCP independentes das de UDP Um protocolo: TCP ou UDP Endereço IP local Porta local Endereço IP distante Porta distante Sistemas Distribuídos 101 Sistemas Distribuídos 102 17
Comunicação por sockets Comunicação via TCP 1 Cria um socket com Família (ou domínio): UNIX, Internet, XNS Tipo: stream, datagrama, puro Protocolo (por conseq.): TCP, UDP kernel socket conexão socket kernel rede sockfd = (int) socket (int family, int type, int protocol) Sistemas Distribuídos 103 Sistemas Distribuídos 104 Comunicação via TCP Comunicação via TCP Atribui ao socket Endereço Internet (pode ser any ) Porta de comunicação Declara Que está pronto para receber conexões Até quantas devem ser enfileiradas ret = (int) bind (int sockfd, struct sockaddr *myaddr, int addrlen) listen ( ) ret = (int) listen (int sockfd, int backlog) Sistemas Distribuídos 105 Sistemas Distribuídos 106 Comunicação via TCP Comunicação via TCP listen ( ) accept ( ) Bloqueia até que haja pedido de conexão Quando houver algum, aceita newsock = (int) accept (int sockfd, struct sockaddr *peer, int *addrlen) listen ( ) accept ( ) Cria um socket idêntico ao do servidor (mesma família e tipo) sockfd = (int) socket (int family, int type, int protocol) Sistemas Distribuídos 107 Sistemas Distribuídos 108 18
Comunicação via TCP Comunicação via TCP listen ( ) accept ( ) Pede uma conexão ao servidor Fica bloqueado ou retorna erro Se aceito, fecha a conexão estabelecimento de conexão connect ( ) ret = (int) connect (int sockfd, struct sockaddr *servaddr, int addrlen) listen ( ) accept ( ) Envia uma seqüência de bytes pela conexão estabelecimento de conexão connect ( ) send ( ) nbytes = (int) send (int sockfd, char *buf, int nbytes, int flags) Sistemas Distribuídos 109 Sistemas Distribuídos 110 Comunicação via TCP Comunicação via TCP listen ( ) accept ( ) recv ( ) Recebe msg enviada por send ( ) estabelecimento de conexão solicitação connect ( ) send ( ) nbytes = (int) recv (int sockfd, char *buf, int nbytes, int flags) listen ( ) accept ( ) recv ( ) send ( ) processamento ret = (int) close (int sockfd) Transmite ou confirma msgs faltantes Encerra a conexão Fecha o socket estabelecimento de conexão solicitação resposta connect ( ) send ( ) recv ( ) close ( ) close ( ) Sistemas Distribuídos 111 Sistemas Distribuídos 112 Comunicação via TCP Comunicação via UDP Diagrama completo e servidor criam seus sockets Família = Internet, tipo = datagrama listen ( ) accept ( ) recv ( ) send ( ) processamento estabelecimento de conexão solicitação resposta connect ( ) send ( ) recv ( ) close ( ) close ( ) Sistemas Distribuídos 113 Sistemas Distribuídos 114 19
Comunicação via UDP Comunicação via UDP e servidor definem endereços Recebe pacote enviado do endereço informado Se não houver nada, bloqueia recvfrom ( ) nbytes = (int) recvfrom (int sockfd, char *buf, int nbytes, int flags, struct sockaddr *from, int *addrlen) Sistemas Distribuídos 115 Sistemas Distribuídos 116 Comunicação via UDP Comunicação via UDP Envia pacote para o endereço informado Diagrama completo recvfrom ( ) solicitação sendto ( ) nbytes = (int) recvfrom (int sockfd, char *buf, int nbytes, int flags, struct sockaddr *from, int *addrlen) recvfrom ( ) processamento solicitação sendto ( ) sendto ( ) resposta recvfrom ( ) close ( ) close ( ) Sistemas Distribuídos 117 Sistemas Distribuídos 118 Comunicação entre processos Comunicação entre processos Exercícios: classifique cada uma das primitivas de pipes e sockets com relação a modelo implícito e explicito de endereçamento a comunicação bloqueante e não bloqueante e a bufferização de mensagens Obs.: analise o maior número possível de opções oferecidas por estas interfaces usando PIPES, teste, com programas: uso bidirecional de um pipe (existe?); uso concorrente de um pipe; Exercícios: usando sockets em plataforma linux ou solaris, e comunicação no modo datagrama, implemente em linguagem C um mecanismo de comunicação com suporte a falhas, do tipo twomessage analise bem a interface de sockets para utilizar o máximo de sua funcionalidade implemente um servidor concorrente (trata vários clientes simultaneamente) de operações matemáticas utilizando pipes e depois sockets (tipo stream) os clientes mandam os operandos e a operação, ficam a espera do resultado, e voltam a sortear operandos para o próximo pedido o servidor calcula e manda o resultado devolta para os vários clientes modifique a implementação para trabalhar com sockets no modo datagrama, adicionando o mecanismo de confirmação da questão anterior Sistemas Distribuídos 119 Sistemas Distribuídos 120 20