Sistemas Operacionais Distribuídos e de Redes

Tamanho: px
Começar a partir da página:

Download "Sistemas Operacionais Distribuídos e de Redes"

Transcrição

1 Sistemas Operacionais Distribuídos e de Redes Notas de Aula /2 Profa. Patrícia Kayser Vargas 3 Comunicação em Sistemas Distribuídos 3.1 Troca de Mensagens Assunto que já foi abordado em Sistemas Operacionais II. Mensagem pode ser entendida como um objeto de dados cuja estrutura e aplicação são definidas pelas aplicações. A troca de mensagens é feita através de primitivas explícitas de comunicação: send(destino, msg) envio da mensagem msg para destino receive(origem, msg) recebimento da mensagem msg enviada por origem Essas primitivas podem ser classificadas do seguinte modo: Tabela 3.1 Classificações das primitivas de comunicação. Forma de comunicação Direta send: há indicação do processo receptor send(processo, msg) receive: há indicação do emissor receive(processo, msg) Forma de sincronização Síncrona ou bloqueante send: espera até que a mensagem seja recebida pelo receptor receive: aguarda até a mensagem estar disponível Indireta send: envio para uma porta ou mailbox sem conhecimento de qual será o receptor send(mailbox, msg) receive: obtenção da mensagem guardada no mailbox, possivelmente desconhecendo a identidade do processo emissor receive(mailbox, msg) Assíncrona ou não bloqueante send: envia mensagem, mas não espera até que seja recebido pelo receptor receive: se a mensagem estiver disponível, recebe a mensagem, caso contrário continua a processamento retornando uma indicação de que a mensagem não estava disponível Um sistema pode possuir diferentes combinações desses tipos de primitivas. Um sistema de comunicação é dito síncrono se ambas as primitivas, isto é, tanto send quanto receive, forem do tipo bloqueante. Por outro lado, um sistema de comunicação é dito assíncrono se pelo menos uma das primitivas for assíncrona. A principal desvantagem dessa abordagem é o baixo nível de abstração que permite apenas a modelagem de troca direta de informação entre processos.

2 3.2 Modelo Cliente/Servidor É um paradigma de programação que representa as interações entre os processos e as estruturas do sistema. Nesse tipo de paradigma existem dois tipos de processos: clientes: processos que requisitam serviços; es: processos que recebem requisições, realizam uma operação e retornam serviços Em um modelo cliente/, o processo cliente necessitando de um serviço (por exemplo ler dados de um arquivo) envia uma mensagem para o e espera pela mensagem de resposta. O processo, após realizar a tarefa requisitada, envia o resultado na forma de uma mensagem de resposta ao processo cliente. Note que os es apenas respondem as requisições dos clientes, e, tipicamente, não iniciam conversação com os clientes. A principal vantagem dessa abordagem é a simplicidade mas a implementação em princípio é menos eficiente do que na troca de mensagens pura. A figura (A) abaixo mostra como é a comunicação lógica: envio de requisição (mensagem request) e recebimento do resultado (mensagem reply). De fato, a implementação ocorre como na figura (B) onde a troca de mensagem é feita via do sistema operacional request request cliente cliente reply reply (A) Rede Rede Figura 3.1 (a) Visão lógica da comunicação cliente/; (b) Troca de mensagens que possibilita a comunicação cliente/. (B) cliente 1 request cliente 2... cliente n recurso Figura 3.2 Possibilidade de vários clientes acessarem um recurso de forma consistente e transparente através do uso de um. Também é possível termos um ambiente com múltiplos es. Esses es podem ser ditos replicados quando são várias instâncias do mesmo, e podem ser replicados por questões de desempenho, distribuição natural dos recursos ou por tolerância a falhas. Também é possível termos es hierárquicos, isto é, um que usa serviços de outros es. Nesse tipo de ambiente, as localizações e conversações entre es deveriam ser transparentes aos clientes Endereçamento No nível de usuário, tem-se a noção de um envio de requisição a um específico, mas para que um cliente envie mensagens para um ele deve conhecer o seu endereço. Deste modo, é preciso estabelecer um esquema de identificação única do processo :

3 Opção 1 um identificador único de processo quando na mesma máquina: com um único processo por máquina basta indicar o endereço da máquina pois o consegue determinar qual é o processo único. Isso não é uma abordagem viável, pois dificilmente teremos um único processo em uma máquina. Opção 2 endereçamento indicando o processo e a máquina: quando se permite mais de um processo por máquina, deve-se endereçar a mensagem a esse específico. Um esquema comum é o uso de um nome composto por duas partes. Por exemplo, ou indicaria o processo 4 na máquina 243. Assim, o da máquina cliente usa o número 243 para enviar a máquina correspondente e com o número 4 o remoto determina para qual a mensagem é endereçada. Nessa abordagem a identificação é incluída no código do cliente. Com isso evita-se o custo de coordenação global e evita-se ambigüidades entre processos com identificador idênticos mas em máquinas distintas. Entretanto, perde-se em transparência pois é preciso que o cliente conheça a localização física do. Isso pode causar problemas, como por exemplo, se um de banco de dados normalmente executa na máquina 243, no dia que ela for desligada para realizar manutenção, pode-se disponibilizar o serviço na máquina 177. Se um cliente estiver usando esse esquema fixo, apesar do serviço estar disponível, o cliente não poderá acessar o. Opção 3 processos escolhem endereços que são detectados por broadcast: Cada processo deve receber um endereço único que não envolva o número da sua máquina. Esse endereço pode ser atribuído de duas formas:! através de um alocador de endereços de processo centralizado, que mantém um contador e ao receber uma requisição incrementa esse contador e envia o valor. A principal desvantagem é a utilização de um componente centralizado que compromete a tolerância a falhas e a escalabilidade;! cada processo escolhe um valor aleatoriamente a partir de um espaço de endereçamento grande (por exemplo 64 bits) e portanto com pouca probabilidade de colisão. O emissor de uma requisição pode localizar para qual máquina enviar através do seguinte procedimento: (1) o emissor envia uma mensagem para todas as máquinas (broadcast) com um pacote especial de localização contendo o endereço do processo destino; (2) em cada máquina da rede o verifica se o processo está na sua máquina. Quem localizar envia mensagem indicando seu endereço na rede; (3) o emissor guarda essas informações para requisições futuras. Essa abordagem tem como vantagem ser transparente mas tem um custo da mensagem broadcast. Opção 4 uso de de nomes: nesse esquema os es são indicados por um identificador de alto nível (nome ASCII) que não inclui nem identificação da máquina nem do processo. Quando um cliente executa uma requisição a um pela primeira vez, uma mensagem especial é enviada para um de mapeamento ou de nomes solicitando o número da máquina onde o

4 cliente 1 2 cliente (A) 1 request to reply to (B) 1 broadcast 2 here I am 3 request 4 reply 3 4 cliente 1 2 Name server (C) 1 NS lookup 2 NS reply 3 request 4 reply Figura 3.3 Formas de endereçar o : (a) endereçamento indicando o processo e a máquina; (b) endereços detectados por broadcast; (c) uso de de nomes Primitivas confiáveis e não confiáveis Se as mensagens envolvidas na comunicação cliente/ forem assumidas como não confiável, recairá ao usuário a tarefa de controlar possíveis perdas de mensagem. Isso não é desejável uma vez que o objetivo é tornar o mais transparente possível para o usuário. É, portanto, desejável que o do SO se preocupe em verificar se as mensagens foram corretamente recebidas garantindo dessa forma uma comunicação confiável. A figura abaixo ilustra dois protocolos para garantir a confiabilidade através do uso de mensagens especiais do tipo acknowledgment. cliente request(1) reply (3) cliente request(1) reply (2) ack (2) ack (4) ack (3) (A) Figura 3.4 Uso de mensagens de acknowledgment para garantir comunicação confiável. Normalmente tem-se uma implementação mista, do seguinte modo:! quando a requisição chega no do, um temporizador é inicializado.! se o enviar a mensagem rápido o suficiente, a resposta funcionará como uma confirmação (ACK), senão, um ACK separado é enviado antes do envio da resposta. Nesse caso, a maior parte das requisições é completada com apenas duas mensagens, mas quando uma requisição complexa for requisitada, serão necessárias três mensagens. (B)

5 3.3 Chamada Remota de Procedimento (RPC) Chamada Remota de Procedimento (Remote Procedure Call RPC) permite que programas invoquem procedimentos ou funções localizados em outras máquinas como se ele estivesse localmente definido. No nível do programa, as informações são passadas do chamador para o procedimento chamado através de parâmetros e resultados são retornados através do resultado do procedimento. Deste modo, nenhuma mensagem ou entrada/saída é visível ao programador. Apesar de simples e elegante esse paradigma tem como problemas potenciais os seguintes pontos:! chamador e chamado executam em espaços de endereçamento distintos;! como fazer a passagem de parâmetros e resultados quando máquinas com arquiteturas distintas;! possibilidades de falhas Operação RPC Básica Inicialmente vamos revisar como é realizada uma chamada de procedimento convencional, isto é, em uma linguagem e máquina seqüenciais. Vamos supor a chamada em linguagem C count = read(fd, buffer, nbytes), sendo o primeiro argumento um descritor de arquivo, o segundo um array de caracteres e o último um inteiro. Teríamos nesse caso na pilha de ativação a seguinte seqüência de valores: Variáveis locais da função main SP Variáveis locais da função main Variáveis locais da função main SP nbytes buffer fd end retorno variáveis locais de read SP (a) antes chamada da função read (b) durante execução da função read (c) após chamada da função read Note que os parâmetros são empilhados de modo a que o primeiro argumento esteja no topo da pilha facilitando o acesso aos dados. A forma como esses parâmetros serão empilhados (tratados) define três tipos de passagens de parâmetros:! Chamada por valor (call-by-value): o valor do parâmetro é copiado para a pilha; o procedimento pode alterar o valor da forma que desejar que tal mudança não será refletida na variável original após o retorno da função;! Chamada por referência (call-by-reference): o endereço do parâmetro é copiado para a pilha; quando o procedimento alterar uma variável, esse valor será mantido no retorno da chamada uma vez que a alteração é feita diretamente na variável original;! Chamada por cópia e restauração (call-by-copy/restore): a variável é copiada para a pilha (como se fosse em uma chamada por valor) e no retorno da chamada o valor alterado sobrescreve o valor original (como se fosse uma chamada por referência)

6 Note que a chamada por cópia e restauração normalmente atinge o mesmo efeito da chamada por referência. Porém, em algumas situações a semântica não é a mesma, como, por exemplo, quando uma mesma variável for passada como mais de um parâmetro. No caso das implementações RPC, via de regra usa-se chamada por valor ou por cópia e restauração. Como um dos princípios do RPC é tornar a chamada de um procedimento remoto parecer o máximo possível com uma chamada local. Por isso, utiliza-se a estrutura de clientes e es stubs. Máquina Cliente Máquina Servidora call Cliente 1 unpack pack 5 parameter call parameters Stub Stub Servidor Cliente 2 4 Servidor KERNEL 3 KERNEL Máquina Cliente Máquina Servidora call Cliente return 1 unpack pack 5 parameter call parameters Stub Stub Servidor Cliente 2 4 Servidor 10 unpack pack 6 return results results KERNEL KERNEL Figura 3.5 Passos realizados para executar uma chamada remota. Conforme ilustrado na figura acima, uma chamada remota de procedimentos segue os seguintes passos: 1. O procedimento remoto chama o stub cliente da forma normal, isto é, como se fosse um procedimento local qualquer; 2. O stub cliente constrói a mensagem e passa ao ; 3. O envia a mensagem ao remoto; 4. O remoto entrega a mensagem ao stub ; 5. O stub desempacota os parâmetros e chama o ; 6. O realiza o trabalho solicitado e envia o resultado ao stub ; 7. O stub empacota o resultado em uma mensagem e passa para o ; 8. O remoto envia mensagem ao cliente; 9. O do cliente entrega a mensagem ao stub cliente; 10. O stub desempacota o resultado e retorna ao cliente.

7 O efeito da execução de todos esses passos é a conversão da chamada local de um cliente a um stub cliente em uma chamada ao procedimento sem que o cliente ou o percebam os passos intermediários. Via de regra os stubs são gerados automaticamente por um compilador. Essa operação básica do RPC indica alguns aspectos e problemas interessantes que serão tratados nas próximas seções. (a) Passagem de Parâmetros É preciso tratar a passagem de parâmetros e a conversão de dados. Isso é feito pela operação de empacotamento de parâmetros (parameter marshalling). Essa operação trata problemas de representação distinta de dados (números/caracteres) para máquinas heterogêneas;. Tanto o cliente quanto o sabem os tipos de parâmetros passados (identificador do procedimento + parâmetros) e devem conseguir obter a representação correta dos dados. Alternativa 1: uso de um padrão de representação de dados, como por exemplo o XDR do RPC Unix. Essa alternativa é muito interessante por permitir a comunicação entre máquinas heterogêneas. A desvantagem é que entre máquinas homogêneas não haveria a necessidade de incluir um custo adicional de conversão da representação da máquina para a representação do padrão. Alternativa 2: a mensagem é enviada no formato nativo com indicação de qual o formato utilizado. O receptor deve fazer a conversão quando for o caso. Essa alternativa evita custos de conversão em ambientes homogêneos, entretanto exige que clientes e es saibam converter qualquer formato para a sua representação nativa. (b) Passagem de Ponteiros Um ponteiro representa um endereço de memória que não tem nenhum significado na máquina remota. Alternativa 1: proibir a passagem de ponteiros. Essa obviamente não é uma alternativa desejável pelo programador; Alternativa 2: Copiar o valor apontado pela variável ponteiro. As alterações são feitas remotamente e no retorno as alterações são atualizadas no chamador (semântica cópia/restauração). Uma otimização possível consiste em, sabendo que um determinado parâmetro é apenas de entrada, evitar o retorno do conteúdo do ponteiro. De forma análoga, se ele for apenas de saída, ele não precisa ser copiado no envio. Esse tipo de informação pode ser fornecido pelo programador ou extraído a partir da análise do código fonte (análise estática). (c) Semântica RPC na Presença de Falhas Na execução de uma chamada remota de procedimento, existem cinco classes diferentes de falhas possíveis. 1. O cliente não consegue localizar o Tal situação pode ocorrer devido a dois motivos: ou o caiu ou o cliente e o estão executando versões incompatíveis de protocolo impedindo a sua comunicação. A melhor forma de tratar tal erro é através do uso no programa de tratamento de exceções. Uma exceção é um procedimento especial que é invocado pelo sistema no caso de uma falha (exceção) ser detectada. Esse tipo de solução torna o código mais claro e fácil de dar manutenção do que o uso de um código de retorno de função. O principal problema é que nem todas as linguagens prevêem o tratamento de exceção. Além disso, a inclusão de tratamento de exceção acaba com a ilusão de que procedimentos remotos não diferem dos locais.

8 2. Mensagem de requisição perdida: A mensagem de requisição do cliente para o pode ser perdida. O do Sistema Operacional deve controlar, através de timeout e ao detectar a perda, reenviar a mensagem. 3. A mensagem de resposta perdida: A mensagem de resposta do para o cliente pode ser perdida e nesse caso é um pouco mais difícil de tratar. Com o uso de timeout o do cliente não pode determinar o porquê da ausência de resposta: a mensagem de resposta pode ter sido perdida, ou a mensagem de requisição foi perdida ou então se tem apenas um muito lento. O reenvio de requisição pode causar erros caso o procedimento remoto não seja idempotente. Um procedimento idempotente (idempotent) é aquele cuja execução não causa efeito colateral. Por exemplo, ler um determinado bloco de um arquivo. Para resolver esse impasse, pode-se numerar as requisições o que permite que o identifique e possivelmente ignore uma retransmissão. 4. O cai após receber uma requisição: Esse tipo de falha também está relacionado a semântica idempotente ou não idempotente de um procedimento. requisição Servidor requisição Servidor requisição Servidor receive execute reply receive execute crash receive crash resposta não há resposta não há resposta (a) (b) (c) Figura 3.6 (a) execução normal no ; (b) falha no após a requisição ter sido realizada; (c) falha no após receber requisição, mas antes de iniciar execução. Note que na figura acima temos dois pontos onde pode ocorrer falha no após a requisição ter sido recebida. No caso (b) houve a execução da requisição, mas o resultado não será enviado ao cliente, enquanto no caso (c) a requisição não chegou a ser processada. Logo, no caso (b) a requisição somente poderá ser reexecutada se o procedimento for idempotente, enquanto no caso (c) a reexecução seria permitida sem restrições. As implementações de RPC tratam a possibilidade de falha do através da definição de uma das três possíveis semânticas de execução de procedimento remoto:! pelo menos uma vez (at least once semantics): o procedimento vai ser executado pelo menos uma vez, mas possivelmente mais de uma vez (o cliente espera que o volte a funcionar enviando nova requisição);! no máximo uma vez (at most once semantics): o procedimento será executado uma única vez ou nenhuma (no caso de erro, o cliente desiste e reporta erro)! exatamente uma vez (exactly once semantics): garante a execução do procedimento uma única vez. Teoricamente seria a melhor semântica, porém difícil de implementar. 5. O cliente falha após enviar uma requisição (falha do cliente):

9 No caso de falha do cliente, a computação estará ativa no não existirá nenhum processo aguardando o resultado, resultando em um processo ou computação órfã. Esse tipo de computação causa basicamente dois tipos de problemas: - desperdício de CPU, e - processo cliente ao retornar pode receber uma mensagem não esperada do processo órfão. [TAN 95] apresenta as seguintes soluções possíveis: solução 1 exterminação (extermination): o cliente mantém log das requisições. Quando falhar, ao reiniciar, elimina todos os processos órfãos. Como desvantagens tem-se o gasto para escrita em disco e o fato de não funcionar quando houver partição na rede. solução 2 reencarnação (reincarnation): quando o cliente reiniciar, envia mensagem broadcast declarando o início de uma nova época. Com isso computações remotas serão finalizadas. solução 3 reencarnação gentil (gentle reincarnation): idem solução 2, porém somente mata as requisições remotas quando o não estiver ativo. solução 4 expiração (expiration): O tem um tempo T para executar, se precisar de mais tempo tem que enviar requisição Questões de Implementação As questões de implementação a serem analisadas nessa seção estão intimamente direcionadas ao ganho de desempenho. (a) Protocolo Em princípio qualquer mecanismo de troca de mensagens poderia dar suporte a implementação de RPC. Uma das questões a serem decididas na implementação é se o protocolo será orienta a conexão ou sem conexão. No primeiro caso, evita-se o problema de mensagens perdidas pois isso é tratado em baixo nível, porém, o desempenho é menor. No segundo caso, o desempenho é melhor, sendo indicado para implementações em LANs que são mais confiáveis do que WAMs. (b) Confirmação (Acknowledgements) O uso de mensagens de confirmação é usado para detecção de falhas. No momento de implementar, é preciso decidir se os pacotes serão confirmados individualmente ou não. Assim temos dois tipos de protocolos: stop-and-wait (no momento em que um pacote for danificado ou perdido, o cliente não recebendo o ACK providencia o reenvio), e blast (o envia mensagem ACK apenas ao final). stop-and-wait ACK 0 ACK 1 ACK 2 ACK 3 blast protocol ACK 0-3 Figura 3.7 Protocolos stop-and-wait e blast. No caso do blast protocol, existe duas formas de tratar o fato de apenas alguns pacotes terem sido entregues e outros não. Uma hipótese é ignorar todos os pacotes e solicitar a retransmissão de todos os pacotes. Outra possibilidade é realizar uma repetição seletiva, onde os pacotes recebidos são armazenados em um buffer, e solicitar ao cliente o reenvio específico dos pacotes. A segunda alternativa requer maior administração porém gasta menos banda no canal da rede de comunicação

10 Como a perda de pacotes em LANs é muito rara, a repetição seletiva (selective repeat) não compensa devido ao custo de controle envolvido. Outro problema refere-se ao fato dos buffers de recepção serem limitados. O envio de várias mensagens consecutivas pode causar um overrun error. O overrun error caracteriza-se pela incapacidade do receptor receber um pacote que chega corretamente causando dessa forma uma perda de mensagem. Na prática esse é um erro mais sério do que a perda por ruído ou outros problemas físicos na rede. Com o uso de stop-and-wait em princípio esse erro não ocorre pois uma mensagem é enviada de cada vez. No entanto ele poderia ocorrer caso diferentes emissores enviarem várias mensagens ao mesmo tempo.

11 3.4 Comunicação de grupo [TAN 95][TAN 92] Existem várias aplicações para as quais tem-se comunicação com múltiplos processos (comunicação em grupo ou multicast). Por exemplo, grupo de es de arquivos que fornecem serviço de arquivos tolerante a falhas. Um processo pode enviar mensagem para um grupo de es sem saber quantos eles são ou onde se localizam, sendo que tais parâmetros que podem mudar na próxima chamada. Um grupo é uma coleção de processos que agem juntos. Quando uma mensagem é enviada ao grupo, todos os membros recebem a mesma mensagem. Grupos são dinâmicos (analogia a grupos sociais): podem ser criados e destruídos; processos podem entrar ou abandonar o grupo; e um mesmo processo pode pertencer a mais de um grupo Questões de Projeto! grupos fechados (closed) x grupos abertos (open) essa diferenciação é definida em função de quem pode ou não se comunicar com os elementos do grupo. Grupo fechado: Apenas os membros do grupo podem mandar mensagem para o grupo; processos fora do grupo não podem enviar mensagens ao grupo como um todo, apenas aos membros individualmente. Tipicamente essa abordagem é usada em processamento paralelo. Grupo aberto: Qualquer processo no sistema pode enviar mensagem para o grupo. Tipicamente usado para elementos replicados como por exemplo um grupo de es.! grupos igualitários (peer) e hierárquicos essa classificação indica a estrutura interna do grupo. Grupo igualitário: Todos os processos são iguais e as decisões são tomadas coletivamente. Como vantagens temos um grupo simétrico e uma ausência de ponto único de falhas. Por outro lado, a tomada de decisão é bem mais complexa. Grupo hierárquico: Existe algum tipo de hierarquia entre os membros; a organização mais simples consiste em um processo coordenador e outros processos denominados trabalhadores; quando uma requisição (externa ou interna) é feita, o coordenador decide qual trabalhador é o mais apropriado para realizar a tarefa, ou define que todos devem realizar a requisição. Quando a hierarquia for do tipo coordenador-trabalhadores temos no coordenador ao mesmo tempo um ponto de falha e uma simplificação da tomada de decisão.! Controle dos Membros do Grupo (group membership) Como grupos são dinâmicos, é preciso realizar de alguma forma o controle de quais são os membros do grupo, bem como permitir a inclusão e exclusão de membros. As duas principais formas de fazer essa gerência é através de um (implementação centralizada) ou de uma forma distribuída. Servidor de Grupo (group server): com a presença de um de grupo, todas as requisições devem ser feitas a ele. O deve manter uma base de dados completa de todos os grupos e seu conjunto exato de membros. Vantagens: eficiente; direto; fácil de implementar. Desvantagem: ponto único de falha. Controle de forma distribuída: cada novo membro deve enviar mensagem a todos os membros atuais anunciando a sua presença. Da mesma forma temos que ao sair um membro deve avisar a todos os membros para que as mensagens do grupo não sejam mais direcionadas a ele. Esse tipo

12 de gerência facilita uma implementação tolerante a falhas. Além disso, note que a entrada e a saída do grupo deve ser sincronizada com a troca de mensagens para que ao entrar um membro receba todas as mensagens. Controle de falhas: a falha de um membro isolado equivale a esse membro sair do grupo. A diferença é que nesse caso não há "anúncio" dessa saída. Os demais membros do grupo devem perceber que um membro não está mais respondendo e por isso não faz mais parte do grupo. No caso de uma organização hierárquica, pode ser necessário reestruturar a organização do grupo. Além disso, caso haja muitos membros falhando (máquinas e/ou processos) o grupo pode ser inviabilizado pelo pouco número de elementos, forçando a execução de um algoritmo de reconstrução de grupo.! Endereçamento do Grupo Para realizar efetivamente a comunicação em grupo é preciso ter uma forma de indicar qual o grupo com o qual deseja-se enviar a mensagem. Esse endereçamento deve ser análogo ao endereçamento de processos devendo ser um identificador único no nível do usuário. Para implementar a comunicação em grupo existem basicamente três formas de implementação, que são dependentes de suporte de hardware: multicast, broadcast e unicast (ponto a ponto). Considere por exemplo a figura abaixo onde o processo 0 deseja enviar a mensagem ao grupo formado pelos processos 1, 3 e 4. Note que multicast é baseado na possibilidade de criar endereços especiais para os quais um conjunto de máquinas selecionadas podem receber. Já o broadcast envia a mensagem a todas as máquinas e fica a cargo do descartar as mensagens que não são endereçadas a uma determinada máquina (no exemplo, a máquina 2 descarta a mensagem). Finalmente, caso não haja suporte para comunicação em grupo ou broadcast, o sistema deve enviar as mensagens usando um pacote separado para cada membro do grupo (mensagens ponto a ponto) (a) multicast * * descarta a msg (b) broadcast (c) unicast Ainda com relação a endereçamento, existe a possibilidade de endereça o grupo usando predicados (expressão booleana). Esse endereçamento, denominado predicate addressing, permite que somente quando o predicado for avaliado com verdadeiro o membro irá receber e avaliar a mensagem.

13 ! Primitivas de comunicação com o grupo O envio de mensagens para grupos não pode ser modelado como uma chamada remota de procedimento (RPC) ou pelo menos fica bem mais difícil em termos semânticos. Normalmente a comunicação é modelada como primitivas send e receive. Assim como na troca de mensagens normais, pode-se ter os seguintes tipos de "configuração" para o send: bloqueante x não bloqueante com buffer x sem buffer confiável x não confiável Essas características costumam ser definidas pelo projetista do sistema e o usuário não tem como interferir. Para implementar em essas rotinas, pode-se usar send/receive utilizando ao invés de um identificador de processo a identificação do grupo ou usar primitivas distintas como send_group/receive_group que explicitam a existência de comunicação em grupo.! Atomicidade A atomicidade ou broadcast atômico garante a propriedade de tudo ou nada na entrega da mensagem ao grupo simplificando a programação distribuída de certas classes de aplicações, como por exemplo, bancos de dados distribuídos. De fato existem dois cenários de aplicações com comunicação em grupo: o cliente solicita um serviço o qual qualquer um dos es pode realizar ou o cliente solicita um serviço para todos os membros. No primeiro caso, o sistema deve garantir a entrega a todos os membros do grupo que não falharam caracterizando uma comunicação do tipo melhor esforço (best-effort multicast). No segundo caso, a mensagem deve ser entregue a todos os membros do grupo ou a nenhum caracterizando uma comunicação confiável (reliable multicast). Além dessa classificação, pode-se estabelecer três semânticas de ordenação: - ordem de chegada (FIFO order): mensagens enviadas ao grupo a partir de uma fonte são entregues na ordem em que foram enviadas por essa fonte; - ordem causal (causal order): mensagens com relacionamento causa-efeito das diversas fontes são entregues na ordem causal; - ordem total (total order): todas as mensagens são entregues para todos os membros do grupo na mesma ordem. Segundo alguns autores, uma comunicação atômica (atomic multicast) pode ser descrita por uma comunicação confiável que garante a semântica de ordenação total [CHO 97]. Ordenamento de mensagens Quando dois processos estão disputando o acesso à rede local, a ordem na qual as mensagens serão enviadas é não determinística. Por isso, pode-se utilizar algoritmos que garantam a ordenação com tempo global, com a entrega de todas as mensagens na ordem exata em que foram enviadas, o que é muito difícil de ser implementado, ou uma ordenação com tempo consistente, onde a mensagem chega a todos os membros do grupo na mesma ordem que pode ou não ser a ordem real de envio. Considere a figura abaixo:

14 Note que o processo 0 envia as mensagens, respectivamente para os processos 1, 3 e 4 enquanto o processo 4 envia, respectivamente, para os processos 0,1 e 3. Note que teremos uma inconsistência no recebimento das mensagens uma vez que o processo 1 receberá primeiro a mensagem do processo 0 e depois do 4 enquanto o processo 3 receberá primeiro do 4 e depois do 0. Isso pode ser um problema em certos tipos de aplicações como por exemplo banco de dados replicados. Uma possibilidade de resolver isso é através do uso de um algoritmo de ordenamento causal como o apresentado abaixo: S = (S1, S2,..., Sn) // vetor local onde // Sk é o número da última mensagem recebida de k T = (T1, T2,..., Tn) // vetor de seqüência incluído na mensagem Quando é recebida uma mensagem m de i para j Se (Ti = Si+1) e (Tk Sk para todo k i) j aceita a mensagem m Se (Ti > Si+1) ou ( k i tal que Tk>Sk) j aguarda para processar m Se (Ti Sj) j rejeita a mensagem m A primeira verificação inclui duas condições para que a mensagem seja aceita: j está esperando a mensagem de i (Ti = Si+1) e j lá recebeu todas as mensagens que precedem m (ordem casual). Caso alguma mensagem de i ainda não tenha sido recebida (Ti > Si+1) ou i recebeu mais mensagens multicast do que j ( k i tal que Tk>Sk), irá precisar aguardar até processar a mensagem. Finalmente, mensagens duplicadas (Ti Sj) são descartadas. Note que esse algoritmo irá funcionar apenas para grupos fechados. 4 Referências Bibliográficas [CHO 97] CHOW, R.; JOHNSON, T. Distributed Operating Systems & Algorithms. Addison-Wesley, [SIL 99] SILBERSCHATZ et al. Operating System Concepts. John Willey, [TAN 92] TANENBAUM, A. S. Modern Operating Systems. Prentice Hall, [TAN 95] TANENBAUM, A. S. Distributed Operating Systems. Prentice Hall, [DSM] DSM Tutorial.

15

3. Comunicação em Sistemas Distribuídos

3. Comunicação em Sistemas Distribuídos 3. Comunicação em 3.1.Troca de mensagens As mensagens são objetos de dados cuja estrutura e aplicação são definidas pelas próprias aplicações que a usarão. Sendo a troca de mensagens feita através de primitivas

Leia mais

Sistemas distribuídos:comunicação

Sistemas distribuídos:comunicação M. G. Santos marcela@estacio.edu.br Faculdade Câmara Cascudo - Estácio de Sá 16 de abril de 2010 Formas de comunicação Produtor-consumidor: comunicação uni-direccional, com o produtor entregando ao consumidor.

Leia mais

Sistemas Distribuídos RPC

Sistemas Distribuídos RPC Sistemas Distribuídos RPC Disciplina: Sistemas Distribuídos Prof.: Edmar Roberto Santana de Rezende Faculdade de Engenharia de Computação Centro de Ciências Exatas, Ambientais e de Tecnologias Pontifícia

Leia mais

Sistemas Distribuídos RPC x RMI. Edeyson Andrade Gomes www.edeyson.com.br

Sistemas Distribuídos RPC x RMI. Edeyson Andrade Gomes www.edeyson.com.br Sistemas Distribuídos RPC x RMI Edeyson Andrade Gomes www.edeyson.com.br Roteiro da Aula Chamada Remota a Procedimento Definição Passagem de Parâmetros STUBS Semântica de Falhas 2 RPC Chamada Remota a

Leia mais

Comunicação. Parte II

Comunicação. Parte II Comunicação Parte II Carlos Ferraz 2002 Tópicos Comunicação Cliente-Servidor RPC Comunicação de objetos distribuídos Comunicação em Grupo Transações Atômicas Comunicação Stream 2 Comunicação cliente-servidor

Leia mais

SISTEMAS DISTRIBUÍDOS

SISTEMAS DISTRIBUÍDOS SISTEMAS DISTRIBUÍDOS CUP Disk Memoey CUP Memoey Disk Network CUP Memoey Disk Comunicação em Sistemas Distribuídos Sumário Modelo Cliente e Servidor Troca de Mensagens Remote Procedure Call Comunicação

Leia mais

Sistemas Distribuídos Grupos

Sistemas Distribuídos Grupos Sistemas Distribuídos Grupos Edeyson Andrade Gomes www.edeyson.com.br Roteiro da Aula Roteiro da Aula Definição de Grupos Tipos Atomicidade Ordenamento 3 RPC Comunicação entre Pares Cliente - Servidor

Leia mais

Comunicação entre processos (grupos) COMUNICAÇÃO ENTRE PROCESSOS Comunicação de grupo. Comunicação entre processos (grupos)

Comunicação entre processos (grupos) COMUNICAÇÃO ENTRE PROCESSOS Comunicação de grupo. Comunicação entre processos (grupos) Comunicação one-to-one Forma mais simples de comunicação entre processos point-to-point, ou unicast COMUNICAÇÃO ENTRE PROCESSOS Comunicação de grupo Algumas aplicações comunicação entre grupos de processos

Leia mais

Tópicos em Sistemas Distribuídos. Modelos de Comunicação

Tópicos em Sistemas Distribuídos. Modelos de Comunicação Tópicos em Sistemas Distribuídos Modelos de Comunicação Comunicação em SD Comunicação entre processos Sockets UDP/TCP Comunicação em grupo Broadcast Multicast Comunicação entre processos Conceitos básicos

Leia mais

Sistemas Distribuídos Aula 15

Sistemas Distribuídos Aula 15 Sistemas Distribuídos Aula 15 Msc. Daniele Carvalho Oliveira Doutoranda em Ciência da Computação - UFU Mestre em Ciência da Computação UFU Bacharel em Ciência da Computação - UFJF 8. Tolerância a Falha

Leia mais

Sistemas Distribuídos. Professora: Ana Paula Couto DCC 064

Sistemas Distribuídos. Professora: Ana Paula Couto DCC 064 Sistemas Distribuídos Professora: Ana Paula Couto DCC 064 Comunicação- Protocolos, Tipos, RPC Capítulo 4 Agenda Protocolos em Camadas Pilhas de Protocolos em Sistemas Distribuídos Tipos de Comunicação

Leia mais

UNIVERSIDADE. Sistemas Distribuídos

UNIVERSIDADE. Sistemas Distribuídos UNIVERSIDADE Sistemas Distribuídos Ciência da Computação Prof. Jesus José de Oliveira Neto Comunicação Inter-Processos Sockets e Portas Introdução Sistemas distribuídos consistem da comunicação entre processos

Leia mais

Sistemas Distribuídos. Professora: Ana Paula Couto DCC 064

Sistemas Distribuídos. Professora: Ana Paula Couto DCC 064 Sistemas Distribuídos Professora: Ana Paula Couto DCC 064 Resiliência de Processos Comunicação Confiável Cliente-Servidor Capítulo 8 Resiliência de Processos Idéia Básica: Replicar processos em grupos,

Leia mais

Sistemas Distribuídos Comunicação entre Processos em Sistemas Distribuídos: Middleware de comunicação Aula II Prof. Rosemary Silveira F. Melo Comunicação em sistemas distribuídos é um ponto fundamental

Leia mais

Grupos de Processos (Comunicação Grupal)

Grupos de Processos (Comunicação Grupal) Grupos de Processos (Comunicação Grupal) Roteiro Definição de Grupos Tipos (organização) de grupos Atomicidade Ordenação de mensagens 2 RPC Comunicação entre Pares (duas partes) Cliente - Servidor Comunicação

Leia mais

SISTEMAS DISTRIBUÍDOS

SISTEMAS DISTRIBUÍDOS SISTEMAS DISTRIBUÍDOS Modelo cliente e servidor Slide 2 Nielsen C. Damasceno Modelos Cliente - Servidor A principal diferença entre um sistema centralizado e um sistema distribuído está na comunicação

Leia mais

Comunicação em Sistemas Distribuídos. Bruno M. Carvalho Sala: 3B2 Horário: 35T34

Comunicação em Sistemas Distribuídos. Bruno M. Carvalho Sala: 3B2 Horário: 35T34 Comunicação em Sistemas Distribuídos Bruno M. Carvalho Sala: 3B2 Horário: 35T34 Comunicação em Sistemas Distribuídos Protocolos regras que os processos que estão se comunicando tem de seguir Protocolos

Leia mais

Comunicação em Sistemas Distribuídos

Comunicação em Sistemas Distribuídos Comunicação em Sistemas Distribuídos A diferença mais importante entre os Sistemas Distribuídos e os Sistemas Uniprocessadores é a comunicação inter-processo. Nos uniprocessadores esta comunicação é feita

Leia mais

Prof. Luiz Fernando Bittencourt MC714. Sistemas Distribuídos 2 semestre, 2013

Prof. Luiz Fernando Bittencourt MC714. Sistemas Distribuídos 2 semestre, 2013 MC714 Sistemas Distribuídos 2 semestre, 2013 Tipos de comunicação Middleware: serviço intermediário na comunicação de nível de aplicação. Fig. 67 Ex.: correio eletrônico Comunicação é persistente. Middleware

Leia mais

Sistemas Distribuídos Modelo Cliente-Servidor

Sistemas Distribuídos Modelo Cliente-Servidor Sistemas Distribuídos Modelo Cliente-Servidor Disciplina: Sistemas Distribuídos Prof.: Edmar Roberto Santana de Rezende Faculdade de Engenharia de Computação Centro de Ciências Exatas, Ambientais e de

Leia mais

Prof. Marcos Ribeiro Quinet de Andrade Universidade Federal Fluminense - UFF Pólo Universitário de Rio das Ostras - PURO

Prof. Marcos Ribeiro Quinet de Andrade Universidade Federal Fluminense - UFF Pólo Universitário de Rio das Ostras - PURO Conceitos básicos e serviços do Sistema Operacional Prof. Marcos Ribeiro Quinet de Andrade Universidade Federal Fluminense - UFF Pólo Universitário de Rio das Ostras - PURO Tipos de serviço do S.O. O S.O.

Leia mais

Sistemas Distribuídos Comunicação. Edeyson Andrade Gomes www.edeyson.com.br

Sistemas Distribuídos Comunicação. Edeyson Andrade Gomes www.edeyson.com.br Sistemas Distribuídos Comunicação Edeyson Andrade Gomes www.edeyson.com.br Roteiro da Aula Roteiro da Aula Comunicação entre Processos Protocolos Modelo OSI Modelo Cliente Servidor 3 Comunicação entre

Leia mais

Sistemas Distribuídos. Ricardo Ribeiro dos Santos ricrs@ec.ucdb.br

Sistemas Distribuídos. Ricardo Ribeiro dos Santos ricrs@ec.ucdb.br Sistemas Distribuídos Ricardo Ribeiro dos Santos ricrs@ec.ucdb.br Curso de Engenharia de Computação UCDB Novembro/2003 Tópicos Tolerância a falhas em comunicação em grupo Tolerância a falhas em comunicação

Leia mais

Remote Procedure Call

Remote Procedure Call Remote Procedure Call O aumento de complexidade das aplicações, torna desejável um paradigma que permite software distribuído ser programado de maneira similar a aplicações convencionais que executam em

Leia mais

Notas da Aula 6 - Fundamentos de Sistemas Operacionais

Notas da Aula 6 - Fundamentos de Sistemas Operacionais 1. Monitores Notas da Aula 6 - Fundamentos de Sistemas Operacionais Embora os semáforos sejam uma boa solução para o problema da exclusão mútua, sua utilização não é trivial. O programador é obrigado a

Leia mais

Comunicação entre processos (grupos) COMUNICAÇÃO ENTRE PROCESSOS Comunicação de grupo. Comunicação entre processos (grupos)

Comunicação entre processos (grupos) COMUNICAÇÃO ENTRE PROCESSOS Comunicação de grupo. Comunicação entre processos (grupos) COMUNICAÇÃO ENTRE PROCESSOS Comunicação de grupo Comunicação one-to-one Forma mais simples de comunicação entre processos point -to-point, ou unicast Algumas aplicações requerem comunicação envolvendo

Leia mais

Sistemas Operacionais

Sistemas Operacionais UNIVERSIDADE BANDEIRANTE DE SÃO PAULO INSTITUTO POLITÉCNICO CURSO DE SISTEMAS DE INFORMAÇÃO Sistemas Operacionais Notas de Aulas: Tópicos 7 e 8 Estrutura do Sistema Operacional São Paulo 2009 1 Sumário

Leia mais

Sistemas Distribuídos 59. Sistemas Distribuídos 61. "Receive não-bloqueante:

Sistemas Distribuídos 59. Sistemas Distribuídos 61. Receive não-bloqueante: Comunicação entre processos! Memória Compartilhada: " os processo compartilham variáveis e trocam informações através do uso dessas variáveis compartilhadas COMUNICAÇÃO ENTRE PROCESSOS P1 Área Compartilhda!

Leia mais

Comunicação em Sistemas Distribuídos. Conceitos: Paradigma C/S. Conceitos: Paradigma C/S. Paradigma Cliente/Servidor

Comunicação em Sistemas Distribuídos. Conceitos: Paradigma C/S. Conceitos: Paradigma C/S. Paradigma Cliente/Servidor Comunicação em Sistemas Distribuídos Paradigma / Os processos em um SD estão lógica e fisicamente separados. Precisam se comunicar para que possam interagir O desempenho de um SD depende criticamente do

Leia mais

Programação distribuída e paralela (C. Geyer) RPC 1

Programação distribuída e paralela (C. Geyer) RPC 1 Programação distribuída e paralela (C. Geyer) RPC 1 Autores C. Geyer Local II-UFRGS Versão v6 2008-2 Disciplinas SOII Programação distribuída e paralela (C. Geyer) RPC 2 Bibliografia base original dos

Leia mais

Bancos de dados distribuídos Prof. Tiago Eugenio de Melo tiagodemelo@gmail.com. http://www.tiagodemelo.info

Bancos de dados distribuídos Prof. Tiago Eugenio de Melo tiagodemelo@gmail.com. http://www.tiagodemelo.info Bancos de dados distribuídos Prof. Tiago Eugenio de Melo tiagodemelo@gmail.com Última atualização: 20.03.2013 Conceitos Banco de dados distribuídos pode ser entendido como uma coleção de múltiplos bds

Leia mais

SISTEMAS OPERACIONAIS. Apostila 03 Estrutura do Sistema Operacional UNIBAN

SISTEMAS OPERACIONAIS. Apostila 03 Estrutura do Sistema Operacional UNIBAN SISTEMAS OPERACIONAIS Apostila 03 Estrutura do Sistema Operacional UNIBAN 1.0 O Sistema Operacional como uma Máquina Virtual A arquitetura (conjunto de instruções, organização de memória, E/S e estrutura

Leia mais

Nomes e Endereçamento. Nomes e Endereçamento. Paradigmas em Sistemas Distribuídos. Paradigmas em Sistemas Distribuídos

Nomes e Endereçamento. Nomes e Endereçamento. Paradigmas em Sistemas Distribuídos. Paradigmas em Sistemas Distribuídos Paradigmas em Sistemas Distribuídos Paradigmas em Sistemas Distribuídos Nomes e Endereçamento Troca de Mensagens Operações emota Comunicação em Grupo Time e Clocks Sincronismo Ordenação Coordenação Consistência

Leia mais

Remote Procedure Call. Programação distribuída e paralela (C. Geyer) RPC 1

Remote Procedure Call. Programação distribuída e paralela (C. Geyer) RPC 1 Remote Procedure Call Programação distribuída e paralela (C. Geyer) RPC 1 Autoria Autores C. Geyer Local II-UFRGS Versão V11.4 2014-2 Disciplinas SOII Programação distribuída e paralela (C. Geyer) RPC

Leia mais

SISTEMAS DISTRIBUÍDOS

SISTEMAS DISTRIBUÍDOS SISTEMAS DISTRIBUÍDOS Comunicação coletiva Modelo Peer-to-Peer Slide 6 Nielsen C. Damasceno Introdução Os modelos anteriores eram realizado entre duas partes: Cliente e Servidor. Com RPC e RMI não é possível

Leia mais

Universidade Federal de Minas Gerais. Sistemas Operacionais. Aula 23. Sistemas Operacionais Distribuídos

Universidade Federal de Minas Gerais. Sistemas Operacionais. Aula 23. Sistemas Operacionais Distribuídos Aula 23 Distribuídos SOs de Rede Em sistemas operacionais de rede você sabe quando é local e quando é remoto. Assim, o trabalho não muda, com exceção de comandos para acesso remoto: - telnet - ftp - etc.

Leia mais

Sistemas Distribuídos. Coulouris Capítulo 4

Sistemas Distribuídos. Coulouris Capítulo 4 Sistemas Distribuídos Coulouris Capítulo 4 Mensagens Para comunicar-se com outros processos, um processo envia uma MENSAGEM para um DESTINO; um outro processo nesse destino recebe a mensagem. As operações

Leia mais

Notas da Aula 15 - Fundamentos de Sistemas Operacionais

Notas da Aula 15 - Fundamentos de Sistemas Operacionais Notas da Aula 15 - Fundamentos de Sistemas Operacionais 1. Software de Entrada e Saída: Visão Geral Uma das tarefas do Sistema Operacional é simplificar o acesso aos dispositivos de hardware pelos processos

Leia mais

Sistemas Operacionais 2014 Introdução. Alexandre Augusto Giron alexandre.a.giron@gmail.com

Sistemas Operacionais 2014 Introdução. Alexandre Augusto Giron alexandre.a.giron@gmail.com Sistemas Operacionais 2014 Introdução Alexandre Augusto Giron alexandre.a.giron@gmail.com Roteiro Sistemas Operacionais Histórico Estrutura de SO Principais Funções do SO Interrupções Chamadas de Sistema

Leia mais

Um cluster de servidores de email pode ser usado para servir os emails de uma empresa.

Um cluster de servidores de email pode ser usado para servir os emails de uma empresa. CLUSTERS Pode-se pegar uma certa quantidade de servidores e juntá-los para formar um cluster. O serviço então é distribuído entre esses servidores como se eles fossem uma máquina só. Um cluster de servidores

Leia mais

Sistemas Distribuídos

Sistemas Distribuídos Sistemas Distribuídos Comunicação de Grupos Peer to Peer Comunicação de Grupos Modelos Anteriores - Comunicação envolvia somente duas partes. RPC não permite comunicação de um processo com vários outros

Leia mais

Unix: Sistema de Arquivos. Geraldo Braz Junior

Unix: Sistema de Arquivos. Geraldo Braz Junior Unix: Sistema de Arquivos Geraldo Braz Junior 2 Arquivos Um arquivo é visto pelo SO apenas como uma seqüência de bytes: nenhuma distinção é feita entre arquivos ASCII, binários, etc.; Muitos programas

Leia mais

Sistemas Distribuídos

Sistemas Distribuídos Sistemas Distribuídos Universidade Federal do ABC Turma: Ciência da Computação Prof. Dr. Francisco Isidro Massetto Introdução Comunicação em Sistemas Distribuídos Introdução: Comunicação em Sistemas Distribuídos

Leia mais

IFPE. Disciplina: Sistemas Operacionais. Prof. Anderson Luiz Moreira

IFPE. Disciplina: Sistemas Operacionais. Prof. Anderson Luiz Moreira IFPE Disciplina: Sistemas Operacionais Prof. Anderson Luiz Moreira SERVIÇOS OFERECIDOS PELOS SOS 1 Introdução O SO é formado por um conjunto de rotinas (procedimentos) que oferecem serviços aos usuários

Leia mais

Um pouco sobre Pacotes e sobre os protocolos de Transporte

Um pouco sobre Pacotes e sobre os protocolos de Transporte Um pouco sobre Pacotes e sobre os protocolos de Transporte O TCP/IP, na verdade, é formado por um grande conjunto de diferentes protocolos e serviços de rede. O nome TCP/IP deriva dos dois protocolos mais

Leia mais

Sistemas Distribuídos e Redes de Sensores

Sistemas Distribuídos e Redes de Sensores Aula 5: abril de 2013 sobre nosso exemplo cliente-servidor servidor espera pedido e passa a tratá-lo e pedidos que cheguem durante tratamento? cliente envia pedido de leitura... pode ou não receber resposta?

Leia mais

Considerações no Projeto de Sistemas Cliente/Servidor

Considerações no Projeto de Sistemas Cliente/Servidor Cliente/Servidor Desenvolvimento de Sistemas Graça Bressan Graça Bressan/LARC 2000 1 Desenvolvimento de Sistemas Cliente/Servidor As metodologias clássicas, tradicional ou orientada a objeto, são aplicáveis

Leia mais

Sistemas Operacionais

Sistemas Operacionais Sistemas Operacionais Sistemas de Entrada/Saída Princípios de Software Sistema de Entrada/Saída Princípios de Software Tratadores (Manipuladores) de Interrupções Acionadores de Dispositivos (Device Drivers)

Leia mais

Sistemas Operacionais

Sistemas Operacionais Sistemas Operacionais Aula 6 Estrutura de Sistemas Operacionais Prof.: Edilberto M. Silva http://www.edilms.eti.br Baseado no material disponibilizado por: SO - Prof. Edilberto Silva Prof. José Juan Espantoso

Leia mais

Roteiro. Sistemas Distribuídos. Sistemas de Arquivos Distribuídos. Sistema de arquivos distribuídos

Roteiro. Sistemas Distribuídos. Sistemas de Arquivos Distribuídos. Sistema de arquivos distribuídos Sistemas Distribuídos Sistemas de Arquivos Distribuídos Roteiro Sistema de arquivos distribuídos Requisitos Arquivos e diretórios Compartilhamento Cache Replicação Estudo de caso: NFS e AFS Sistemas Distribuídos

Leia mais

BANCO DE DADOS DISTRIBUÍDOS e DATAWAREHOUSING

BANCO DE DADOS DISTRIBUÍDOS e DATAWAREHOUSING BANCO DE DADOS DISTRIBUÍDOS e DATAWAREHOUSING http://www.uniriotec.br/~tanaka/tin0036 tanaka@uniriotec.br Bancos de Dados Distribuídos Conceitos e Arquitetura Vantagens das Arquiteturas C/S (em relação

Leia mais

SISTEMAS OPERACIONAIS CAPÍTULO 3 CONCORRÊNCIA

SISTEMAS OPERACIONAIS CAPÍTULO 3 CONCORRÊNCIA SISTEMAS OPERACIONAIS CAPÍTULO 3 CONCORRÊNCIA 1. INTRODUÇÃO O conceito de concorrência é o princípio básico para o projeto e a implementação dos sistemas operacionais multiprogramáveis. O sistemas multiprogramáveis

Leia mais

Programação Concorrente Processos e Threads

Programação Concorrente Processos e Threads Programação Concorrente Processos e Threads Prof. Eduardo Alchieri Processos O conceito mais central em qualquer sistema operacional é o processo Uma abstração de um programa em execução Um programa por

Leia mais

ELEMENTOS DE PROTOCOLOS DE TRANSPORTE. Fabricio Sousa

ELEMENTOS DE PROTOCOLOS DE TRANSPORTE. Fabricio Sousa ELEMENTOS DE PROTOCOLOS DE TRANSPORTE Fabricio Sousa Elementos de protocolos de transporte 2 Serviço de transporte implementado por um protocolo de transporte usado entre duas entidades de transporte Em

Leia mais

AULA 13 - Gerência de Memória

AULA 13 - Gerência de Memória AULA 13 - Gerência de Memória omo sabemos, os computadores utilizam uma hierarquia de memória em sua organização, combinando memórias voláteis e não-voláteis, tais como: memória cache, memória principal

Leia mais

Organização de Computadores 1

Organização de Computadores 1 Organização de Computadores 1 4 SUPORTE AO SISTEMA OPERACIONAL Prof. Luiz Gustavo A. Martins Sistema Operacional (S.O.) Programa responsável por: Gerenciar os recursos do computador. Controlar a execução

Leia mais

Comunicação de Dados

Comunicação de Dados UNISUL 2013 / 1 Universidade do Sul de Santa Catarina Engenharia Elétrica - Telemática 1 Comunicação de Dados Aula 6 Agenda Projeto da camada de enlace de dados Detecção e correção de erros Protocolos

Leia mais

Resumo. Introdução Classificação Fases Curiosidades

Resumo. Introdução Classificação Fases Curiosidades Tolerância à falha Resumo Introdução Classificação Fases Curiosidades Introdução Sistemas Tolerantes a Falhas são aqueles que possuem a capacidade de continuar provendo corretamente os seus serviços mesmo

Leia mais

Sistemas Distribuídos

Sistemas Distribuídos Sistemas Distribuídos LICENCIATURA EM COMPUTAÇÃO Prof. Adriano Avelar Site: www.adrianoavelar.com Email: eam.avelar@gmail.com O que veremos hoje... Evolução Histórica Motivação Conceitos Características

Leia mais

Comunicação Inter-Processos. Prof. Adriano Fiorese. Conceitos Iniciais

Comunicação Inter-Processos. Prof. Adriano Fiorese. Conceitos Iniciais Comunicação Inter-Processos Conceitos Iniciais 1 Características para Comunicação Inter-Processos. Passagem de Mensagem pode ser suportada por duas operações de comunicação (send e receive). A comunicação

Leia mais

Sistemas Distribuídos

Sistemas Distribuídos Sistemas Distribuídos Comunicação Remota Gustavo Reis gustavo.reis@ifsudestemg.edu.br 1 Comunicação entre processos está no coração de todo sistema distribuído. Não tem sentido estudar sistemas distribuídos

Leia mais

Distributed Systems Principles and Paradigms

Distributed Systems Principles and Paradigms Distributed Systems Principles and Paradigms Maarten van Steen VU Amsterdam, Dept. Computer Science (Tradução e Adaptação Ricardo Anido - IC/Unicamp) Capítulo 04: Comunicação Versão: 20 de março de 2014

Leia mais

4 Estrutura do Sistema Operacional. 4.1 - Kernel

4 Estrutura do Sistema Operacional. 4.1 - Kernel 1 4 Estrutura do Sistema Operacional 4.1 - Kernel O kernel é o núcleo do sistema operacional, sendo responsável direto por controlar tudo ao seu redor. Desde os dispositivos usuais, como unidades de disco,

Leia mais

6 - Gerência de Dispositivos

6 - Gerência de Dispositivos 1 6 - Gerência de Dispositivos 6.1 Introdução A gerência de dispositivos de entrada/saída é uma das principais e mais complexas funções do sistema operacional. Sua implementação é estruturada através de

Leia mais

Paradigma Cliente/Servidor

Paradigma Cliente/Servidor Paradigma Cliente/Servidor Mário Meireles Teixeira UFMA Departamento de Informática Dezembro, 2012 Comunicação em Sistemas Distribuídos! Os processos em um SD estão lógica e fisicamente separados. Precisam

Leia mais

Projeto de Arquitetura

Projeto de Arquitetura Projeto de Arquitetura Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 11 Slide 1 Objetivos Apresentar projeto de arquitetura e discutir sua importância Explicar as decisões de projeto

Leia mais

Sistemas Operacionais. Prof. Pedro Luís Antonelli Anhanguera Educacional

Sistemas Operacionais. Prof. Pedro Luís Antonelli Anhanguera Educacional Sistemas Operacionais Prof. Pedro Luís Antonelli Anhanguera Educacional INTRODUÇÃO Sistema Operacional (S.O.) Aplicativos Formado por um conjunto de rotinas que oferecem serviços aos usuários, às aplicações

Leia mais

Arquitetura de Sistemas Operacionais Machado/Maia. Arquitetura de Sistemas

Arquitetura de Sistemas Operacionais Machado/Maia. Arquitetura de Sistemas Arquitetura de Sistemas Operacionais Capítulo 4 Estrutura do Sistema Operacional Cap. 4 Estrutura do Sistema 1 Sistemas Operacionais Pitágoras Fadom Divinópolis Material Utilizado na disciplina Sistemas

Leia mais

Hardware (Nível 0) Organização. Interface de Máquina (IM) Interface Interna de Microprogramação (IIMP)

Hardware (Nível 0) Organização. Interface de Máquina (IM) Interface Interna de Microprogramação (IIMP) Hardware (Nível 0) Organização O AS/400 isola os usuários das características do hardware através de uma arquitetura de camadas. Vários modelos da família AS/400 de computadores de médio porte estão disponíveis,

Leia mais

Notas da Aula 17 - Fundamentos de Sistemas Operacionais

Notas da Aula 17 - Fundamentos de Sistemas Operacionais Notas da Aula 17 - Fundamentos de Sistemas Operacionais 1. Gerenciamento de Memória: Introdução O gerenciamento de memória é provavelmente a tarefa mais complexa de um sistema operacional multiprogramado.

Leia mais

Sistemas Distribuídos. Professora: Ana Paula Couto DCC 064

Sistemas Distribuídos. Professora: Ana Paula Couto DCC 064 Sistemas Distribuídos Professora: Ana Paula Couto DCC 064 Arquiteturas Capítulo 2 Agenda Estilos Arquitetônicos Arquiteturas de Sistemas Arquiteturas Centralizadas Arquiteturas Descentralizadas Arquiteturas

Leia mais

Márcio Leandro Moraes Rodrigues. Frame Relay

Márcio Leandro Moraes Rodrigues. Frame Relay Márcio Leandro Moraes Rodrigues Frame Relay Introdução O frame relay é uma tecnologia de chaveamento baseada em pacotes que foi desenvolvida visando exclusivamente a velocidade. Embora não confiável, principalmente

Leia mais

Sistemas Distribuídos: Conceitos e Projeto Threads e Migração de Processos

Sistemas Distribuídos: Conceitos e Projeto Threads e Migração de Processos Sistemas Distribuídos: Conceitos e Projeto Threads e Migração de Processos Francisco José da Silva e Silva Laboratório de Sistemas Distribuídos (LSD) Departamento de Informática / UFMA http://www.lsd.deinf.ufma.br

Leia mais

Sistemas Distribuídos

Sistemas Distribuídos Sistemas Distribuídos Modelo Cliente-Servidor: comunicação orientada por mensagem e comunicação orientada por fluxo Prof. MSc. Hugo Souza Continuando o módulo 03 da primeira unidade, iremos abordar sobre

Leia mais

Capítulo 8. Sistemas com Múltiplos Processadores. 8.1 Multiprocessadores 8.2 Multicomputadores 8.3 Sistemas distribuídos

Capítulo 8. Sistemas com Múltiplos Processadores. 8.1 Multiprocessadores 8.2 Multicomputadores 8.3 Sistemas distribuídos Capítulo 8 Sistemas com Múltiplos Processadores 8.1 Multiprocessadores 8.2 Multicomputadores 8.3 Sistemas distribuídos 1 Sistemas Multiprocessadores Necessidade contínua de computadores mais rápidos modelo

Leia mais

Sistemas Distribuídos. Professora: Ana Paula Couto DCC 064

Sistemas Distribuídos. Professora: Ana Paula Couto DCC 064 Sistemas Distribuídos Professora: Ana Paula Couto DCC 064 Questões Em uma rede de sobreposição (overlay), mensagens são roteadas de acordo com a topologia da sobreposição. Qual uma importante desvantagem

Leia mais

Arquitetura de Computadores. Introdução aos Sistemas Operacionais

Arquitetura de Computadores. Introdução aos Sistemas Operacionais Arquitetura de Computadores Introdução aos Sistemas Operacionais O que é um Sistema Operacional? Programa que atua como um intermediário entre um usuário do computador ou um programa e o hardware. Os 4

Leia mais

Curso Tecnológico de Redes de Computadores 5º período Disciplina: Tecnologia WEB Professor: José Maurício S. Pinheiro V. 2009-2

Curso Tecnológico de Redes de Computadores 5º período Disciplina: Tecnologia WEB Professor: José Maurício S. Pinheiro V. 2009-2 Curso Tecnológico de Redes de Computadores 5º período Disciplina: Tecnologia WEB Professor: José Maurício S. Pinheiro V. 2009-2 Aula 3 Virtualização de Sistemas 1. Conceito Virtualização pode ser definida

Leia mais

Arquitetura de Sistemas Distribuídos. Introdução a Sistemas Distribuídos

Arquitetura de Sistemas Distribuídos. Introdução a Sistemas Distribuídos Introdução a Sistemas Distribuídos Definição: "Um sistema distribuído é uma coleção de computadores autônomos conectados por uma rede e equipados com um sistema de software distribuído." "Um sistema distribuído

Leia mais

Sistemas Distribuídos

Sistemas Distribuídos Sistemas Distribuídos LICENCIATURA EM COMPUTAÇÃO Prof. Adriano Avelar Site: www.adrianoavelar.com Email: eam.avelar@gmail.com Mecanismos de Comunicação Voltando ao exemplo da calculadora... Rede local

Leia mais

Sistemas Distribuídos

Sistemas Distribuídos Sincronização Referência Sistemas operacionais modernos Andrew S. TANENBAUM Prentice-Hall, 995 Seção. pág. 36-325 2 Conteúdo Relógios lógicos Algoritmo de Lamport Relógios físicos Algoritmos para sincronização

Leia mais

Há dois tipos de configurações bidirecionais usados na comunicação em uma rede Ethernet:

Há dois tipos de configurações bidirecionais usados na comunicação em uma rede Ethernet: Comunicação em uma rede Ethernet A comunicação em uma rede local comutada ocorre de três formas: unicast, broadcast e multicast: -Unicast: Comunicação na qual um quadro é enviado de um host e endereçado

Leia mais

Sistemas Operacionais

Sistemas Operacionais Sistemas Operacionais Gerência de processos Controle e descrição de processos Edson Moreno edson.moreno@pucrs.br http://www.inf.pucrs.br/~emoreno Sumário Representação e controle de processos pelo SO Estrutura

Leia mais

SISTEMAS DISTRIBUIDOS

SISTEMAS DISTRIBUIDOS 1 2 Caracterização de Sistemas Distribuídos: Os sistemas distribuídos estão em toda parte. A Internet permite que usuários de todo o mundo acessem seus serviços onde quer que possam estar. Cada organização

Leia mais

Figura 01 Kernel de um Sistema Operacional

Figura 01 Kernel de um Sistema Operacional 01 INTRODUÇÃO 1.5 ESTRUTURA DOS SISTEMAS OPERACIONAIS O Sistema Operacional é formado por um Conjunto de rotinas (denominado de núcleo do sistema ou kernel) que oferece serviços aos usuários e suas aplicações

Leia mais

Sistemas de Informação. Sistemas Operacionais 4º Período

Sistemas de Informação. Sistemas Operacionais 4º Período Sistemas de Informação Sistemas Operacionais 4º Período SISTEMA DE ARQUIVOS SUMÁRIO 7. SISTEMA DE ARQUIVOS: 7.1 Introdução; 7.2 s; 7.3 Diretórios; 7.4 Gerência de Espaço Livre em Disco; 7.5 Gerência de

Leia mais

Notas da Aula 4 - Fundamentos de Sistemas Operacionais

Notas da Aula 4 - Fundamentos de Sistemas Operacionais Notas da Aula 4 - Fundamentos de Sistemas Operacionais 1. Threads Threads são linhas de execução dentro de um processo. Quando um processo é criado, ele tem uma única linha de execução, ou thread. Esta

Leia mais

Visão Geral de Sistemas Operacionais

Visão Geral de Sistemas Operacionais Visão Geral de Sistemas Operacionais Sumário Um sistema operacional é um intermediário entre usuários e o hardware do computador. Desta forma, o usuário pode executar programas de forma conveniente e eficiente.

Leia mais

Arquitetura de Sistemas Operativos

Arquitetura de Sistemas Operativos Arquitetura de Sistemas Operativos Sistemas Operativos 2011/2012 1 Introdução Os sistemas operativos implementam mecanismos que asseguram independência entre processos (i.e., a execução de um processo

Leia mais

Índice. Para encerrar um atendimento (suporte)... 17. Conversa... 17. Adicionar Pessoa (na mesma conversa)... 20

Índice. Para encerrar um atendimento (suporte)... 17. Conversa... 17. Adicionar Pessoa (na mesma conversa)... 20 Guia de utilização Índice Introdução... 3 O que é o sistema BlueTalk... 3 Quem vai utilizar?... 3 A utilização do BlueTalk pelo estagiário do Programa Acessa Escola... 5 A arquitetura do sistema BlueTalk...

Leia mais

Sistemas Distribuídos e Paralelos

Sistemas Distribuídos e Paralelos Sistemas Distribuídos e Paralelos Tolerância a Falhas Ricardo Mendão Silva Universidade Autónoma de Lisboa r.m.silva@ieee.org January 14, 2015 Ricardo Mendão Silva (UAL) Sistemas Distribuídos e Paralelos

Leia mais

Sistemas Distribuídos Aula 10

Sistemas Distribuídos Aula 10 Sistemas Distribuídos Aula 10 Msc. Daniele Carvalho Oliveira Doutoranda em Ciência da Computação - UFU Mestre em Ciência da Computação UFU Bacharel em Ciência da Computação - UFJF Sincronização Comunicação

Leia mais

Interconexão redes locais (LANs)

Interconexão redes locais (LANs) Interconexão redes locais (LANs) Descrever o método de funcionamento dos dispositivos bridge e switch, desenvolver os conceitos básicos de LANs intermediárias, do uso do protocolo STP e VLANs. Com o método

Leia mais