Visão Geral da camada de sessão
—O primeiro problema é que suas mensagens podem se cruzar durante a conversação. Vocês dois podem digitar mensagens exatamente ao mesmo tempo, interrompendo um ao outro. O segundo problema é a necessidade de interromper (para salvar a conversação atual como um arquivo) ou de verificar a conversação anterior de cada um (para obter pistas da razão da discussão), ou de ressincronizar a comunicação depois de uma interrupção.
— Para resolver o primeiro problema, você deve estabelecer um protocolo, ou um conjunto de protocolos, que ditem as regras de comunicação entre vocês. Isso significa que cada um de vocês deve concordar com um conjunto de regras a serem usadas durante a conversação (ex.: o revezamento no envio de mensagens para evitar que um interrompa o outro). Isso é conhecido como comunicação alternada de mão dupla. Outra solução é que cada pessoa digite suas mensagens sempre que desejar, independentemente de quem está transmitindo, e você presume que mais informações estejam sempre a caminho. Isso é conhecido como comunicação simultânea de mão dupla.
—Para resolver o segundo problema, cada um deve enviar ao outro um ponto de verificação, o que significa que cada pessoa deve salvar a conversação como um arquivo. Depois, cada pessoa deve reler a última parte de sua conversação e verificar a hora no relógio. Isso é conhecido como sincronização.
—Dois pontos de verificação muito importantes são como a c

Visão Geral da camada de sessão
—O primeiro problema é que suas mensagens podem se cruzar durante a conversação. Vocês dois podem digitar mensagens exatamente ao mesmo tempo, interrompendo um ao outro. O segundo problema é a necessidade de interromper (para salvar a conversação atual como um arquivo) ou de verificar a conversação anterior de cada um (para obter pistas da razão da discussão), ou de ressincronizar a comunicação depois de uma interrupção.
— Para resolver o primeiro problema, você deve estabelecer um protocolo, ou um conjunto de protocolos, que ditem as regras de comunicação entre vocês. Isso significa que cada um de vocês deve concordar com um conjunto de regras a serem usadas durante a conversação (ex.: o revezamento no envio de mensagens para evitar que um interrompa o outro). Isso é conhecido como comunicação alternada de mão dupla. Outra solução é que cada pessoa digite suas mensagens sempre que desejar, independentemente de quem está transmitindo, e você presume que mais informações estejam sempre a caminho. Isso é conhecido como comunicação simultânea de mão dupla.
—Para resolver o segundo problema, cada um deve enviar ao outro um ponto de verificação, o que significa que cada pessoa deve salvar a conversação como um arquivo. Depois, cada pessoa deve reler a última parte de sua conversação e verificar a hora no relógio. Isso é conhecido como sincronização.
—Dois pontos de verificação muito importantes são como a conversação se inicia e como termina. Isso é conhecido como início ordenado e término da conversação. Por exemplo, quando você usa o Instant Mail ou o Internet Relay Chat, geralmente se despede da outra pessoa antes de terminar a sessão. A outra pessoa percebe então que você está terminando a sessão.
Imagen
Analogias da camada de sessão

Controle de diálogos
··

A camada de sessão decide entre usar a conversação simultânea de mão dupla ou a comunicação alternada de mão dupla. Essa decisão é conhecida como controle de diálogo. Se a comunicação simultânea de mão dupla for permitida, a camada de sessão fará pouco para gerenciar a conversação. Nesses casos, outras camadas dos computadores que estão se comunicando gerenciam a conversação. É possível ter colisões na camada de sessão, embora isso seja muito diferente das colisões nos meios que ocorrem na camada 1. Nesse nível, as colisões podem apenas ocorrer quando duas mensagens se cruzam e causam confusão em cada um ou nos dois hosts que estão se comunicando.
·Se as colisões da camada de sessão forem intoleráveis, o controle de diálogo terá outra opção: a comunicação alternada de mão dupla. A comunicação alternada de mão dupla envolve o uso de um token de dados da camada de sessão, que permite a cada host ter sua vez. Isso é semelhante à forma como uma token ring da camada 2 lida com as colisões da camada 1.
··Separação de diálogos
··A separação de diálogo é o início, término e gerenciamento ordenados de comunicação. A figura principal ilustra uma sincronização secundária. No "Eixo Tempo, t = ponto de verificação", a camada de sessão do host A envia uma mensagem de sincronização para o host B, tempo no qual os dois hosts executam a rotina a seguir:
··Fazem backup de arquivos específicos
·Salvam configurações de rede
·Salvam configurações de relógio
·Tomam nota do nó de extremidade na conversação
··Uma sincronização principal envolveria mais etapas e conversação de ida e volta do que a mostrada neste diagrama.
··O ponto de verificação é semelhante à forma como um processador de textos em um computador stand-alone é interrompido por um instante quando ele executa um salvamento automático do documento atual. No entanto, esses pontos de verificação são usados, em vez disso, para separar as partes de uma sessão anteriormente referida como diálogos.
··Imagen
··Network File System (NFS)
··O NFS (Network File System) é um sistema de arquivo distribuído que provê acesso transparente a discos remotos. Este serviço permite centralizar a administração dos discos, assim como o NIS permite a administração centralizada das informações dos usuários e dos hosts.
·Ao invés de duplicação de diretórios comuns como o /usr/local em cada sistema, o NFS oferece compartilhamento de uma única cópia do diretório entre todos os sistemas da rede.
·Na visão do usuário, a utilização do NFS significa não ter que se logar em cada sistema para acessar os arquivos. Eles não precisam utilizar o comando rcp (remote copy) ou fitas para transferir arquivos entre sistemas locais. O NFS garante que os arquivos necessários aos usuários são acessíveis de qualquer host da rede.
·O NFS é construído sobre um protocolo RPC e impõe o relacionamento cliente/servidor aos hosts que o utilizam.
· Um servidor NFS é um host que possui um ou mais sistemas de arquivos e os torna disponível pela rede.
·O cliente NFS monta estes sistemas de arquivos de um ou mais servidores.
·Um cliente NFS pode ser uma máquina diskless. E este é provavelmente o maior problema que o NFS encontra, pois não é trivial disponibilizar uma máquina sem qualquer recurso local como sendo um membro de uma rede funcionando completamente bem, além da integração desta máquina com outros servidores como o do NIS.
··Características do NFS
··Stateless - O NFS é um sistema de arquivo distribuído que mantêm o estado corrente de um ambiente, mesmo quando diante de um break do sistema. Quando o servidor NFS volta a funcionar corretamente, o estado anterior é restaurado e o funcionamento continua como se não houvesse ocorrido nenhuma pausa.
·Caching - A caching de dados permite que as informações utilizadas mais recentemente, sejam alocadas para posterior uso, ou ainda, pode vir a carregar os dados em antecipação a operações futuras. Por exemplo, os dados lidos a partir de um disco podem ser mantidos até uma subseqüente escrita destes dados. No NFS a caching de dados significa não ter que enviar requisições RPC através da rede para um servidor. Ou seja, os dados são armazenados na memória do cliente NFS, e quando solicitados são buscados localmente, não executando portanto acesso ao disco remoto.
·File Locking - Esta característica, permite que um processo tenha acesso exclusivo a um arquivo ou parte deste, e força outros processos que estão solicitando acesso ao mesmo arquivo, aguardarem a liberação.
··VFS (Virtual File System) e Protocolo NFS
··Um sistema de arquivo montado via NFS apresenta dois níveis de transparência:
··O sistema de arquivo parece residir em um disco acoplado ao sistema local, e todas as entradas deste sistema de arquivo, arquivos e diretórios, são vistas do mesmo modo, tanto local como remotamente.
·Os sistemas de arquivos NFS não contêm informações sobre o servidor de arquivos do qual eles foram montados. O servidor de arquivos NFS pode ser de uma arquitetura diferente ou executar um sistema operacional completamente diverso, com uma estrutura de sistemas de arquivos radicalmente diferente. O NFS esconde as diferenças na estrutura de sistemas de arquivos básica e faz o sistema de arquivo remoto apresentar a mesma estrutura do cliente.
··Transparência do NFS
··O segundo nível de transparência surgi a partir da definição de virtual nodes, que estão mais relacionados a estrutura dos inodes do UNIX, mas esconde a estrutura real do sistema de arquivo físico abaixo dele. O conjunto de todos os procedimentos que podem ser executados sobre os arquivos, é a definição da interface vnode. A especificação do vnode e do VFS definem o protocolo NFS.
·Ações que operam no sistema de arquivos como um todo, tais como informar a quantidade de espaço livre em um sistema de arquivo, são chamadas operações VFS; enquanto que chamadas que atuam diretamente com os arquivos ou diretórios, são operações vnode. Algumas operações vnode não são definidas em certos tipos de sistemas de arquivos. Os sistemas de arquivos DOS, por exemplo, não possui qualquer equivalência a links simbólicos. Sendo assim, um servidor de arquivos NFS executando sobre uma máquina DOS rejeita qualquer tentativa de utilizar uma operação vnode para criar um link simbólico.
··Protocolo NFS
··O NFS é um protocolo baseado em RPC, com um relacionamento cliente/servidor entre a máquina que possui um sistema de arquivo a ser distribuído e a máquina que aguarda o acesso a estes sistemas de arquivos.
·O daemon do servidor NFS é o nfsd (Unix), aceita as chamadas RPC dos clientes. Os servidores NFS também executam o daemon rpc.mountd para tratar das requisições de montagem dos sistemas de arquivos e algumas traduções de caminhos completos.
·No cliente NFS, o daemon biod está normalmente em execução para melhorar a performance do NFS, apesar de não ser imprescindível.
·No cliente, cada processo que está utilizando os arquivos NFS é um cliente do servidor. As chamadas de sistema dos clientes que acessam os arquivos montados via NFS fazem chamadas RPC aos servidores NFS dos arquivos que foram montados. O VFS estende as operações das chamadas de sistema básicas a operações read( ) e write( ). Com o VFS as chamadas de sistema básicas e aquelas orientadas a sistemas de arquivos são modificadas para conhecerem como tratar com sistemas de arquivos não locais.
··Procedimentos RPC do NFS
··O protocolo RPC NFS contêm 16 procedimentos, cada um deles operam ou com arquivos ou sistemas de arquivos. Os procedimentos básico executados no servidor NFS podem ser agrupados em:
··Operações de diretórios
··mkdir -> Cria um diretório;
·Rmdir -> Destrói um diretório;
·readdir -> Lê um diretório;
·Rename -> Renomeia um diretório;
·remove -> Remove um diretório;
·Create -> Cria um diretório;
·lookup -> é de fundamental importância no mecanismo de tradução do caminho completo no handle do arquivo. Ela procura pelo nome do diretório e retorna o handle que aponta para ele.
··Operações de arquivos - estão diretamente associadas as chamadas de sistema do UNIX:
·· read e write -> movem os dados para e dos clientes NFS,
·getattr e setattr -> configuram ou modificam atributos dos arquivos.
··Operações de link - incluem link, o qual cria um hard link no servidor:
··symlink e readlink -> criam e lêem os valores de links simbólicos, respectivamente.
··Operações de sistemas de arquivos:
··statfs -> retorna informações sobre os sistemas de arquivos montados.
··Outras operações de sistemas de arquivos incluem montagem e desmontagem de um sistema de arquivo, mas estas são tratadas pelo daemon rpc.mountd ao invés do daemon RPC nfsd. As operações de montagem são separadas do protocolo NFS pois os pontos de montagem envolvem resolução de caminhos completos, e a sintaxe destes é peculiar a cada sistema operacional.
··RPC NFS X interface vnode
··A interface vnode define um conjunto de serviços do sistema operacional que são usadas para acessar os sistemas de arquivos, NFS ou locais.
· Vnodes simplesmente generaliza a interface para objetos de arquivo. Existem muitas rotinas na interface vnode que correspondem diretamente a procedimentos no protocolo NFS, mas ela também contém implementações dos serviços do sistema operacional tal como mapeamento dos blocos de arquivos e gerenciamento de cache.
··Stateless
··O protocolo NFS é stateless, significando que não há necessidade de manter informações sobre o protocolo no servidor. O cliente mantém trilhas de todas as informações necessárias para enviar uma requisição ao servidor, mas o servidor não possui informações sobre requisições prévias, ou como as várias requisições se relacionam.
·A escolha de um protocolo stateless vem de uma motivação principal, que é minimizar a sobrecarga quando da recuperação de um estado inativo. E isto implica em várias questões de design e implementação:
··Requisições RPC NFS devem descrever por completo as operações a serem executadas. Por exemplo, a escrita de um bloco de arquivo deve conter o handle do arquivo, o offset, e o comprimento da operação de escrita.
·Muitas requisições NFS são indepotentes, ou seja, um cliente NFS pode enviar mais de uma vez a mesma requisição sem qualquer efeito nocivo. Por exemplo, a leitura de um bloco de dados terá a mesma saída independente do número de vezes que é executada tal operação. Contudo, algumas operações não são indepotentes, como por exemplo, a remoção de um arquivo.
·Pelo fato das requisições poderem ser repetidas e as informações de estado serem proibidas, o NFS utiliza um protocolo de transporte de suas requisições RPC não confiável, o UDP (User Datagram Protocol). O UDP é um protocolo stateless não prometendo qualquer garantia da entrega dos pacotes, nem da ordem da entrega. Os servidores NFS notificam aos clientes quando uma chamada RPC é completada através do envio de um reconhecimento, também utilizando UDP.
··Retransmissão de requisições
··Quando um cliente solicita uma requisição RPC, ele inicializa um período de timeout durante o qual o servidor deve servir e reconhecer esta requisição. Se algum problema ocorreu e o servidor não atendeu a requisição dentro do intervalo de tempo determinado, ou por tê-la perdido, ou por sobrecarga no servidor, o cliente retransmite a requisição. Porém, se a operação houver sido executada e o atraso foi o envio do reconhecimento, pelo fato das requisições serem indepotentes, não haverá problemas com a duplicação de requisições (isto se o servidor possuir cache de requisições duplicadas). Quando o cliente receber a segunda confirmação, ele a descarta.
··Remote Procedure Call
··A Sun Microsystems desenvolveu o RPC na década de 80 com o objetivo de permitir o desenvolvimento de aplicações cliente/servidor sem necessidade de programar com interfaces sob a camada de transporte como, por exemplo, sockets.
·Desvantagens do Socket:
··- Abordagem orientada a Comunicação;
·- A aplicação não recebe atenção exclusiva;
··No paradigma cliente-servidor, os usuários interagem com aplicações que podem ser clientes de outros serviços disponíveis no sistema.
· Cada serviço provê uma série de operações que podem ser invocadas pelos clientes.
· A comunicação entre clientes e servidores se dá através de um mecanismo do tipo send/receive (request/reply).
·O mecanismo de Remote Procedure Calls (RPC), portanto, vem justamente introduzir uma abstração maior nesse cenário, permitindo que os clientes solicitem tarefas aos servidores simplesmente fazendo chamadas remotas a procedimentos, de uma maneira semelhante à que é utilizada em linguagens de alto nível convencionais.
·Dessa forma, um serviço disponível através da rede apresenta-se a seus clientes como um módulo que possui uma interface bem definida de acesso a suas operações, interface esta constituída pelos procedimentos. Isto não só dá uma maior uniformidade de acesso às suas funções, escondendo detalhes de implementação das mesmas, mas também aumenta a segurança do sistema e, evidentemente, sua transparência.
·Os clientes, então, obtêm serviços enviando uma mensagem a um determinado servidor, o qual executa a solicitação e envia uma mensagem de resposta ao cliente, comunicando o resultado da mesma e, eventualmente, mais alguns parâmetros.
·O cliente, normalmente, fica bloqueado enquanto seu pedido está sendo executado, dando prosseguimento às suas tarefas quando chega a mensagem de resposta.
·Todo este processo de enviar mensagens, bloquear-se, aguardar pela conclusão do serviço, etc., é um pouco complicado e exige um certo grau de conhecimento do programador, além de não ser transparente, pois é preciso se preocupar com protocolos utilizados, acknowledgements, sockets e outras coisas mais, não sendo isto nem um pouco trivial para a maioria das pessoas.
··Objetivo: Tornar mais fácil a implementação de Aplicações Distribuídas
·Esconde o código de chamadas a rede em procedimentos chamados stubs
· Stubs -> procedimentos que contêm o código de chamadas a rede.
· Com stubs o RPC protege os programas de aplicação (cliente e servidor) de preocupações com detalhes como sockets.
·O RPC inclui uma especificação para formato padrão dos dados (visando interoperabilidade), e nos stubs é que acontece a conversão dos dados
··No RPC da Sun o padrão para a representação dos dados é o XDR (eXternal Data Representation Standard)
·Os stubs são gerados automaticamente por algum compilador.
··Exemplo: O RPCGen da Sun
··Processamento no Adaptador Cliente
··Pedido:
··constrói a mensagem (parameter marshalling);
·envia-a (p.ex. usando sendto()) para o servidor;
· bloqueia à espera da resposta (p.ex. usando recvfrom()).
··Resposta:
··recebe a resposta;
· extrai os resultados (unmarshalling);
· retorna-os ao cliente.
··Pedido:
··recebe mensagem com pedido;
·extrai argumentos;
·invoca a função.
··Resposta:
··constrói mensagem com resultado da invocação da função;
·envia mensagem;
· bloqueia à espera de novo pedido.
··Chamadas Remotas de Procedimentos (RPC).
··Idéia do modelo é estender o conceito de chamada de procedimento convencional para ambientes distribuídos.
·· a ênfase é em distribuição e não em concorrência!
· objetivo é simplificar a programação distribuída, tornando-a semelhante à programação convencional!
··Remote Procedure Call (RPC): subrotina chamada pode ser função ou procedimento
·Procedimentos => permitem a divisão do programas em vários pedaços que podem executar em máquinas arbitrárias.
··RPC - Implementação
··O código das chamadas a rede é escondido em procedimentos chamados stubs
·· Stubs -> procedimentos que contêm o código de chamadas a rede.
·Com stubs o RPC protege os programas de aplicação (cliente e servidor) de preocupações com detalhes como sockets.
··Cabe aos stubs a passagem de parâmetros entre procedimentos.
··Máquinas diferentes podem usar representações diferentes de dados como inteiros, caracteres, etc.
·O que fazer com dados complexos, como listas, etc?
··Transparência: Heterogeneidade do Hardware
··Problema: pelo menos dois:
··diferentes arquiteturas usam diferentes formatos de representação:
··complemento para 1 vs. complemento para 2;
·big endian vs. little endian;
·ASCII vs. EBCDIC;
·vírgula flutuante: IEEE 754 vs.
··representação de estruturas de dados complexas pode diferir entre compiladores.
··Solução: essencialmente duas:
··conversão entre 2 formatos só;


onversação se inicia e como termina. Isso é conhecido como início ordenado e término da conversação. Por exemplo, quando você usa o Instant Mail ou o Internet Relay Chat, geralmente se despede da outra pessoa antes de terminar a sessão. A outra pessoa percebe então que você está terminando a sessão.
Imagen
Analogias da camada de sessão

Controle de diálogos
··A camada de sessão decide entre usar a conversação simultânea de mão dupla ou a comunicação alternada de mão dupla. Essa decisão é conhecida como controle de diálogo. Se a comunicação simultânea de mão dupla for permitida, a camada de sessão fará pouco para gerenciar a conversação. Nesses casos, outras camadas dos computadores que estão se comunicando gerenciam a conversação. É possível ter colisões na camada de sessão, embora isso seja muito diferente das colisões nos meios que ocorrem na camada 1. Nesse nível, as colisões podem apenas ocorrer quando duas mensagens se cruzam e causam confusão em cada um ou nos dois hosts que estão se comunicando.
·Se as colisões da camada de sessão forem intoleráveis, o controle de diálogo terá outra opção: a comunicação alternada de mão dupla. A comunicação alternada de mão dupla envolve o uso de um token de dados da camada de sessão, que permite a cada host ter sua vez. Isso é semelhante à forma como uma token ring da camada 2 lida com as colisões da camada 1.
··Separação de diálogos
··A separação de diálogo é o início, término e gerenciamento ordenados de comunicação. A figura principal ilustra uma sincronização secundária. No "Eixo Tempo, t = ponto de verificação", a camada de sessão do host A envia uma mensagem de sincronização para o host B, tempo no qual os dois hosts executam a rotina a seguir:
··Fazem backup de arquivos específicos
·Salvam configurações de rede
·Salvam configurações de relógio
·Tomam nota do nó de extremidade na conversação
··Uma sincronização principal envolveria mais etapas e conversação de ida e volta do que a mostrada neste diagrama.
··O ponto de verificação é semelhante à forma como um processador de textos em um computador stand-alone é interrompido por um instante quando ele executa um salvamento automático do documento atual. No entanto, esses pontos de verificação são usados, em vez disso, para separar as partes de uma sessão anteriormente referida como diálogos.
··Imagen
··Network File System (NFS)
··O NFS (Network File System) é um sistema de arquivo distribuído que provê acesso transparente a discos remotos. Este serviço permite centralizar a administração dos discos, assim como o NIS permite a administração centralizada das informações dos usuários e dos hosts.
·Ao invés de duplicação de diretórios comuns como o /usr/local em cada sistema, o NFS oferece compartilhamento de uma única cópia do diretório entre todos os sistemas da rede.
·Na visão do usuário, a utilização do NFS significa não ter que se logar em cada sistema para acessar os arquivos. Eles não precisam utilizar o comando rcp (remote copy) ou fitas para transferir arquivos entre sistemas locais. O NFS garante que os arquivos necessários aos usuários são acessíveis de qualquer host da rede.
·O NFS é construído sobre um protocolo RPC e impõe o relacionamento cliente/servidor aos hosts que o utilizam.
· Um servidor NFS é um host que possui um ou mais sistemas de arquivos e os torna disponível pela rede.
·O cliente NFS monta estes sistemas de arquivos de um ou mais servidores.
·Um cliente NFS pode ser uma máquina diskless. E este é provavelmente o maior problema que o NFS encontra, pois não é trivial disponibilizar uma máquina sem qualquer recurso local como sendo um membro de uma rede funcionando completamente bem, além da integração desta máquina com outros servidores como o do NIS.
··Características do NFS
··Stateless - O NFS é um sistema de arquivo distribuído que mantêm o estado corrente de um ambiente, mesmo quando diante de um break do sistema. Quando o servidor NFS volta a funcionar corretamente, o estado anterior é restaurado e o funcionamento continua como se não houvesse ocorrido nenhuma pausa.
·Caching - A caching de dados permite que as informações utilizadas mais recentemente, sejam alocadas para posterior uso, ou ainda, pode vir a carregar os dados em antecipação a operações futuras. Por exemplo, os dados lidos a partir de um disco podem ser mantidos até uma subseqüente escrita destes dados. No NFS a caching de dados significa não ter que enviar requisições RPC através da rede para um servidor. Ou seja, os dados são armazenados na memória do cliente NFS, e quando solicitados são buscados localmente, não executando portanto acesso ao disco remoto.
·File Locking - Esta característica, permite que um processo tenha acesso exclusivo a um arquivo ou parte deste, e força outros processos que estão solicitando acesso ao mesmo arquivo, aguardarem a liberação.
··VFS (Virtual File System) e Protocolo NFS
··Um sistema de arquivo montado via NFS apresenta dois níveis de transparência:
··O sistema de arquivo parece residir em um disco acoplado ao sistema local, e todas as entradas deste sistema de arquivo, arquivos e diretórios, são vistas do mesmo modo, tanto local como remotamente.
·Os sistemas de arquivos NFS não contêm informações sobre o servidor de arquivos do qual eles foram montados. O servidor de arquivos NFS pode ser de uma arquitetura diferente ou executar um sistema operacional completamente diverso, com uma estrutura de sistemas de arquivos radicalmente diferente. O NFS esconde as diferenças na estrutura de sistemas de arquivos básica e faz o sistema de arquivo remoto apresentar a mesma estrutura do cliente.
··Transparência do NFS
··O segundo nível de transparência surgi a partir da definição de virtual nodes, que estão mais relacionados a estrutura dos inodes do UNIX, mas esconde a estrutura real do sistema de arquivo físico abaixo dele. O conjunto de todos os procedimentos que podem ser executados sobre os arquivos, é a definição da interface vnode. A especificação do vnode e do VFS definem o protocolo NFS.
·Ações que operam no sistema de arquivos como um todo, tais como informar a quantidade de espaço livre em um sistema de arquivo, são chamadas operações VFS; enquanto que chamadas que atuam diretamente com os arquivos ou diretórios, são operações vnode. Algumas operações vnode não são definidas em certos tipos de sistemas de arquivos. Os sistemas de arquivos DOS, por exemplo, não possui qualquer equivalência a links simbólicos. Sendo assim, um servidor de arquivos NFS executando sobre uma máquina DOS rejeita qualquer tentativa de utilizar uma operação vnode para criar um link simbólico.
··Protocolo NFS
··O NFS é um protocolo baseado em RPC, com um relacionamento cliente/servidor entre a máquina que possui um sistema de arquivo a ser distribuído e a máquina que aguarda o acesso a estes sistemas de arquivos.
·O daemon do servidor NFS é o nfsd (Unix), aceita as chamadas RPC dos clientes. Os servidores NFS também executam o daemon rpc.mountd para tratar das requisições de montagem dos sistemas de arquivos e algumas traduções de caminhos completos.
·No cliente NFS, o daemon biod está normalmente em execução para melhorar a performance do NFS, apesar de não ser imprescindível.
·No cliente, cada processo que está utilizando os arquivos NFS é um cliente do servidor. As chamadas de sistema dos clientes que acessam os arquivos montados via NFS fazem chamadas RPC aos servidores NFS dos arquivos que foram montados. O VFS estende as operações das chamadas de sistema básicas a operações read( ) e write( ). Com o VFS as chamadas de sistema básicas e aquelas orientadas a sistemas de arquivos são modificadas para conhecerem como tratar com sistemas de arquivos não locais.
··Procedimentos RPC do NFS
··O protocolo RPC NFS contêm 16 procedimentos, cada um deles operam ou com arquivos ou sistemas de arquivos. Os procedimentos básico executados no servidor NFS podem ser agrupados em:
··Operações de diretórios
··mkdir -> Cria um diretório;
·Rmdir -> Destrói um diretório;
·readdir -> Lê um diretório;
·Rename -> Renomeia um diretório;
·remove -> Remove um diretório;
·Create -> Cria um diretório;
·lookup -> é de fundamental importância no mecanismo de tradução do caminho completo no handle do arquivo. Ela procura pelo nome do diretório e retorna o handle que aponta para ele.
··Operações de arquivos - estão diretamente associadas as chamadas de sistema do UNIX:
·· read e write -> movem os dados para e dos clientes NFS,
·getattr e setattr -> configuram ou modificam atributos dos arquivos.
··Operações de link - incluem link, o qual cria um hard link no servidor:
··symlink e readlink -> criam e lêem os valores de links simbólicos, respectivamente.
··Operações de sistemas de arquivos:
··statfs -> retorna informações sobre os sistemas de arquivos montados.
··Outras operações de sistemas de arquivos incluem montagem e desmontagem de um sistema de arquivo, mas estas são tratadas pelo daemon rpc.mountd ao invés do daemon RPC nfsd. As operações de montagem são separadas do protocolo NFS pois os pontos de montagem envolvem resolução de caminhos completos, e a sintaxe destes é peculiar a cada sistema operacional.
··RPC NFS X interface vnode
··A interface vnode define um conjunto de serviços do sistema operacional que são usadas para acessar os sistemas de arquivos, NFS ou locais.
· Vnodes simplesmente generaliza a interface para objetos de arquivo. Existem muitas rotinas na interface vnode que correspondem diretamente a procedimentos no protocolo NFS, mas ela também contém implementações dos serviços do sistema operacional tal como mapeamento dos blocos de arquivos e gerenciamento de cache.
··Stateless
··O protocolo NFS é stateless, significando que não há necessidade de manter informações sobre o protocolo no servidor. O cliente mantém trilhas de todas as informações necessárias para enviar uma requisição ao servidor, mas o servidor não possui informações sobre requisições prévias, ou como as várias requisições se relacionam.
·A escolha de um protocolo stateless vem de uma motivação principal, que é minimizar a sobrecarga quando da recuperação de um estado inativo. E isto implica em várias questões de design e implementação:
··Requisições RPC NFS devem descrever por completo as operações a serem executadas. Por exemplo, a escrita de um bloco de arquivo deve conter o handle do arquivo, o offset, e o comprimento da operação de escrita.
·Muitas requisições NFS são indepotentes, ou seja, um cliente NFS pode enviar mais de uma vez a mesma requisição sem qualquer efeito nocivo. Por exemplo, a leitura de um bloco de dados terá a mesma saída independente do número de vezes que é executada tal operação. Contudo, algumas operações não são indepotentes, como por exemplo, a remoção de um arquivo.
·Pelo fato das requisições poderem ser repetidas e as informações de estado serem proibidas, o NFS utiliza um protocolo de transporte de suas requisições RPC não confiável, o UDP (User Datagram Protocol). O UDP é um protocolo stateless não prometendo qualquer garantia da entrega dos pacotes, nem da ordem da entrega. Os servidores NFS notificam aos clientes quando uma chamada RPC é completada através do envio de um reconhecimento, também utilizando UDP.
··Retransmissão de requisições
··Quando um cliente solicita uma requisição RPC, ele inicializa um período de timeout durante o qual o servidor deve servir e reconhecer esta requisição. Se algum problema ocorreu e o servidor não atendeu a requisição dentro do intervalo de tempo determinado, ou por tê-la perdido, ou por sobrecarga no servidor, o cliente retransmite a requisição. Porém, se a operação houver sido executada e o atraso foi o envio do reconhecimento, pelo fato das requisições serem indepotentes, não haverá problemas com a duplicação de requisições (isto se o servidor possuir cache de requisições duplicadas). Quando o cliente receber a segunda confirmação, ele a descarta.
··Remote Procedure Call
··A Sun Microsystems desenvolveu o RPC na década de 80 com o objetivo de permitir o desenvolvimento de aplicações cliente/servidor sem necessidade de programar com interfaces sob a camada de transporte como, por exemplo, sockets.
·Desvantagens do Socket:
··- Abordagem orientada a Comunicação;
·- A aplicação não recebe atenção exclusiva;
··No paradigma cliente-servidor, os usuários interagem com aplicações que podem ser clientes de outros serviços disponíveis no sistema.
· Cada serviço provê uma série de operações que podem ser invocadas pelos clientes.
· A comunicação entre clientes e servidores se dá através de um mecanismo do tipo send/receive (request/reply).
·O mecanismo de Remote Procedure Calls (RPC), portanto, vem justamente introduzir uma abstração maior nesse cenário, permitindo que os clientes solicitem tarefas aos servidores simplesmente fazendo chamadas remotas a procedimentos, de uma maneira semelhante à que é utilizada em linguagens de alto nível convencionais.
·Dessa forma, um serviço disponível através da rede apresenta-se a seus clientes como um módulo que possui uma interface bem definida de acesso a suas operações, interface esta constituída pelos procedimentos. Isto não só dá uma maior uniformidade de acesso às suas funções, escondendo detalhes de implementação das mesmas, mas também aumenta a segurança do sistema e, evidentemente, sua transparência.
·Os clientes, então, obtêm serviços enviando uma mensagem a um determinado servidor, o qual executa a solicitação e envia uma mensagem de resposta ao cliente, comunicando o resultado da mesma e, eventualmente, mais alguns parâmetros.
·O cliente, normalmente, fica bloqueado enquanto seu pedido está sendo executado, dando prosseguimento às suas tarefas quando chega a mensagem de resposta.
·Todo este processo de enviar mensagens, bloquear-se, aguardar pela conclusão do serviço, etc., é um pouco complicado e exige um certo grau de conhecimento do programador, além de não ser transparente, pois é preciso se preocupar com protocolos utilizados, acknowledgements, sockets e outras coisas mais, não sendo isto nem um pouco trivial para a maioria das pessoas.
··Objetivo: Tornar mais fácil a implementação de Aplicações Distribuídas
·Esconde o código de chamadas a rede em procedimentos chamados stubs
· Stubs -> procedimentos que contêm o código de chamadas a rede.
· Com stubs o RPC protege os programas de aplicação (cliente e servidor) de preocupações com detalhes como sockets.
·O RPC inclui uma especificação para formato padrão dos dados (visando interoperabilidade), e nos stubs é que acontece a conversão dos dados
··No RPC da Sun o padrão para a representação dos dados é o XDR (eXternal Data Representation Standard)
·Os stubs são gerados automaticamente por algum compilador.
··Exemplo: O RPCGen da Sun
··Processamento no Adaptador Cliente
··Pedido:
··constrói a mensagem (parameter marshalling);
·envia-a (p.ex. usando sendto()) para o servidor;
· bloqueia à espera da resposta (p.ex. usando recvfrom()).
··Resposta:
··recebe a resposta;
· extrai os resultados (unmarshalling);
· retorna-os ao cliente.
··Pedido:
··recebe mensagem com pedido;
·extrai argumentos;
·invoca a função.
··Resposta:
··constrói mensagem com resultado da invocação da função;
·envia mensagem;
· bloqueia à espera de novo pedido.
··Chamadas Remotas de Procedimentos (RPC).
··Idéia do modelo é estender o conceito de chamada de procedimento convencional para ambientes distribuídos.
·· a ênfase é em distribuição e não em concorrência!
· objetivo é simplificar a programação distribuída, tornando-a semelhante à programação convencional!
··Remote Procedure Call (RPC): subrotina chamada pode ser função ou procedimento
·Procedimentos => permitem a divisão do programas em vários pedaços que podem executar em máquinas arbitrárias.
··RPC - Implementação
··O código das chamadas a rede é escondido em procedimentos chamados stubs
·· Stubs -> procedimentos que contêm o código de chamadas a rede.
·Com stubs o RPC protege os programas de aplicação (cliente e servidor) de preocupações com detalhes como sockets.
··Cabe aos stubs a passagem de parâmetros entre procedimentos.
··Máquinas diferentes podem usar representações diferentes de dados como inteiros, caracteres, etc.
·O que fazer com dados complexos, como listas, etc?
··Transparência: Heterogeneidade do Hardware
··Problema: pelo menos dois:
··diferentes arquiteturas usam diferentes formatos de representação:
··complemento para 1 vs. complemento para 2;
·big endian vs. little endian;
·ASCII vs. EBCDIC;
·vírgula flutuante: IEEE 754 vs.
··representação de estruturas de dados complexas pode diferir entre compiladores.
··Solução: essencialmente duas:
··conversão entre 2 formatos só;