Sistemas Distribuídos Jorge Surian [email protected] Sistemas Distribuídos: Processos (Clientes,...

46
Sistemas Distribuídos Jorge Surian [email protected] Sistemas Distribuídos: Processos (Clientes, Servidores e Migração)

Transcript of Sistemas Distribuídos Jorge Surian [email protected] Sistemas Distribuídos: Processos (Clientes,...

Page 1: Sistemas Distribuídos Jorge Surian jsurian@uol.com.br Sistemas Distribuídos: Processos (Clientes, Servidores e Migração)

Sistemas DistribuídosJorge [email protected]

Sistemas Distribuídos: Processos (Clientes, Servidores e Migração)

Page 2: Sistemas Distribuídos Jorge Surian jsurian@uol.com.br Sistemas Distribuídos: Processos (Clientes, Servidores e Migração)

22

Processos Clientes (modelo Cliente-Servidor)

– Uma das tarefas mais importantes, atualmente, nas máquinas clientes é proporcionar aos usuários meios de interagir com servidores remotos.

– Primeiro Modo: Para cada serviço remoto, a máquina cliente terá um servidor separado, com o qual possa estabelecer contato. Algumas operações são feitas no próprio cliente.

Exemplo: Agenda remota compartilhada 2

Page 3: Sistemas Distribuídos Jorge Surian jsurian@uol.com.br Sistemas Distribuídos: Processos (Clientes, Servidores e Migração)

33

Processos

Clientes– Segundo Modo: Fornecimento de uma

interface de usuário conveniente. Dessa maneira, a máquina cliente é usada somente como um terminal sem nenhuma necessidade de armazenamento.

Exemplo: Thin clients, nova (antiga...) tendência.

Page 4: Sistemas Distribuídos Jorge Surian jsurian@uol.com.br Sistemas Distribuídos: Processos (Clientes, Servidores e Migração)

44

Processos

Cliente - Um exemplo de cliente: Sistema X Windows– Sistema X é baseado no modelo cliente-

servidor.» Servidor X é um programa que executa no sistema e

é responsável por todos os acessos ao hardware gráfico.

» Cliente se comunica com o servidor, enviando requisições como 'desenhe uma linha' ou 'preste atenção na entrada do teclado‘

» Solução pioneira, mas ainda muito usada pela adequação ao modelo cliente servidor.

– Pode ser visto como parte de um sistema operacional que controla o terminal.

Page 5: Sistemas Distribuídos Jorge Surian jsurian@uol.com.br Sistemas Distribuídos: Processos (Clientes, Servidores e Migração)

55

Processos

Cliente - Um exemplo de cliente: Sistema X Windows– Cerne do sistema e formado pelo núcleo X, que

contém todos os drivers do dispositivo específicos do terminal, usualmente fortemente dependente do hardware.

– O núcleo X oferece uma interface de nível relativamente baixo para controlar a tela e também para capturar eventos do teclado e do mouse.

– Interface disponibilizada para as aplicações e definida pela biblioteca Xlib.

Page 6: Sistemas Distribuídos Jorge Surian jsurian@uol.com.br Sistemas Distribuídos: Processos (Clientes, Servidores e Migração)

66

Processos Cliente - Sistema X Window (modelo esquemático –

continuação exemplo)

Page 7: Sistemas Distribuídos Jorge Surian jsurian@uol.com.br Sistemas Distribuídos: Processos (Clientes, Servidores e Migração)

77

Processos

Cliente - Sistema X Window (continuação exemplo)– Núcleo X e as aplicações X não precisam

necessariamente residir na mesma máquina – X fornece o protocolo X, que é um protocolo de

comunicação de camada de aplicação pelo qual uma instância de Xlib pode trocar dados e eventos com o núcleo X. Por exemplo, Xlib pode enviar requisições ao núcleo X para criar ou encerrar uma janela, estabelecer cores e definir o tipo de cursor. O núcleo X reagirá a eventos locais como entrada de teclado e mouse devolvendo pacotes de eventos a Xlib.

– Núcleo X recebe requisições para manipular o visor recebendo essas requisições de aplicações geralmente remotas.

– Núcleo X age como um servidor, enquanto as aplicações desempenham o papel de clientes.

Page 8: Sistemas Distribuídos Jorge Surian jsurian@uol.com.br Sistemas Distribuídos: Processos (Clientes, Servidores e Migração)

88

Processos

Cliente– Clientes - Transparência de Distribuição

» O software no lado cliente pode ser mais do que uma interface.

» Em alguns casos, parte do nível de processamento e dados são executadas no lado cliente.

» Transparência de Migração:

Se um cliente já está vinculado a um servidor, ele pode ser informado quando o servidor mudar de localização. Middleware no cliente → oculta do usuário a corrente localização do servidor.

Page 9: Sistemas Distribuídos Jorge Surian jsurian@uol.com.br Sistemas Distribuídos: Processos (Clientes, Servidores e Migração)

99

Processos

Cliente– Clientes - Transparência de Distribuição

»Transparência a falha: –Middleware cliente pode ser configurado para tentar a conexão com um servidor repetidas vezes, ou tentar um outro servidor depois de fracassar determinado número de tentativas.

–Uso de cache: Uma falha na conexão com o servidor é compensada pela exibição de dados anteriormente armazenados no cache, como os browsers Web podem fazer, por vezes gerando inúmeros inconvenientes.

Page 10: Sistemas Distribuídos Jorge Surian jsurian@uol.com.br Sistemas Distribuídos: Processos (Clientes, Servidores e Migração)

1010

Processos

Cliente– Modelo Esquemático demonstrando situação

onde um cliente chama vários servidores, obtém várias respostas e passa uma delas à aplicação cliente, mantendo a transparência.

Page 11: Sistemas Distribuídos Jorge Surian jsurian@uol.com.br Sistemas Distribuídos: Processos (Clientes, Servidores e Migração)

1111

Processos

Servidores– Cada servidor, de maneira geral, é organizado

do mesmo modo:»Espera por uma requisição de um cliente.»Assegura o atendimento.»Espera pela próxima requisição

– Questões de Projeto»Como tratar as requisições?»Como os clientes contatam um servidor?»Como interromper comunicação com o

servidor?»Servidor deve guardar estado dos clientes?

Page 12: Sistemas Distribuídos Jorge Surian jsurian@uol.com.br Sistemas Distribuídos: Processos (Clientes, Servidores e Migração)

1212

Processos

Servidores – Tratamento de Requisições– Servidor Iterativo: Próprio servidor manipula

a requisição e, se necessário, retorna uma resposta ao cliente

– Servidor Concorrente: Não manipula por si próprio a requisição, como no Servidor multithread, onde processos ou threads é que devolvem a resposta ao cliente.

Page 13: Sistemas Distribuídos Jorge Surian jsurian@uol.com.br Sistemas Distribuídos: Processos (Clientes, Servidores e Migração)

1313

Processos

Servidores – Forma de Organização– Servidor Iterativo: Situação em que o próprio

servidor manipula a requisição e, se necessário, retorna uma resposta ao cliente.

– Servidor Concorrente: Nessa situação o servidor não manipula por si próprio a requisição. Os servidor multithreads, são exemplos de servidores concorrentes. Nos servidores concorrentes típicos do ambiente Unix o processo ou threads que manipula a requisição é também responsável por sua devolução ao cliente.

Page 14: Sistemas Distribuídos Jorge Surian jsurian@uol.com.br Sistemas Distribuídos: Processos (Clientes, Servidores e Migração)

1414

Processos

Servidores – Funcionamento– Clientes enviam requisições a uma porta, na

máquina servidora.– Para serviços conhecidos existem portas pré-

definidas, por exemplo servidores que manipulam requisições FTP na Internet, ouvem a porta TCP 21, mas um servidor HTTP ouvirá sempre a porta 80.

– Para serviços que não requerem porta prédeterminada, a opção mais usual é ter um daemon (um programa executado automaticamente em um computador a fim de executar um serviço para o sistema operacional), fazendo com que o Cliente acesse o daemon e o sistema operacional informará dinamicamente uma porta livre.

Page 15: Sistemas Distribuídos Jorge Surian jsurian@uol.com.br Sistemas Distribuídos: Processos (Clientes, Servidores e Migração)

1515

Processos

Servidores – Esquema de funcionamento

Page 16: Sistemas Distribuídos Jorge Surian jsurian@uol.com.br Sistemas Distribuídos: Processos (Clientes, Servidores e Migração)

1616

Processos

Servidores e Superservidores– Uma outra maneira de manipular portas é o uso

de superservidores, para se evitar desperdício de recursos.

– Um caso típico é aquele onde muitos servidores ficam esperando passivamente por uma requisição. Muitos recursos seriam desperdiçados na monitoração desses processos passivos.

– Se o monitoramento passar a ser realizado por um superservidor à escuta em cada porta associada com um serviço específico.

– Por exemplo, o daemom inetd no Unix ouve uma quantidade de portas bem conhecidas para serviços de internet. Quando chega uma requisição, o daemon bifurca um processo para cuidar da requisição, que será cancelado, findada a execução da requisição.

Page 17: Sistemas Distribuídos Jorge Surian jsurian@uol.com.br Sistemas Distribuídos: Processos (Clientes, Servidores e Migração)

1717

Processos Servidores – Superservidores – Esquema de

Funcionamento

Page 18: Sistemas Distribuídos Jorge Surian jsurian@uol.com.br Sistemas Distribuídos: Processos (Clientes, Servidores e Migração)

1818

Processos

Servidores – Como interromper um servidor?

Problema: O usuário resolve fazer um download de um enorme arquivo para um servidor FTP. Repentinamente descobre que o arquivo escolhido estava errado. O que fazer para deter o processo?

Abordagem mais simples: usuário sai abruptamente da aplicação cliente → servidor encerrará a conexão antiga, em algum momento admitindo falha do cliente.

Page 19: Sistemas Distribuídos Jorge Surian jsurian@uol.com.br Sistemas Distribuídos: Processos (Clientes, Servidores e Migração)

1919

Processos

Servidores – Como interromper um servidor?

Abordagem mais completa: dados “urgentes” (fora da banda) são enviados fazendo com que o servidor possa inspecionar os dados e manipulá-los de acordo com a necessidade, em acordo com o esquema:» Pacotes TCP possuem no header o campo

URG.» Servidor ao receber um pacote com o

campo URG setado é interrompido, através de um sinal.

» Servidor cancela o envio do arquivo errado.

Page 20: Sistemas Distribuídos Jorge Surian jsurian@uol.com.br Sistemas Distribuídos: Processos (Clientes, Servidores e Migração)

2020

Processos

Servidores – Avaliação do Estado– Os servidores podem estar num dos três

estados descritos: Sem, com ou flexível.– Quando o servidor estiver sem estado, ele:

»Não mantém informações sobre os estados dos clientes.

»Pode mudar seu próprio estado sem ter que informar a nenhum cliente.

»Por exemplo, servidor Web são sem estado, pois após processar uma requisição, esquece o cliente.

»Mesmo sem estado, servidor Web guarda informações de clientes, mas sua eventual perda não resulta na interrupção do serviço ou numa falha. Simplesmente pode haver uma perda de desempenho.

Page 21: Sistemas Distribuídos Jorge Surian jsurian@uol.com.br Sistemas Distribuídos: Processos (Clientes, Servidores e Migração)

2121

Processos

Servidores – Avaliação do Estado– Quando o servidor estiver em estado flexível,

ele:»Servidor promete manter estado em nome

do cliente, por um tempo limitado.»Após o tempo limitado, o servidor descarta

estas informações.»Exemplo: Servidor promete manter um

cliente informado sobre atualizações, mas depois de um determinado tempo o servidor volta ao estado padrão (default) descartando quaisquer informações que guardava em nome de um cliente associado.

Page 22: Sistemas Distribuídos Jorge Surian jsurian@uol.com.br Sistemas Distribuídos: Processos (Clientes, Servidores e Migração)

2222

Processos

Servidores – Avaliação do Estado– Quando o servidor estiver em com estado,

ele:»Mantém informações persistentes sobre

seus clientes.» Informações precisam ser explicitamente

removidas pelo servidor.

Page 23: Sistemas Distribuídos Jorge Surian jsurian@uol.com.br Sistemas Distribuídos: Processos (Clientes, Servidores e Migração)

2323

Processos

Servidores – Avaliação do Estado– Quando o servidor estiver em com estado,

ele:

Exemplo: Servidor de arquivos que permite a um cliente manter cópia local de um arquivo. Servidor mantém uma tabela, com entradas (cliente, arquivo). Permite monitorar as permissões sobre um arquivo, etc.

»Vantagem: Desempenho percebido pelo cliente nas operações de leitura e escrita.

»Problema: Recuperação de Falhas, pois o servidor tem que recuperar sua tabela de entradas (cliente arquivo), já que sem isso deixará de garantir que processou as mais recentes atualizações em um arquivo.

Page 24: Sistemas Distribuídos Jorge Surian jsurian@uol.com.br Sistemas Distribuídos: Processos (Clientes, Servidores e Migração)

2424

Processos

Servidores – Clusters de Servidores– Clusters de Servidores: Conjunto de

máquinas conectadas por uma rede, no qual cada máquina executa um ou mais servidores. Essas máquinas estão conectadas por uma rede local, com alta largura de banda e baixa latência.

– Esquema geral de funcionamento de um cluster de servidores (em três camadas)

Page 25: Sistemas Distribuídos Jorge Surian jsurian@uol.com.br Sistemas Distribuídos: Processos (Clientes, Servidores e Migração)

2525

Processos

Servidores – Clusters de Servidores– Comutador Lógico (1ª Camada)

» Forma o ponto de entrada para o cluster de servidores, oferecendo um único endereço de rede.

» Considerando TCP, o comutador aceita requisições e as transfere a um dos servidores.

» Identifica o melhor servidor a tratar a requisição.

Page 26: Sistemas Distribuídos Jorge Surian jsurian@uol.com.br Sistemas Distribuídos: Processos (Clientes, Servidores e Migração)

2626

Processos

Servidores – Clusters de Servidores– 2ª Camada

» Nos ambientes corporativos em geral as aplicações carecem de máquinas de tecnologia relativamente baixa, porque a capacidade de computação requerida não é o gargalo, mas o acesso ao armazenamento. Assim, é possível e até provável encontrarmos aplicações sendo executadas diretamente na terceira ou na primeira camada, ou seja, o ambiente se torna cliente-servidor “puro”.

Page 27: Sistemas Distribuídos Jorge Surian jsurian@uol.com.br Sistemas Distribuídos: Processos (Clientes, Servidores e Migração)

2727

Processos

Servidores – Clusters de Servidores– 3ª Camada

» Usualmente composta por servidores de processamento de dados, especialmente servidores de arquivo e banco de dados. Dependendo da utilização do cluster de servidores, esses servidores podem executar em máquinas altamente especializadas, configuradas para acesso de alta velocidade a disco, normalmente com grandes caches do lado do servidor.

» Esse modelo não é estanque. Pode ocorrer que máquinas distintas ofereçam também diferentes servidores de aplicação. Nessa situação cabe ao comutador distinguir esses serviços, senão não será capaz de repassar as requisições as máquinas adequadas.

Page 28: Sistemas Distribuídos Jorge Surian jsurian@uol.com.br Sistemas Distribuídos: Processos (Clientes, Servidores e Migração)

2828

Processos

Servidores – Clusters de Servidores– Por que migrar?

» Deve ser observado que a maioria das máquinas de segunda camada executam apenas uma aplicação, até porque aplicações diferentes tendem a ser gerenciadas por administradores diferentes que preferem um não interferir com o trabalho do outro.

» Nessa situação é usual que certas máquinas fiquem temporariamente ociosas enquanto outras não.

» Algo útil seria migrar serviços temporariamente para máquinas ociosas.

Page 29: Sistemas Distribuídos Jorge Surian jsurian@uol.com.br Sistemas Distribuídos: Processos (Clientes, Servidores e Migração)

2929

Processos

Servidores – Cluster de Servidores– Por que migrar?

» Analisando-se mais detalhadamente a primeira camada, mais especificamente o comutador, podemos chegar a algumas conclusões:1. É fundamental num projeto de cluster de

servidores que há de fato vários servidores.

2. Nenhuma máquina cliente precisa saber nada da organização do cluster.

3. A transparência de acesso é oferecida a partir de um único ponto de acesso, portanto cada ponto de acesso é realizado por uma máquina separada.

Page 30: Sistemas Distribuídos Jorge Surian jsurian@uol.com.br Sistemas Distribuídos: Processos (Clientes, Servidores e Migração)

3030

Processos

Servidores – Cluster de Servidores– Por que migrar?

4. Um modo padrão de acessar um cluster de servidores é através de uma conexão TCP pela qual as requisições de nível de aplicação sejam enviadas como parte de uma sessão, que termina com o encerramento da conexão.

5. Um comutador de camada de transporte aceita requisições de conexão TCP que entram e transferem tais conexões a um dos servidores.

Page 31: Sistemas Distribuídos Jorge Surian jsurian@uol.com.br Sistemas Distribuídos: Processos (Clientes, Servidores e Migração)

3131

Processos

Servidores – Cluster de Servidores– Por que migrar?

6. Esse princípio, conhecido como TCP handoff é baseado no fato do comutador identificar o melhor servidor para manipular aquela requisição repassando-a a esse servidor que enviará um reconhecimento diretamente o cliente requisitante, mas insere o endereço IP do comutador como endereço de fonte no cabeçalho do pacote IP que está transportando esse segmento TCP.

7. Esse processo de falsificação, conhecido como spoofing, é necessário para que o cliente continue executando o protocolo TCP, pois ele está esperando uma mensagem de voltado do comutador e não de um servidor do qual nunca ouviu falar...

Page 32: Sistemas Distribuídos Jorge Surian jsurian@uol.com.br Sistemas Distribuídos: Processos (Clientes, Servidores e Migração)

3232

Processos

Servidores – Cluster de Servidores– Princípio da transferência de IP

Page 33: Sistemas Distribuídos Jorge Surian jsurian@uol.com.br Sistemas Distribuídos: Processos (Clientes, Servidores e Migração)

3333

Processos

Servidores – Cluster de Servidores Distribuídos– Conjunto de máquinas que possivelmente

muda dinamicamente, com vários pontos de acesso também possivelmente variáveis, mas se apresenta ao mundo externo como um única e poderosa máquina.

– Características:» Vários pontos de acesso» Estabilidade no acesso

Alto desempenho» Flexibilidade

Page 34: Sistemas Distribuídos Jorge Surian jsurian@uol.com.br Sistemas Distribuídos: Processos (Clientes, Servidores e Migração)

3434

Processos

Migração de Código– Somente será abordada a passagem de dados

entre diferentes máquinas.– Observe-se que em alguns casos é importante

migrar código de uma máquina para outra.– Mas... Por que migrar código?

Melhorar Desempenho!

Page 35: Sistemas Distribuídos Jorge Surian jsurian@uol.com.br Sistemas Distribuídos: Processos (Clientes, Servidores e Migração)

3535

Processos

Migração de Código– Como fazer esta tarefa em sistemas

heterogêneos?» Envio de processos de máquinas sobrecarregadas

para máquinas com cargas mais leves.» Evitar grande quantidade de mensagens trocadas

entre aplicações cliente-servidor:

– Exemplo 1: Operações de banco de dados que envolvem uma grande quantidade de dados(aplicação cliente → servidor).

– Exemplo 2: Formulários enviados do servidor → cliente.

Page 36: Sistemas Distribuídos Jorge Surian jsurian@uol.com.br Sistemas Distribuídos: Processos (Clientes, Servidores e Migração)

3636

Processos

Migração de Código - Modelos para Migração de Código– Migração de código é algo muito amplo:

podemos também migrar status de um programa, sinais pendentes e outras partes do ambiente.

– Processo consiste em três segmentos:1. Segmento de código: contém o conjunto de

instruções que compõem o programa que está em execução.

2. Segmento de recursos: contém referências a recursos externos (arquivos, impressoras).

3. Segmento de execução: armazenar o estado em execução de um processo no momento da migração (dados privados, pilha,contador de programa)

Page 37: Sistemas Distribuídos Jorge Surian jsurian@uol.com.br Sistemas Distribuídos: Processos (Clientes, Servidores e Migração)

3737

Processos

Migração de Código - Modelos para Migração de Código– Mobilidade pode ser de dois tipos:

1. Mobilidade Fraca: possível transferir somente o segmento de código, junto com alguns dados de inicialização. Requer somente que a máquina-alvo possa executar o código (portabilidade).

2. Mobilidade Forte: segmento de execução também pode ser transferido. O processo em execução pode ser parado e movido para uma outra máquina e retomar a execução no ponto original.

Page 38: Sistemas Distribuídos Jorge Surian jsurian@uol.com.br Sistemas Distribuídos: Processos (Clientes, Servidores e Migração)

3838

Processos

Migração de Código– Em relação do ponto de início da migração:

» Iniciada pelo remetente: a migração é iniciada na máquina em que o código está em execução no momento em questão.

– Exemplo: Enviar programa de busca pela Internet a um servidor de banco de dados para realização de pesquisas.

» Iniciada pelo destinatário: Iniciativa da migração de código é tomada pela máquina-alvo.

Page 39: Sistemas Distribuídos Jorge Surian jsurian@uol.com.br Sistemas Distribuídos: Processos (Clientes, Servidores e Migração)

3939

Processos

Migração e Recursos Locais– Segmentos de recursos requerem uma atenção

especial

Exemplo: Comunicação de um processo sendo feita através de uma porta TCP. Ao mudar de localização, este processo deverá devolver a porta e requisitar uma nova no destino.

Page 40: Sistemas Distribuídos Jorge Surian jsurian@uol.com.br Sistemas Distribuídos: Processos (Clientes, Servidores e Migração)

4040

Processos

Migração e Recursos Locais– Três tipos de vinculações processo-recurso:

»Vinculação por identificador

• Processo requer exatamente o recurso referenciado (URL de um site).

»Vinculação por valor

• É necessário somente um valor.

• Se outro recurso fornece o mesmo valor, execução não é afetada (bibliotecas padronizadas).

»Vinculação por tipo

• Processo requer um recurso de um tipo específico (monitores, impressoras).

Page 41: Sistemas Distribuídos Jorge Surian jsurian@uol.com.br Sistemas Distribuídos: Processos (Clientes, Servidores e Migração)

4141

Processos

Migração e Recursos Locais– Três tipos de vinculações recurso-máquina:

» Recursos não ligados: recursos podem ser movidos com facilidade entre maquinas diferentes(arquivos de dados).

» Recursos amarrados: recursos podem ser movidos ou copiados, mas só a custo relativamente alto ( banco de dados locais).

» Recursos fixos: recursos estão intimamente vinculados a uma máquina ou ambiente especifico e não podem ser movidos (porta).

Page 42: Sistemas Distribuídos Jorge Surian jsurian@uol.com.br Sistemas Distribuídos: Processos (Clientes, Servidores e Migração)

4242

Processos

Migração e Recursos Locais– Referência global

» Caso vários processos referenciem um recurso, uma alternativa é estabelecer uma referência global, que atravesse as fronteiras das máquinas.

» URL (baixa complexidade).» Memória compartilhada entre processos (referência

global significa memória compartilhada).

Page 43: Sistemas Distribuídos Jorge Surian jsurian@uol.com.br Sistemas Distribuídos: Processos (Clientes, Servidores e Migração)

4343

Processos

Migração e Recursos Locais– Várias combinações entre vinculação

processo-recurso e recurso-máquina.» Exemplo 1: Processo admite que a memória pode ser

compartilhada entre processos (recurso fixo,vinculação de valor).

» Exemplo 2:Bibliotecas de tempo de execução (recurso amarrado, vinculação de valor).

Page 44: Sistemas Distribuídos Jorge Surian jsurian@uol.com.br Sistemas Distribuídos: Processos (Clientes, Servidores e Migração)

4444

Processos

Migração e Recursos Locais– Complexidade está ligada aos tipos de vínculo

processo-recurso e recurso-máquina.» Recursos não ligados: A melhor solução é copiar

ou mover o recurso para o novo destino.» Vinculações por tipo: A solução é vincular

novamente o processo a um recurso do mesmo tipo disponível no local.

Page 45: Sistemas Distribuídos Jorge Surian jsurian@uol.com.br Sistemas Distribuídos: Processos (Clientes, Servidores e Migração)

4545

Processos

Migração em Sistemas Heterogêneos– Requisitos:

» Segmento de código possa ser executado em cada plataforma.

» Segmento de execução pode ser adequadamente representado em cada plataforma.

» Efeito global: Migrar sistema operacional inteiro, em vez de migrar processos.

Page 46: Sistemas Distribuídos Jorge Surian jsurian@uol.com.br Sistemas Distribuídos: Processos (Clientes, Servidores e Migração)

4646

Copyright © 2010 Prof. Jorge Surian

Todos direitos reservados. Reprodução ou divulgação total ou parcial deste documento é expressamente proíbido sem o consentimento formal, por escrito, do Professor Surian.

Fonte:

Tanenbaum, Andrew S. e Steen, Marteen Van. Sistemas Distribuídos, São Paulo: Prentice Hall, 2008.