Corzinha da Fefe :PCor da lu (agora o docs vai ficar lindo :DDD... ueheuheuheu )SamucaOggoDebora

Material do professor Geyer sobre RPC:http :// saloon . inf . ufrgs . br / twiki - data / Disciplinas / INF 01151/ ExercicioEmLaboratorio 2006-2-04/ rpc . pdf

Material do Johann sobre deadlocks (coloquei aqui, pois não está aparecendo direto na pag)http :// www . inf . ufrgs . br /~ johann / sisop 2/ deadlock . pdf

LINKs para download do livro: http :// www . ziddu . com / download /16483725/ DistributedOperatingSystems . pdf . html http :// www .4 shared . com / office /-_ aPlT 7 l / Distributed _ Operating _ Systems _. html

ESTUDO - PROVA 2 - SISOP2 - 05/06/2012

CONTEÚDO:

- Introdução a sistemas distribuídos: vantagens, características, HW, SW- comunicação por troca de mensagens, sockets, modelo cliente/servidor- Remote Procedure Call (RPC)- Remote Method Invocation (RMI)- memória compartilhada distribuída- sincronização de relógios e relógio lógico- comunicação em grupo- algoritmos distribuídos: eleição, exclusão, semáforos distribuídos- detecção e prevenção de deadlocks em sistemas distribuídos

Resumo de SISOP II - Área 2

Introdução a Sistemas Distribuídos:Um sistema distribuído é um conjunto de computadores independentes que se apresenta a seus usuários como um sistema único e coerente.

A intenção de um sistema distribuído é transformar um grupo de máquinas fracamente conectadas em um sistema coerente com base em um conceito, cuja idéia é fornecer algo que unifique o sistema.

Um sistema distribuído deve ser:● Transparente: capaz de se apresentar aos usuários e aplicações como se fosse um

único sistema de computador. OBS: Visar a transparência de distribuíção pode ser uma

meta no projeto e na implementação de sistemas distribuídos, mas deve ser considerada em conjunto com outras questões, como desempenho e facilidade de compreensão. Nem sempre vale a pena tentar conseguir total transparência, pois o preço que se paga pode ser alto.

● Aberto: oferece serviços de acordo com regras padronizadas que descrevem a sintaxe e a semântica desses serviços.

● Escalável: Escalável com relação ao tamanho, o que significa que é fácil adicionar mais usuários e recursos ao sistema. Escalável em termos geográficos, sistemas e recursos podem estar longe uns dos outros. Escalável em termos administrativos, ele pode ser fácil de gerenciar, mesmo que abrajna muitas organizações administrativas diferentes. OBS: Normalmente isso implica em perda de desempenho à medida que é ampliado.

Vantagens do sistema distribuído:● Economia: é mais barato permitir que uma impressora seja compartilhada por diversos

usuários em um pequeno escritório do que comprar e manter uma impressora para cada usuário.

● Conectar usuários e recursos também facilita a colaboração e troca de informação.● O Acoplamento fraco dos computadores no sistema distribuiído é ao mesmo tempo uma

vantagem e uma desvantagem. É uma vantagem porque os computadores podem ser usados por uma ampla variedade de aplicações, mas é uma desvantagem, pois a programação dessas aplicações é difícil devido à falta de qualquer modelo de uma plataforma comum.

● Quando adequadamente projetados, os sistemas distribuídos podem ser ampliados com facilidade em relação ao tamanho da rede subjacente

Desvantagens:● SW mais complexos● Perda de desempenho● Menor segurança

Tipos de Sistemas Distribuídos:● Sistemas de Computação Distribuídos:

○ Computação de Cluster: HW subjacente consiste em um conjunto de estações de trabalho ou PC’s semelhantes, conectados por meio de uma rede local de alta velocidade. Cada nó executa o mesmo SO. Populares devido ao preço/desempenho dos PC’s.

● Computação em Grade: montados como federação de computadores, na qual cada sistema pode cair sob um domínio administrativo diferente, e pode ser muito diferente no que tange o HW, SW e tecnologia de rede empregada (heterogêneo).

● Sistemas de Informação Distribuídos:○ Sistemas de Processamento de Transações: RPC’s, isto é chamada de

procedimentos remotas, também costumam ser encapsuladas em uma transação (RPC transacional)

● Integração de Aplicações Empresariais: a idéia é que aplicações existentes possam trocar mensagens diretamente. Tipos de middleware de comunicação:

○ RPC: um componente de aplicação pode efetivamente enviar uma requisição a um outro componente de aplicação executando uma chamada de procedimento local, que resulta no empacotamento da requisição como uma mensagem e em seu envio ao chamador. Da mesma forma o resultado é enviado de volta e devolvido à aplicação como resultado da chamada do procedimento.Exemplo: O client (stub) chama send encapsula os parâmetros em uma

mensagem, pede para o kernel enviar e se bloqueia até vir um reply. O server, que está em um loop de receive, recebe o pacote, faz o q tem de fazer, dá um reply e entra em loop receive de novo.

Problemas - Solução:■ conversão de caracteres - espec pode ir junto da mensagem■ passagem de ponteiro - copiar a estrutura toda na mensagem

Bind dinamico: Servidor se anuncia quando é iniciado. Cliente, no inicio da transmissão, pergunta ao bind se existe servidor e o bind importa configurações do servidor ao iniciar a conexão (custoso).

Problemas na transmissão: Sua soluçãoSe não localizar o server: Usar exceções.Se um request se perder: Tem timeout, se tivermos mt perdas dai da erro.Se um reply se perder: Podemos usar num de sequencia.

Se server cai no meio da transmissão como o kernel distingue em que ponto parou a execução?

1. At least once: Espero o servidor reiniciar e restransmito. Garanto a entrega de 1 ou mais msg

2. Most Once: Desisto e reporto no evento de falhas. Garantia de 1 ou 0 entregas.

3. Exactly One: Garantia de 1 entrega, difícil de garantir uma entrega exata.

4. Sem garantias aka UDP puro.

Desisto. Essa capítulo de RPC é um monstro! Confiem na teoria de sockets +- e era isso!

○ PRINCIPAL PROBLEMA DO RPC: Passagem de parâmetros por ser por referência faz com que o cliente tenha que passar um volume muito grande de dados para o servidor para que a computação esteja correta. (solução ver item acima, na resposta da Fê). Perfeito, só acrescentando ...Porém apesar de ser possível manipular ponteiros para vetores e estruturas simples, NÃO é possível manipular para uma estrutura de dados arbitrária e complexa.

○ RMI: é o mesmo que o RPC, exceto que funciona com OBJETOS em vez de com APLICAÇÕES. OBS: Uma desvantagem do RPC e do RMI é que ambos, o chamador e o chamado, precisam estar ligados e em funcionamento no momento da comunicação. Além disso, eles precisam saber como se referir um ao outro.

○ MOM (middleware orientado a mensagem): aplicações apenas enviam mensagens a pontos lógicos de contato. As aplicações podem indicar o seu interesse por um tipo específico de mensagem, após, o middleware de

comunicação cuidará para que todas as mensagens sejam entregue a essas aplicações (publicar/subscrever).

● Sistemas Distribuídos Pervasivos: são sistemas distribuídos nos quais a instabilidade é o comportamento esperado. Tem uma ausência geral de controle administrativo humano.

○ Sistemas Dométicos: são compostos por computadores pessoais, TV, equipamentos de áudio e vídeo, dispositivos para jogos, smart phones e outros equipamentos de uso pessoal em um único sistema.

● Sistemas eletrônicos para tratamento de saúde: dispositivos (ex. sensores) que monitoram o bem-estar de indivíduos e entram automaticamente em contato com o médio se necessário.

● Redes de Sensores

RPC resumido: http :// www . youtube . com / watch ? v = Md 1 pBk - JbdQ Etapas do RPC:

1. O procedimento do cliente chama o stub do cliente.2. O stub do cliente constrói uma mensagem e envia ao kernel.3. O kernel envia uma mensagem ao kernel remoto.4. O kernel remoto entrega a mensagem ao stub do servidor.5. O stub do servidor desempacota os parâmetros constantes da mensagem e chama o

servidor.6. O servidor realiza o seu trabalho e retorna o resultado para um buffer dentro do stub.7. O stub do servidor empacota tais resultados em uma mensagem e emite para o kernel.8. O kernel remoto envia a mensagem para o kernel do cliente.9. O kernel do cliente entrega a mensagem ao stub do cliente.10. O stub desempacota os resultados e fornece ao cliente.

Modelo Cliente/ServidorNo modelo cliente/servidor básico, processos em um sistema distribuído são divididos em 2 grupos, com posível sobreposição. Um servidor é um processo que implementa um serviço específico, enquanto um cliente é um processo que requisita um serviço de um servidor enviando-lhe uma requisição e esperando pela resposta do servidor.

A comunicação entre um cliente e um servidor pode ser implementada por meio de um protocolo simples sem conexão quando a rede for razoavelmente confiável. Esse protocolo é mais eficiente e funciona bem, contanto que as mensagens não se percam nem sejam corrompidas. Infelizmente, fazer com que o protocolo seja resistente a falhas de transmissão não é trivial, a única coisa que podemos fazer é possivelmente deixar que o cliente reenvie a requisição quando não receber nenhuma mensagem de resposta. Porém, o problema está no fato de que o cliente não pode detectar ser a mensagem de requisição original se perdeu ou se a transmissão de resposta falhou. Se a resposta se perdeu, reenviar pode significar em executar uma operação dus vezes (ex. Transfira 10 000 de minha conta, o que teria sido melhor informar que houve erro).

Quando uma operação pode ser repetida várias vezes sem causar dano, diz-se que ela é idempotente. Como algumas requisição são idempotentes e outras não, deve ficar claro que não há nenhuma solução única para tratar mensagens perdidas.Como alternativa, muitos sistemas cliente/servidor usam um protocolo de comunicação confiável orientado a conexão. Seu desempenho é mais lento, porém funciona perfeitamente bem em sistemas de longa distância (menos confiáveis). Normalmente, é utilizado o TCP/IP, onde inicialmente há um estabelecimento de conexão para depois realizar um envio. Porém esse estabelecimento de conexão custa caro, especialmente se as mensagens de requisição e resposta forem pequenas.

Divisão de níveis de uma aplicação cliente/servidor:● Nível de interface de usuário: Clientes, de um modo geral implementam o nível de

interface de usuário (contém tudo o que é necessário para fazer interface diretamente com o usuário, como gerenciamente e exibição). Permitem usuários finais interagirem com aplicações.

● Nível de processamento: Contém a funcionalidade geral da aplicação. (exemplo recuperação de informação)

● Nível de dados: Contém os programas que mantem os dados propriamente ditos, sobre os quais as aplicações agem em suas operações. Os dados costumam ser persistentes, ou seja, ainda que nenhuma aplicação esteja sendo executada, os dados estarão armazenados em algum lugar para a próxima utilização. Normalmente é implementado pelo servidor. É responsável por manter os dados consistentes nas diferentes aplicações.

Clientes multithread:A maneira usual de ocultar latências de comunicação é iniciar a comunicação e imediatamente prosseguir com alguma outra coisa. Um browser web frequentemente inicia abuscando a página HTML e, na sequencia, a exibe, alguns começam a exibir os dados enquanto eles ainda vão entrando. Desenvolver um browser como um cliente multithread simplifica consideravelmente as coisas. Tão logo o principal arquivo HTML tenha sido buscado, threads separadas podem ser ativadas para se encarregar de buscar outras partes. Cada thread estabelece uma conexão separada com o servidor e traz os dados. Outra vantagem dessa utilização é que várias conexões podem ser abertas ao mesmo tempo. Se a carga desse servidor estiver pesada ou se ele for lento nenhuma melhoria de desempenho será notada, porém como muitos servidores são replicados e contém os mesmos documentos, podemos estabelecer conexões com réplicas diferentes, o que permite aos dados serem transferidos em paralelo. É claro, que só será possível se o cliente puder manipular fluxos de entrada verdadeiramente paralelos.

Servidores multhithread:A prática mostra que multithreading não somente simplifica consideravelmente o código do servidor como também facilita muito o desenvolvimento de servidores que exploram o paralelismo para obter alto desempenho.Vantagens de utilização de threads para clientes e servidores:Elas possibilitam reter a idéia de a idéia de processos sequenciais que fazem chamadas bloqueadoras de sistema (exemplo RPC) e ainda conseguem paralelismo. Chamadas bloqueadoras de sistema facilitam a programação, e o paralelismo aumenta o desempenho.

Comunicação por Grupo

Closed Groups: Somente participantes podem mandar para o grupo todo, outsiders só podem fazer point-to-point (processamento paralelo).Open Groups: Qualquer um pode mandar para o grupo inteiro

Peer Group: Processos iguais == Comunista. Simétrica, sem SPF. Difícil tomar decisões.Hirarchical Group: Um processo coordenador (todas as mensagens passam por ele)

Algoritmos de eleição (Ainda não li o livro, baseado em minhas anotações):BULLY - Coordenador morreu. Processo maior (maior ID) vira e diz: Eu sou coordenador. Máquinas ficam disputando quem é o maior.RING - Coordenador morreu. Então o processor invoca uma eleição e manda o seu número para o vizinho 7. Mensagem 5O vizinho 7 manda pro vizinho a mensagem 5,7. Quando essa mesma mensagem chegar de novo no 5..... perdi....

Sincronização de Relógio

Coisas a se preocupar quando temos sistemas distruídos:1. Informações relevantes espalhadas entre máquinas2. Processadores fazem decisões baseadas em informações locais3. Single Points Of Failure devem ser evitados4. Não existe relógio em comum.

Um máquina com vários processadores tem problemas de clock skew que é a diferença de tempo entre os relógios de cada CPU.

Lamport: A sincronização do relógio não importa, o que importa é que os processos concordem sobre a ordem de ocorrência de eventos.

Relógios físicos: Os relógios precisam ser iguais e não devem se desviar do tempo real. Todos deveriam saber que “a” acontece às 1:00 e b aconteceu às 1:01.Relógios lógicos: Os relógio não precisam ser iguais ou concordar com o tempo real, basta eles serem consistentes entre si (todos sabem que “a” aconteceu antes de “b”).

Lamport bolou um algoritmo de ordenação, mas e se os relógios dependerem do tempo real?Fê, pelo que eu compreendi do algoritmo de Lamport, ele é especificamente para relógios lógicos, ou seja, onde não há a dependência do tempo real. Se for necessário que os relógios dependam do tempo real, então é aconselhável se usar algum dos outros algoritmos. :)O algoritmo de Lamport segue esses três passos:1. Se a acontece antes de b no mesmo processo, C (a) < C(b)2. Se a e b representam o envio e o recebimento da mensagem. C(a) < C(b)3. Para todos os eventos a e b, C(a) != C(b)Obs: C é a mensagemA solução de Lamport segue diretamente a relação “aconteceu antes”. Se C saiu em um clock 60 (processamento da maquina local) ela deve chegar em um tempo > 60 (ou seja, 61 ou mais). Então cada mensagem leva o clock local como um dos parametros dela. Caso o

recebedor da mensagem tenha um clock menor que o recebimento da mesma, ele avança seu tempo para poder recebê-la.

Cristian’s AlgorithmExiste uma máquina Time Server que sincroniza envia seu relógio para todo mundo.Problema 1: O tempo nunca anda pra trás e se o servidor possuir um tempo menor que o cliente poderia causar problemas. As mudanças de tempo devem ser feitas de forma gradual adicionando ou diminuindo o tempo de interrupção (?)Problema 2: Tempo de propagação na rede. Pode-se resolver usando estimativas sobre o tempo.

The Berkeley AlgorithmCom Cristian o servidor é passivo e responde à requisições. No Berkeley é ativo.Server pergunta qual o clock das outras máquinas, as máquinas respondem com a diferença de tempo e o servidor diz, para cada máquina, como ajustar o tempo.

Averaging AlgorithmNão é centralizado. Cada máquina faz o broadcast do seu relógio e escuta outras máquinas em um período. Um algoritmo faz a média dos clocks e atualiza a máquina.

Prova do Johann de 20111. Quem deve construir o código dos STUBs para fazer RPC? (Marque apenas uma alternativa)[ ] O programador do servidor[ ] O sistema operacional[ ] O hardware[ X ] Um gerador automático (mais comum)[ ] O programador da aplicação Para permitir que servidores sejam acessados por diferentes clientes, diversos sistemas padronizados de RPC foram criados. A maioria deles usa uma linguagem de descrição de interface (IDL) para que diferentes plataformas possam chamar procedimentos. Fazendo uso de uma ferramenta como o RPCGEN, pode-se gerar interfaces entre cliente e servidor a partir de um arquivo IDL, os chamados stubs.A gente encontrou que é possível o programador construir o código do stub, mas o mais comum mesmo é um gerador automártico.A.. eu só li o que vcs tinham colocado agora, na verdade ele é gerado automaticamente, mas fica sob decisão do programador usa ele ou gerar um outro simples :P (material do geyer... se quiserem eu passo o link)

2. Marque as alternativas corretas:[ ] A troca de mensagens é um mecanismo mais simples para programação concorrente se comparado ao compartilhamento de memória.[ X ] Um servidor é quase sempre composto por uma estrutura assim:while (true) { recv(&msg); switch(msg.type): case1: pthread_create(service1, msg); break; ... }[ ] Uma das maiores dificuldades de RPC é que o código de stubs é complicado e precisa ser programado manualmente para cada aplicação.

[ X ] O uso de microcomputadores (grids ou clusters) é atualmente uma tendência, entre outros fatores, pq há limites físicos para construir uma única CPU de altíssimo desempenho, e quando isso é possível ainda assim a CPU única ainda seria a mais cara;[ ] O aspecto mais importante no desenvolvimento de um sistema distribuído é o seu desempenho, não importando se para isso tivermos que usar modelos de programação diferentes para comunicação e acesso a recursos remotos, com a consciencia de onde eles se encontram.

3. Sobre comunicação por troca de mensagens, identifique qual das afirmativas abaixo é falsa:[ ] Primitivas de envio de mensagens não bloqueantes podem ser implementadas fazendo com que o S.O copie a mensagem a ser enviada ou então avisando o usuário quando o buffer for liberado através de uma interrupção do processo do usuário, desviando o controle dele para um ponto de tratamento.[ X ] Somente primitivas de envio de mensagens podem ser bloqueantes ou não bloqueantes.[ ] Tanto primitivas bufferizadas ou não bufferizadas correm o risco de perder mensagens recebidas se o receptor não está lendo elas suficientemente rápido.[ ] É possível identificar processos servidores no sistema deixando que eles escolham endereços de um espaço grande, e localizando-os por broadcast na rede, mas isso consome banda significativa da rede.Pq está errado?Eu diria que uma primitiva de envio de mensagem != de recebimento de mensagem (que também pode ser bloqueante ou não bloqueante). Se a palavra envio fosse substituída por troca acho que estaria correto.Yes

4. Qual é o principal problema que limita o uso do RPC?Passagem de parâmetros por ser por referência faz com que o cliente tenha que passar um volume muito grande de dados para o servidor para que a computação esteja correta.

Se for uma variavel primitiva é só passar o valor, se for uma estrutura complexa daí não rola

Outro fator que limita é que para o funcionamento do RPC é necessário que o cliente e o servidor estejam funcionando no mesmo momento.

5. Observe as sequencias de acessos à memória e valores lidos ou escritos, e marque na tabela:

Baseada: http://www.cs.nmsu.edu/~pfeiffer/classes/573/notes/consistency.htmlModelo A:Estrita: não é válida, se não todos os valores lidos pelos processos seriam 2Sequencial: não é válida, se os valores lidos por P3 e P4 seriam os mesmos. O tempo não importa, mas a ordem com q eles são lidos em cada processo, sim.Causal: É valida (ta no Tanenbaum). Não sei porque. Correta, pois não é feita nenhuma operação do tipo r(x) nos processos que estão escrevendo, então a ordem de leitura nos outros processos é irrelevante.Isso, as escritas são concorrentes e não causais.

Modelo B:Estrita: Não é válida.Sequencial: É válida. Pois P3 e P4 leem os dados da mesma forma, primeiro 1 e depois 2Causal: ???? Correta pelo mesmo motivo explicado anteriormente.

6. Cite três modelos básicos de semântica de compartilhamento e diga sucintamente o que os caracteriza (diferencia): (não cai na prova :P) Tb acho q não cai na provaResposta da prova:Semântica unix:Acesso irrestrito;Semântica de Sessão:Acesso somente após um close, arquivo invisível para os demais enquanto estiver em uso.

Semântica Restritiva:Somente criação, leitura e exclusão

7. Que vantagens e desvantagens apresentam os servidores de arquivo sem informação de estado?Acho que não deve cair na prova

8. Como se faz para implementar o algoritmo de sinconização de relógio lógico de Lamport, com ordenação total de eventos no sistema? Elabore sua resposta em forma de algoritmo,

determinando os testes e ações que devem ser implementadas, e quando isto deve ser executado, além de especificar regras que devem ser válidas para o sistema.1. Chamada do cliente por uma funçao remota2. Enviar a mensagem com o respectivo clock da maquina local3. Maquina recebe a mensagem com o clock da outra maquina e avança seu tempo caso necessário (para 1 unidade acima do valor recebido).4. Executa a funçao, podendo retornar ao passo 1 (caso precise chamar uma funçao remota de outra maquina) ou para o passo 55. Executa localmente os procedimentos6. Envia para a maquina que enviou a mensagem com seu respectivo clock local7. Maquina que recebe a mensagem verifica o clock e avança seu tempo, caso necessário(Não tenho certeza se é bem isso, mas a idéia geral é essa dae)

9.

a )Observe o grafo de recursos alocados e solicitados por processos, segundo o modelo de Holt, e diga se a situação atual do sistema corresponde a uma situação e deadlock ou não:Sim está em deadlock.Não conseguimos encontrar nenhum ponto de partida neste grafo, não há recursos disponíveis nem para começarmos a podar os processos.O negocio é começar a observar a partir de onde tem processo que solicita recursos que estão disponíveis, e que vai conseguir. Claro que se não haver nenhum está em deadlock. Mas se tiver tem que fazendo e apagando as arestas ate atender todos.Pois é....mas no exemplo q o Johan deu o P4 (ponto de partida) era igualzinho a esse..... tipo ele assumiu q o P3 parou de usar o recuso e cortou as flechas bidirecionais do P4 . Dai o P4 continua ali por causa do recurso sendo utilizado pelo P8, mas dai eu consigo cortar todas as flechas do P6.

O ex do Johann nao era igual nao, eh soh ver nos slides, tinha mais um recurso disponivel pro p4, e dai mudava tudo!

Está sim... olha só (olha a figura embaixo).... o P4 pode usar o recurso de baixo mas aquele (da aresta em vermelho) não ta liberado (ele ta sendo usado pelo P2)!!!!!!!!!!!!!!!!!!!!!!!!!

Nessa figura presta atenção nas bolinhas e setinhas de P4! entre P2 e P6 estão 4 recursos dentro daquela bolinha, LOGO, não tão em deadlock, no desenho anterior havia 3 recursos ali dentro e o P4 solicitando um recurso ocupado.

b) A montagem de um grafo desse tipo e verificação de estado de deadlock faz parte de qual(is) estratégia(s) de tratamento do problema?Detecção de Deadlocks (resposta baseada nos slides do johann) - centralizada