DINF/NCT/UNIR/20012 Sistemas Distribudos

3. Comunicao em Sistemas Distribudos

3.1.Troca de mensagens As mensagens so objetos de dados cuja estrutura e aplicao so definidas pelas prprias aplicaes que a usaro. Sendo a troca de mensagens feita atravs de primitivas explicitas de comunicao: send(destino, mensagem) envio da mensagem para o destino receive(origem, mensagem) recebimento da mensagem enviada pela origem As primitivas acima podem ser classificadas do seguinte modo: a) Forma de comunicao a.1) Direta send: h indicao do processo receptor. send(process, msg) receive: h indicao do emissor. receive(process, msg) a.2) Indireta send: envio para uma porta ou mailbox sem o conhecimento de qual ser o receptor. send(mailbox, msg) receive: obteno da mensagem guardada no mailbox, possivelmente desconhecendo a identidade do processo emissor. receive(mailbox, msg) b) Forma de Sincronizao b.1) Sncrono ou Bloqueante Send: espera at que a mensagem seja recebida pelo receptor. Receive: aguarda at a mensagem estar disponvel c) Assncrona ou No Bloqueante Send: envia a mensagem mas no espera at que a mensagem seja recebida pelo receptor. Receive: se a meensagem estiver disponvel, recebe a mensagem, caso contrrio continua o processamento retornando uma indicao de que a mensagem no estava disponvel.

DINF/NCT/UNIR/20012 Sistemas Distribudos

Um sistema pode possuir diferentes combinaes desses tipos de primitivas, sendo que um sistema de comunicao passa a ser conhecido como sncrono se ambas as primitivas (send, receive), forem do tipo bloqueante. Por outro lado, um sistema de comunicao dito assncrono se pelo menos uma das primitivas for assncrona. A principal desvantagem dessa abordagem o baixo nvel de abstrao que permite apenas a modelagem de troca indireta de informao entre processos.

3.2Modelo Cliente/Servidor um paradigma de programao que representa as interaes entre os processos e as estruturas do sistema. Neste tipo de paradigma existem dois de processos: clientes: processos que requisitam servios; servidores: processos que recebem requisitos , realizam uma operao e retornam servios Em um modelo cliente/servidor, o processo cliente necessita de um servio (ex. Ler dados de um arquivo), ento ele envia uma mensagem para o servidor e espera pela mensagem de resposta. O processo servidor, aps realizar a tarefa requisitada, envia o resultado na forma de uma mensagem de resposta ao processo cliente. Note que os servidores, em um sistema deste tipo, apenas responde as requisies dos clientes,e , tipicamente, no iniciam conversao com os clientes. A principal vantagem desta abordagem a simplicidade, mas a implementao menos eficiente do que a troca de mensagens pura. Obs: A viso lgica da comunicao cliente/servidor possibilita a troca de mensagens Possibilidade de vrios clientes acessarem um recurso de forma consistente e transparente atravs do uso de um nico servidor. Mas tambm possvel termos ambientes com mltiplos servidores. No modelo cliente servidor possvel a existncia de vrios servidores, onde os mesmos podem ser replicados, isto , quando h vrias instncias do mesmo servidor. A replicao muitas vez ocorre por questes de desempenho, distribuio natural dos recursos ou por tolerncia a falhas. Tambm possvel termos servidores hierrquicos, isto , servidores que usam o(s) servio(s) de outros servidores. Nestes casos, as localizaes e converses entre servidores dever ser transparentes aos clientes.

DINF/NCT/UNIR/20012 Sistemas Distribudos

3.2.1 Endereamento Para que um cliente envie mensagens a um servidor, primeiro o cliente, deve necessariamente conhecer o endereo do servidor, desse modo, preciso estabelecer um esquema de identificao: 1. um identificador nico de processo quando na mesma mquina: com um nico processo por mquina basta indicar o endereo da mquina pois o kernel consegue determinar qual o processo servidor nico. Esta no abordagem vivel, pois dificilmente teremos um nico processo servidor em uma mquina. 2. Endereamento indicando o processo e a mquina: quando se permite mais de um processo servidor por mquina, devese enderear a mensagem a esse servidor especifico. Um esquema comum o uso de um nome composto por duas partes. Ex: 12,4 ou , sendo que 12 a mquina e quatro o processo. Logo, o kernel da mquina cliente usa o nmero 12 para enviar ao mquina correspondente e com o nmero 4 e o Kernel remoto determina para qual servidor a mensagem endereada. Nessa abordagem a identificao includa no cdigo do cliente. Com isso evitase o custo de coordenao global e evitase ambiguidades entre processos com identificador idnticos mas em mquinas distintas. Porm, perdese em transparncia pois preciso que o cliente conhea a localizao fsica do servidor. Isso pode causar problemas, como por exemplo: se um servidor de banco de dados normalmente executa na maquina 12, no momento em que a mesma for desligada para manuteno, podese disponibilizar o mesmo servio em outra mquina. Ao usar este esquema com maquinas fixas, o servio poder estar disponvel em outra mquina, mas no poder ser usado. 3. Processos escolhem endereos que so detectados por broadcast: Cada processo deve receber um endereo nico que no envolva o nmero da sua mquina. Este endereo pode ser atribudo de duas formas: atravs de um escalonador de endereos de processo centralizado, que mantm um contador e ao receber uma requisio incrementa esse contador e envia o valor. A principal desvantagem a utilizao de um componente centralizado que compromete a tolerncia a falhas e a escalabilidade; cada processo escolhe um valor aleatoriamente a partir de um espao de endereamento grande (ex. 64 bits) e portanto com pouca probabilidade de coliso. O kernel emissor de uma requisio pode localizar para qual maquina enviar atravs do seguinte procedimento: 1) o emissor envia a mensagem para todas as maquinas (broadcast) com um pacote especial de localizao contendo o endereo do processo destino; 2) em cada maquina da rede o kernel verifica se o processo est na mquina. Quem localizar envia

DINF/NCT/UNIR/20012 Sistemas Distribudos

mensagem indicando seu endereo na rede; 3) o kernel emissor guarda essas informaes para requisies futuras. Essa abordagem tem como vantagem ser transparente mas tem um custo da mensagem broadcast. 4. uso de servidor de nomes: neste esquema os servidores so indicados por um identificador de alto nvel (nome ASCII) que no inclui nem identificao da maquina nem do processo. Quando um cliente executa uma requisio a um servidor pela primeira vez, uma mensagem especial enviada para um servidor de mapeamento ou servidor de nomes solicitando o nmero da mquina onde est o servidor.

3.2.2Primitivas confiveis e no confiveis de comunicao Se as mensagens envolvidas na comunicao cliente/servidor for assumida como no confiveis, recair ao usurio a tarefa de controlar possveis perdas de mensagens. Isso no desejvel uma vez que o objetivo tornar o mais transparente possvel para o usurio. Logo, desejvel que o kernel do S.O. Se preocupe em verificar se as mensagens forem corretamente recebidas garantindo dessa forma uma comunicao confivel. A figura abaixo ilustra dois protocolos para garantir a confiabilidade atravs do uso de mensagens especiais do tipo acknowledgment.

3.3Chamada Remota de Procedimento (RPC Remote Procedure Call) Chamada remota de procedimento permite que programas invoquem procedimentos ou funes localizadas em outras mquinas como se ele estivesse localmente definidos. A nvel do programa, as informaes so passadas do chamador para o procedimento chamado atravs de parmetros e resultados so retornados atravs do resultado do procedimento. Deste modo, nenhuma mensagem ou entrada/sada visvel ao programador. Apesar de simples h alguns problemas nos seguintes pontos: chamador e chamado executam em espaos de endereamento diferentes; como fazer a passagem de parmetros e resultados quando as maquinas envolvidas tm arquiteturas distintas; possibilidades de falhas.

3.3.1Operao RPC Bsica A chamada de procedimento remoto deve parecer o mximo com o mximo possvel com a

DINF/NCT/UNIR/20012 Sistemas Distribudos

chamada local de procedimentos. Por isso, utilizase a estrutura de cliente/servidor stubs. A RPC segue os seguintes passos: 1. O procedimento chama o stub cliente de forma normal, isto , como se fosse um procedimento local qualquer; 2. O stub cliente constri mensagens e passa ao kernel; 3. O kernel remoto envia a mensagem ao stub servidor; 4. O kernel remoto entrega a mensagem ao stub servidor; 5. O stub servidor desempacota os parmetros e chama o servidor; 6. O servidor realiza o trabalho solicitante e envia o resultado ao stub servidor; 7. O stub servidor empacota o resultado em uma mensagem e passa para o kernel; 8. O kernel remoto envia mensagem ao kernel cliente; 9. O kernel cliente entrega a mensagem ao stub cliente; 10.O stub desempacota o resultado e retorna ao stub cliente. O efeito da execuo de todos esses passos a converso da chamada local de um cliente a um stub cliente em uma chamada ao procedimento servidor sem que o cliente ou servidor percebam os passos intermedirios. Via de regra os stubs so gerados automaticamente por um compilador. Essa operao bsica do RPC indica alguns aspectos e problemas interessantes que sero vistos na prxima seo. a) Passagem de Parmetros preciso tratar a passagem de parmetros e a converso de dados. Isso feito pela operao de empacotamento de parmetros (parameter marshalling). Essa operao trata problemas de representao distinta de dados (nmeros/caracteres)para mquinas hetergneas: Tanto o cliente quanto o servidor sabem os tipos de parmetros passados (identificador do procedimento + parmetros) e devem conseguir obter a representao correta dos dados. Opo 1: uso de um padro de representao de dados, como por exemplo o XDR do RPC UNIX. Essa alternativa muito interessante por permitir a comunicao entre maquinas heterogneas. A desvantagem que entre mquinas homogneas no h necessidade de incluir um custo adicional de converso da representao da mquina para a representao padro. Opo 2: a mensagem enviada no formato nativo com indicao de qual o formato utilizado. O receptor deve fazer a converso quando for o caso. Essa opo evita custos de converso em ambientes homogneos, entretanto exige que clientes e servidores saibam converter qualquer formato

DINF/NCT/UNIR/20012 Sistemas Distribudos

para a sua representao nativa.

b) Passagem de Ponteiros Um ponteiro representa um endereo de memria que no tem nenhum significado na mquina remota. Opo 1: proibir a passagem de ponteiros, essa obviamente no uma alternativa desejvel pelo programador; Opo 2: Copiar o valor apontado pela varivel ponteiros. As alteraes so feitas remotamente e no retorno as alteraes so atualizadas no chamador (semntica cpia/restaurao) Uma otimizao possvel consite em, sabendo que um determinado parmetro apenas de entrada, evita o retorno do contedo do ponteiro. De forma anloga, se ele for apenas de sada, ele no precisa ser copiado no envio. Esse tipo de informao pode ser fornecido pelo programador ou extrado a partir da anlise do cdigo fonte(anlise esttica).

c) Semntica RPC na Presena de Falhas Na execuo de uma chamda remota de procedimentos, existem cinco classes diferentes de falhas possveis. O cliente no consegue localizar o servidor Mensagem de requisio perdida Mensagem de resposta perdida O servidor cai aps receber uma requisio O cliente falha aps enviar uma requisio (falha do cliente).

3.3.2Questes de Implementao As questes de implementao analisadas nesta seo esto relacionadas as questes de desempenho. a) Protocolo Em principio qualquer mecanismo de troca de mensagem poderia dar suporte a implementao de RPC. Uma das questes a serem decididas na implementao se o protocolo ser orientado a conexo ou sem conexo. No primeiro caso, evitase o problema de mensagens perdidas, pois isso

DINF/NCT/UNIR/20012 Sistemas Distribudos

tratado em baixo nvel, porm, o desempenho menor. No segundo caso, o desempenho melhor, sendo indicado para implementao em LANs que no so confiveis do que WANs.

b)Confirmao (Acknowledgment) As mensagens de confirmao so usadas para deteco de falhas. No momento de implementar, preciso decidir se os pacotes sero confirmados individualmente ou no. Assim temos dois tipos de protocolos: stopandwait (no momento em que um pacote for danificado ou perdido, o cliente no recebendo o ACK providncia o reenvio), e o blast (o servidor envia mensagem ACK apenas no final). No caso do protocolo Blast, h duas formas de tratar o fato de apenas alguns pacotes terem sido entregues e outros no. Uma hiptese ignorar todos os pacotes e solicitar a retransmisso de todos os pacotes. Outra possibilidade realizar uma repetio seletiva (selective repeat) no compensa devido ao custo de controle envolvido. Outro problema referese ao fato dos buffers de recepo serem limitados. O envio de vrias mensagens consecutivas pode causar um overrum error. O overrum error caracterizase pela incapacidade do receptor de receber um pacote que chega corretamente causando dessa forma uma perda de mensagem. Na prtica esse um erro mais srio do que a perda por rudo ou outros problemas fsicos na rede. Com o uso de stopandwait em princpio esse erro no ocorre pois uma mensagem enviada de cada vez. No entanto, a mesma, poderia ocorrer caso diferentes emissores enviarem vrias mensagens ao mesmo tempo.

3.4Comunicao de Grupo H vria formas aplicaes para as quais temse comunicao com mltiplos processadores. Ex.: grupos de servidores de arquivos que fornecem servio de arquivos tolerantes a falhas. Um processo pode enviar mensagens para um grupo de servidores sem saber quantos eles so ou onde localizamse, sendo que tais parmetros podem mudar na prxima chamada. Um grupo uma coleo de processos que agem juntos. Quanto uma mensagem enviada ao grupo, todos os membros recebem a mesma mensagem. Grupos so dinmicos: podem ser criados e destrudos, processos podem entrar ou abandonar um grupo; e um mesmo grupo pode pertencer a mais de um grupo.