Aula 6 - Comunicação

SISTEMAS DISTRIBUÍDOS
Prof. Ricardo Rodrigues Barcelar
http://www.ricardobarcelar.com.br
- Aula 6 –
NOMEAÇÃO E COMUNICAÇÃO
1. INTRODUÇÃO
A comunicação entre processos é o “coração” de um Sistema Distribuído. Isto definirá
como se realizarão os processos de troca de informações em as diferentes máquinas.
Na comunicação entre processos é desejável obter modelos onde a complexidade da
comunicação seja transparente para o desenvolvedor, ou seja, o desenvolvedor não deve se
preocupar em como a comunicação se dá e sim no seu resultado.
Outro aspecto importante da comunicação é a nomeação, utilizado para que um processo
possa identificar outro na rede.
2. COMUNICAÇÃO
2.1. Modelo Cliente-Servidor
Neste modelo os servidores implementam um serviço específico, os clientes solicitam ao
servidor um determinado serviço e espera pela resposta.
Figura 1 - Comportamento requisição-resposta
1
SISTEMAS DISTRIBUÍDOS
Prof. Ricardo Rodrigues Barcelar
http://www.ricardobarcelar.com.br
2.2. Protocolos em Camadas
Figura 2 - Camada, interface e protocolos do RM OSI
- Camada Física: Camada responsável pelo envio de bits. Trata da padronização das
interfaces elétrica, mecânica e de sinalização. Seus protocolos são dependentes do meio de
transmissão do link.
- Camada de Enlace: Camada responsável pelo envio de frames entre os links. Nela um
datagrama pode ser manipulado por diferentes tipos de protocolos da camada de enlace: Ethernet
(CSMA/CD), PPP. Cada protocolo diferente pode ou não implementar um conjunto de serviços.
Ex.: Entrega confiável da informação.
- Camada de Rede: Redes de longa distância são constituídas de muitos nós com
diferentes caminhos entre eles. Para definir como definir um caminho entre um par origem-destino
é utilizado o roteamento, que é a principal tarefa da camada de rede. Nesta camada também está
o Internet Protocol, protocolo sem conexão, onde pacotes são roteados de forma independente best-effort service.
- Camada de Transporte: Camada responsável pela comunicação lógica entre diferentes
processos sendo executados em diferentes hosts (fim-a-fim). Os protocolos da camada de
transporte não estão implementados nos roteadores. Esta camada pode fornecer os seguintes
serviços: multiplexing/demultiplexing, transmissão confiável, garantias de banda, retardo, etc. Esta
camada apresenta dois protocolo de transporte na Internet: TCP e UDP. O primeiro orientado a
Conexão, confiável, porém “lento”. O segundo sem conexão, “rápido”, porém não confiável.
- Camada de Aplicação: Esta camada define os protocolos que dão suporte a uma
aplicação para redes. Ex.: Aplicação WEB (HTTP), Aplicação e-mail (SMTP). Os protocolos
definem os tipos de mensagens trocadas e sua sintaxe.
- Camada de Middleware: Camada de software que é situada logicamente entre uma
camada de nível mais alto, composta de usuários e aplicações e uma camada subjacente, que
consiste de facilidades básicas de comunicação. O funcionamento do middleware depende de
autenticação, comprometimento e comunicação de alto nível.
2
SISTEMAS DISTRIBUÍDOS
Prof. Ricardo Rodrigues Barcelar
http://www.ricardobarcelar.com.br
Figura 3 - Modelo de referencia adaptado para comunicação em rede
2.3. Sockets
Os sockets são responsáveis por possibilitar a troca de informações entre processos
operando em hosts diferentes. É o ponto final de uma comunicação full-duplex entre dois
processos. O socket é a porta entre o processo da aplicação e o protocolo de transporte.
Na pilha de protocolos TCP/IP as mensagens são enviadas através da utilização de
sockets.
Figura 4 - Sockets
2.3.1. SOCKETS JAVA
Para comunicação distribuída à linguagem Java fornece três tipos diferentes de Sockets:
3
SISTEMAS DISTRIBUÍDOS
Prof. Ricardo Rodrigues Barcelar
http://www.ricardobarcelar.com.br
- Sockets orientados a conexão (TCP): Implementados com a Classe Socket
- Sockets sem Conexão (UDP): Implementados com a classe DatagramSocket
- Sockets sem Conexão Multicast: Implementado com a classe MulticastSocket
Neste processo de comunicação as informações são strings de bytes, sem significado
aparente.
(Vide
implementação
de
um
socket
em
Java
no
endereço
http://www.javaworld.com/javaworld/jw-12-1996/jw-12-sockets.html).
Na comunicação não existe a transparência de distribuição. Toda comunicação está
explícita, através de procedimentos send e receive. As funções mais sofisticadas devem ser feitas
na camada de aplicação.
Diante deste contexto é necessário oferecer uma comunicação de mais alto nível
denominado Middlware de comunicação, que independe da aplicação.
2.4. Middleware de Comunicação
Middlewares são softwares que em sistemas distribuídos ajudam a prover:
- Portabilidade
- Habilitam a mudança de um sistema ou componente de um ambiente (incluindo hardware
e software) para outro sem alterar o sistema ou componente que está sendo transferido
-Transparência
- Interoperabilidade
Eles fornecem interfaces de programação padronizadas para habilitar comunicação
interprocessos entre computadores remotos. Estas interfaces proporcionam portabilidade e
transparência.
Os middleware de comunicação podem ser de três tipos:
- Chamadas de Procedimento Remoto
- Comunicação orientada a Mensagens
- Comunicação orientada a fluxo
2.4.1. TIPOS DE COMUNICAÇÃO (MIDDLEWARE)
2.4.1.1. Quanto a Persistência
- Persistente: Mensagem é armazenada pelo middleware de comunicação durante o tempo
que for necessário para entregá-la ao receptor.
- Transiente: Mensagem é armazenada somente durante o tempo em que a aplicação
remetente e a aplicação receptora estiverem executando.
2.4.1.2. Quanto a Sincronização
- Assíncrona: O remetente continua sua execução imediatamente após ter apresentado
sua mensagem para transmissão
4
SISTEMAS DISTRIBUÍDOS
Prof. Ricardo Rodrigues Barcelar
http://www.ricardobarcelar.com.br
- Síncrona: O remetente é bloqueado até saber que sua requisição foi aceita. Durante a
comunicação o middleware avisa que se encarregará da transmissão. O bloqueio permanece até
que a requisição seja entregue ao receptor e o receptor retorne uma resposta.
2.4.1.3. Quanto a Granularidade
- Discreta: Partes se comunicam por mensagens e cada mensagem forma uma unidade de
informação completa.
- Fluxo: Várias mensagens, sendo que as mensagens estão relacionadas uma com as
outras pela ordem ou pela relação temporal.
2.5. Chamada de Procedimento Remoto (RPC)
A comunicação usando sockets é considerada uma forma de comunicação de baixo nível
entre processos ou threads distribuídos. Um dos motivos é que os sockets só permitem a troca de
um fluxo não estruturado de bytes entre os threads. É de responsabilidade da aplicação cliente ou
servidor impor uma estrutura aos dados.
Um método alternativo aos sockets é a chamada de procedimento remota, RPC. O RPC
permite a processos chamar procedimentos localizados em outros hosts. O desenvolvedor não
precisa se preocupar mais com detalhes de implementação de rede, ou seja, não é mais
necessária a utilização de sockets.
A vantagem de RPC ao Sockets é que RPC gerencia o canal de comunicação, por isso os
programas podem ser escritos de modo que a localização de um procedimento seja transparente;
Em tese tudo é muito simples, contudo este modelo implementa algumas complicações,
tais como:
- Arquiteturas de duas máquinas podem ser diferentes
- Espaços de endereçamentos diversos
- Passagem de parâmetros
A idéia básica por trás do RPC é fazer com que uma chamada de procedimento remoto
pareça com uma chamada local. Isto representa o princípio da transparência. Esta transparência é
alcançada por meio do uso de stubs.
O stub do cliente é responsável por empacotar os parâmetros em uma mensagem e enviar
a mensagem para a máquina do servidor. Quando a resposta chega, o resultado é copiado para o
cliente, e controle volta para o servidor.
- O stub do servidor é responsável por desempacotar parâmetros, chamar o procedimento
do servidor e retornar resposta para máquina do cliente.
5
SISTEMAS DISTRIBUÍDOS
Prof. Ricardo Rodrigues Barcelar
http://www.ricardobarcelar.com.br
Transporte de mensagens na rede
Figura 5 - Funcionamento do Stub
2.5.1. ETAPAS DO FUNCIONAMENTO DO RPC
- Um processo do cliente chama um procedimento local conhecido como stub cliente;
- O stub do cliente empacota as informações, constrói uma mensagem (marshaling) e
chama o Sistema Operacional;
- O Sistema Operacional envia a mensagem para Sistema Operacional remoto;
- O Sistema Operacional remoto repassa a mensagem para o stub do servidor;
- O stub do servidor desempacota parâmetros e chama procedimento servidor;
- O procedimento do servidor executa e retorna o resultado desejado;
- O stub do servidor empacota resultado em uma mensagem e chama o Sistema
Operacional;
- O Sistema Operacional remoto envia mensagem para Sistema Operacional da máquina
cliente;
- O Sistema Operacional do cliente passa a mensagem para stub cliente;
- O stub cliente desempacota resultado, repassando-o para o cliente.
A função do stub do cliente é pegar seus parâmetros, empacotá-los em uma mensagem e
enviá-los ao stub do servidor (montagem de parâmetros - parameter marshaling).
Em todo este processo os stubs interagem com o kernel dos sistemas operacionais na qual
estão hospedados os processos clientes.
6
SISTEMAS DISTRIBUÍDOS
Prof. Ricardo Rodrigues Barcelar
http://www.ricardobarcelar.com.br
Figura 6 - RPC entre um cliente e servidor
O conceito de chamada de Procedimento Remoto esconde todos os detalhes do código de
rede dentro dos procedimentos STUB.
Isso facilita aos programas de aplicações, cliente e servidor, e principalmente ao
programador, não precisar conhecer os detalhes de rede como: sockets, ordem de byte na rede,
dentre outros. Facilmente permite a construção de aplicações distribuídas.
RPC encontra-se entre a camada de aplicação e apresentação do modelo OSI.
2.5.2. PROBLEMAS
- O RPC trabalha com TCP ou UDP, logo diferentes níveis de confiabilidade.
- Como o processo de emissão da RPC e de seu correspondente Stub cliente reside em
diferentes espaços de endereçamento de memória a passagem de ponteiros como parâmetros é
dificultada, logo limitando a transparência e a capacidade da RPC.
- O desempenho e segurança levam ao desenvolvimento de protocolos adicionais, logo
não é uma boa solução para comunicação distribuída.
Em suma o RPC permite a um cliente o acesso a um serviço remoto por meio de uma
simples chamada a um procedimento local, possibilitando que programas clientes sejam escritos
de modo simples. Estes podem localizar automaticamente o servidor e estabelece a comunicação
entre software cliente e software servidor.
7
SISTEMAS DISTRIBUÍDOS
Prof. Ricardo Rodrigues Barcelar
http://www.ricardobarcelar.com.br
3. NOMEAÇÃO
O processo de nomeação é o principal responsável pela transparência nas comunicações
entre os nós de um sistema distribuído, uma vez que cada nó constitui uma entidade.
3.1. Nomes, Identificadores e Endereços
Em sistemas distribuídos entidades pode ser qualquer coisa, sejam elas máquinas,
impressoras, processos, usuários, páginas web, mensagens, etc.
3.1.1. ENDEREÇO
O acesso a uma entidade se dá através de um ponto de acesso, ou simplesmente,
endereço.
Exemplo:
Servidor e seu número IP
Um endereço pode ser utilizado como uma maneira de nomear, identificar uma entidade. O
problema é que uma entidade pode facilmente mudar seu ponto de acesso.
Dessa forma, para nomear entidades, sem utilizar especificamente seu endereço, ou seja,
nomeá-las independentemente da sua posição física (localização) deve usar identificadores ou
nomes amigáveis a seres humanos.
É comum estabelecer nomes de países, de jogadores de futebol do passado ou de deuses
mitológicos. É mais fácil ao usuário entender que “Afrodite” não está disponível do que
“XPTO001X” está indisponível.
3.1.2. IDENTIFICADORES
Os identificadores são cadeias aleatórias de bits, com algumas propriedades:
- Um identificador referencia, no máximo, 01(uma) entidade;
- Cada entidade é referenciada por, no máximo, um identificador;
- Um identificador sempre referencia a mesma entidade, isto é, nunca é reutilizado.
Exemplo:
Identificadores de entidades em sistemas P2P baseados no sistema Chord.
3.1.3. NOMES AMIGÁVEIS
São nomes representados por uma cadeia de caracteres, como pathnames, domínios de
Internet, números de processos, etc.
8
SISTEMAS DISTRIBUÍDOS
Prof. Ricardo Rodrigues Barcelar
http://www.ricardobarcelar.com.br
Exemplo:
http://www.ricardobarcelar.com.br
Diante desses conceitos é necessário resolver a questão dos nomes e identificadores para
endereços. Solução para isto é a utilização de um Sistema de Nomeação.
3.2. Sistema de Nomeação
Um sistema de nomeação, em princípio mantém uma vinculação nome-endereço que na
forma mais simples é uma tabela de pares (nome, endereço). Contudo, em sistemas que
abrangem redes de grande porte, uma tabela centralizada não vai funcionar devido aos muitos
recursos a nomear.
Existem três classes diferentes de nomeação:
- Nomeação Simples
- Nomeação Estruturada
- Nomeação Baseada em Atributo
3.2.1. NOMEAÇÃO SIMPLES
A nomeação simples é aplicada a identificadores. São representados por cadeias
aleatórias de bits, conhecidos como nomes simples. Estes nomes não contêm sequer uma
informação sobre como localizar o ponto de acesso de uma entidade associada, tornando-se um
problema na localização do ponto de acesso (endereço).
Para localizar uma entidade quando se tem somente o nomes simples em redes locais é
possível utilizar soluções como:
- Broadcasting e multicasting
- Localização Nativa
- Tabelas de Hash Distribuídas (DHT)
3.2.1.1. Broacasting e multicasting
São aplicáveis somente a redes locais. Seu funcionamento consiste em enviar uma
mensagem broadcast que contém o identificador da entidade. Máquinas com ponto de acesso
para a entidade enviam uma mensagem que contém o endereço procurado.
Essa estratégia é ineficiente quando a rede cresce, visto que largura de banda da rede é
desperdiçada, e com grande número de mensagens de requisição aumenta a probabilidade de
colisões de mensagens, diminuindo o throughput do sistema.
O multicast também pode ser utilizado para localizar entidades em uma rede ponto-aponto, na qual somente um grupo restrito de máquinas recebe a requisição como, por exemplo,
em um banco de dados replicado.
Um endereço multicast pode também estar associado a uma entidade replicada, na qual
para cada requisição para o endereço multicast, a réplica responde com seu endereço IP.
9
SISTEMAS DISTRIBUÍDOS
Prof. Ricardo Rodrigues Barcelar
http://www.ricardobarcelar.com.br
Figura 7 - Multicast
3.2.1.2. Localização Nativa
Outra solução é a localização nativa, que consiste em uma abordagem para suportar
entidades móveis em redes de grande escala. Nesta solução é monitorada a localização corrente
de uma entidade.
Um exemplo em que a abordagem da localização nativa é usada é em Mobile IP. Nesta
abordagem cada host móvel usa um endereço fixo e toda a comunicação é dirigida inicialmente ao
agente nativo do host móvel (situado na rede local do endereço do host). Ao mudar de rede, o
host recebe um endereço externo (care-of-adress) e registra no agente nativo. Quando o agente
nativo recebe um pacote para o host móvel ele consulta a localização corrente do hospedeiro. Se
estiver na rede local o pacote repassado, senão o pacote é envida por um túnel até a localização
corrente do hospedeiro.
10
SISTEMAS DISTRIBUÍDOS
Prof. Ricardo Rodrigues Barcelar
http://www.ricardobarcelar.com.br
Figura 8 – Princípio do Mobile IP
As desvantagens dessa estratégia é que para se comunicar com uma entidade móvel, em
primeiro lugar um cliente tem que contatar a localização nativa, que pode estar em um lugar
completamente diferente gerando grande latência de comunicação.
3.2.1.3. Tabelas de hash distribuídas (DHT)
Esta é outra forma de resolver um identificador para o endereço da entidade associada.
Este modelo é bem representado pelo sistema Chord, na qual existem “nós” organizados
logicamente em um anel. O sistema Chord é extremamente simples no que se refere à
funcionalidade que provê. A única função que oferece é mapear chaves e seus respectivos objetos
em nós do sistema.
O sistema Chord usa um espaço de identificadores de m1 bits para designar nós e
entidades específicas (arquivos, processos). Assim, uma entidade com chave k cai sob a
jurisdição do nó que tenha o menor identificador id >= k. Esse nó é denominado sucessor de k e
denotado por succ(k).
Para resolver com eficiência uma chave k para o endereço de succ(k) utiliza-se uma das
abordagens abaixo:
- Abordagem linear: Cada nó p monitora o sucessor succ(p+1) e o predecessor pred(p).
Ao receber uma requisição para a chave k, p repassa a requisição para os seus vizinhos, a menos
que pred(p) < k <= p, caso em que o nó p retorna o próprio endereço.
Esta é uma estratégia não escalável.
1
Número m bits é usualmente 128 ou 160
11
SISTEMAS DISTRIBUÍDOS
Prof. Ricardo Rodrigues Barcelar
http://www.ricardobarcelar.com.br
Caso 1) Suponhamos que p = 4 receba uma requisição para k = 7 → succ(p+1) → repassa
a requisição ao nó = 9.
Caso 2) Suponhamos que p = 4 receba uma requisição para k = 3 → como pred(4) = 1<
3<=4 → retorna o próprio endereço.
Figura 9 – Sistema Chord
- Tabela de Derivação (Finger Table): Diferente da abordagem linear para a consulta de
chaves, cada nó Chord mantém uma tabela de derivação de no máximo, m entradas.
Denotando a tabela de derivação de p por Ftp, temos: Ftp[i]=succ(p+2 i -1), ou seja, a iésima entrada aponta para o primeiro nó que sucede p por no mínimo 2 i -1.
Para encontrar uma entidade k, as referências na tabela de derivação são usadas como
atalhos para nós existentes no espaço de identificadores. A distância do atalho em relação ao nó
p aumenta exponencialmente à medida que o índice na tabela de derivação cresce. Para
consultar uma chave k, o nó p repassará a requisição ao nó q com índice j na tabela de derivação
de p, ou seja, q = Ftp [ j ] <= k <= Ftp [j+1]
Exemplo:
Considere a resolução de k=26, a partir do nó 1.
1) Nó 1 consultará k=26 → verifica que o valor é maior do que FT1[5].
2) Requisição será repassada para o nó 18.
12
SISTEMAS DISTRIBUÍDOS
Prof. Ricardo Rodrigues Barcelar
http://www.ricardobarcelar.com.br
3) O nó 18 selecionará o nó 20, porque FT18[2] < k<= FT18[3].
4) Por fim, requisição é repassada do nó 20 para o nó 21 e deste para 28
O problema dessa solução é que a organização lógica dos nós em uma rede de
sobreposição (orvelay) pode levar a uma escolha errada no roteamento de mensagens, portanto k
e succ(k+1) podem estar muito longe fisicamente.
Existem três solução para este problema, a saber:
- Identificar nós com base na topologia, de modo que dois nós próximos tenham
identificadores que também estejam próximos um do outro.
- Roteamento por proximidade que consiste em manter mais de um sucessor e repassar a
requisição para o mais próximo.
- Seleção de vizinho por proximidade. Ao escolher um vizinho (não em Chord), pegue o
mais próximo.
3.2.2. NOMEAÇÃO ESTRUTURADA
Nomes simples são bons para máquinas, mas não são convenientes para a utilização de
seres humanos. Como alternativa os sistemas de nomeação comumente suportam nomes
estruturados.
Exemplo:
Nomeação de arquivos, hosts na Internet
Nomes são organizados em um espaço de nomes que podem ser representados como
um grafo dirigido, com dois tipos de nós:
- Nó-folha: contém informações da entidade
- Nó de diretório: entidade que se refere a outros nós
Cada nó de diretório possui uma tabela de diretório<nome aresta, nome nó>.
Figura 10 – Gráfico de nomeação geral com um único nó-raiz
Sistemas de nomeação possuem, na maioria, um nó raiz, onde cada caminho no grafo de
nomeação pode ser referenciado pela sequência dos labels nas arestas.
N:<label1, label2, ..., labeln>
13
SISTEMAS DISTRIBUÍDOS
Prof. Ricardo Rodrigues Barcelar
http://www.ricardobarcelar.com.br
Onde N se refere ao primeiro nó do caminho. Tal sequência é denominado nome de caminho, que
pode ser:
- Nome de caminho absoluto: primeiro nó no caminho é a raiz
- Nome de caminho relativo: primeiro nó pode ser qualquer nó.
3.2.2.1. Resolução de nomes
Os espaços de nomes oferecem um mecanismo para armazenar e recuperar informações
sobre entidades por meio de nomes. Dado um nome de caminho, deve ser possível consultar
qualquer informação armazenada no nó referenciado por aquele nome.
O problema é que para resolver um nome, precisa-se de um nó de diretório inicial. Para
isso existem algumas soluções:
- Mecanismo de fechamento: Trata da seleção do nó inicial em um espaço de nomes a
partir do qual a resolução de nomes deve começar.
Exemplo:
- www.ricardobarcelar.com.br: início da resolução é feito através do servidor de nome DNS
- /home/publico/arquivos: início da resolução ocorre no servidor local NFS
Vide Figura 10 – Gráfico de nomeação geral com um único nó-raiz
3.2.2.2. Alias (Apelidos)
Define outro nome para a mesma entidade, ou seja, vários nomes absolutos para o mesmo
nó (hard link).
Exemplo:
O nome de caminho /home/steen/Keys, que referencia um nó que contém o nome de
caminho absoluto /Keys.
Vide Figura 10 – Gráfico de nomeação geral com um único nó-raiz
3.2.2.3. Implementação de um Espaço de Nomes
Este é um serviço que permite que usuários e processo adicionem, removam e consultem
nomes. Um serviço de nomeação é implementado por servidores de nomes e devem prover:
- Escalabilidade
- Manutenção descentralizada
- Tolerância a falhas, robustez
- Escopo global: Nomes possuem o mesmo significado em todos os lugares
Um espaço de nomes, em geral, é organizado em hierarquia de três camadas:
- Camada global (Raiz e seus filhos)
- Camada administrativa (Nós de diretórios)
- Camada gerencial (Mantido por administradores e usuários finais)
14
SISTEMAS DISTRIBUÍDOS
Prof. Ricardo Rodrigues Barcelar
http://www.ricardobarcelar.com.br
Figura 11 - Repartição do espaço de nomes DNS
A resolução de nomes pode ser:
- Resolução Iterativa: servidor responde somente o que sabe: o nome do próximo
servidor que deve ser buscado. O cliente procura iterativamente os outros servidores.
- Resolução Recursiva: servidor passa o resultado para o próximo servidor que encontrar.
Para o cliente, existe somente uma mensagem de retorno: o endereço do nome ou 'não
encontrado'.
Figura 12 – Comparação entre resolução recursiva e iterativa de nomes
3.2.2.3. Domain Name System (DNS)
O DNS é usado para realizar o mapeamento entre nome e endereço IP. Para isso ele
utiliza uma base de dados distribuída implementada na hierarquia de muitos servidores de
15
SISTEMAS DISTRIBUÍDOS
Prof. Ricardo Rodrigues Barcelar
http://www.ricardobarcelar.com.br
nomes. O protocolo da camada de aplicação permite que hospedeiros, roteadores, servidores de
nomes e comuniquem para resolver nomes (tradução endereço/nome).
A razão de não se centralizar o DNS é não impor um ponto único de falha, diminuir o
volume de tráfego, evitar base de dados centralizada e distante e proporcionar uma melhor
manutenção da base de dados, além do que possibilita uma estrutura escalável.
Figura 13 – Base de dados Hierárquica e distribuída
Se procurado no servidor local não for possível resolver o nome, a requisição deverá ser
remetida ao servidor raiz. Este é responsável por:
- procurar o servidor oficial se o mapeamento for desconhecido
- obter a tradução
- devolver o mapeamento ao servidor local
São 13 os servidores raiz “espalhados” pelo mundo.
Figura 14 – Servidores raiz
16
SISTEMAS DISTRIBUÍDOS
Prof. Ricardo Rodrigues Barcelar
http://www.ricardobarcelar.com.br
3.2.3. NOMEAÇÃO BASEADA EM ATRIBUTO
Este modelo descreve uma entidade em termos de pares <atributo, valor>.
A premissa é que uma entidade tem um conjunto associado de atributos. Quando um
usuário especifica quais valores um determinado atributo deve ter, ele restringe o conjunto de
entidades nas quais está interessado.
Cabe ao sistema de nomeação retornar uma ou mais entidades que atendam à descrição
do usuário.
Sistemas de nomeação baseado em atributos também são conhecidos como serviços de
diretórios.
Uma abordagem comum para tratar serviços distribuídos de diretórios é combinar
nomeação estruturada com nomeação baseada em atributos. Esta abordagem tem sido adotada
no serviço Active Diretory da Microsoft. Muitos desses sistemas usam, ou dependem, do protocolo
leve de acesso a diretório (Lightwight Diretory Access Protocol – LDAP).
3.2.3.1. LDAP
O LDAP é um protocolo padrão IETF, projetado para operar em Internet. Sua definição
considera o LDAP como um gateway para os servidores de diretório X.500. Pelo fato de utilizar a
pilha TCP/IP, em lugar da mais complexa pilha OSI, permite uma implementação mais eficiente e
simplificada de forma a poder executar em máquinas de diferentes portes, tais como PCs, PDAs,
equipamentos Wireless, entre outros.
O LDAP torna possível gerenciar usuários, grupos, dispositivos, e outros objetos, evitando
a necessidade de gerenciar aplicações de diretórios específicos (tais como de correio eletrônico).
É um padrão suportado por diferentes plataformas que torna a aplicação independente de
fabricantes ou plataformas específicas de sistema operacional ou rede.
Reduz o custo pelo fato de diminuir o número de diretórios distintos a serem gerenciados e
economiza tempo de desenvolvimento pelo fato de não ser necessário construir bases de dados
específicas para gerenciamento de usuários e grupos.
O LDAP cria 4 (quatro) modelos:
- Modelo de informação: define os tipos de dados que podem ser colocados no diretório.
- Modelo de nomes: define como os dados do diretório são organizados e referenciados.
- Modelo funcional: define como acessar e atualizar as informações no diretório.
- Modelo de segurança: define como as informações no diretório são protegidas de
acessos não autorizados.
Este modelo ainda define uma forma de referenciarmos as informações, assim, uma
entrada possui somente um único nome dado por um DN (Distinguished names). Um DN é uma
concatenação de RDN (Relative Distinguished names), por exemplo, um DN poderia ser expresso
como: OU = Recursos, Ou = Servidores, Cn = Web Server. Um RDN para o DN acima poderia ser
Ou = Recursos ou Cn = Web Server.
Eis uma série de chaves geralmente utilizadas:
- uid (userid): identificador único obrigatório
- cn (common name): apelido da pessoa
- givenname: nome
- Sn (surname): apelido da pessoa
17
SISTEMAS DISTRIBUÍDOS
Prof. Ricardo Rodrigues Barcelar
http://www.ricardobarcelar.com.br
- o (organization): empresa da pessoa
- u (organizational unit): serviço da empresa na qual a pessoa trabalha
- mail: endereço de correio eletrônico da pessoa
Figura 15 - Árvore LDAP
18