UNIVERSIDADE. Sistemas Distribuídos

(1)

UNIVERSIDADE

Sistemas Distribuídos

Ciência da Computação

Prof. Jesus José de Oliveira Neto

Comunicação Inter-Processos

(2)

Representação externa de dados

● Informações armazenadas em programas são representadas como

uma estrutura de dados

● Na transmissão de informações, as informações são representadas

numa seqüência de bytes

● Necessidade de conversão: estrutura de dados <–> seqüência de

bytes

● Problema

– Diferentes sistemas possuem diferentes estruturas de dados

– Ex: Código ASC x UNICODE, big endian x little endian, formatos de ponto flutuante etc.

● Solução

– Conversão para um formato de dados de comum acordo (eXternal

Data Representation – XDR)

– Enviar no formato do emissor e incluir informação sobre o formato empregado

(3)

Representação externa de dados

(4)

Representação externa de dados

●

Formato independente de linguagem, SO etc

●

Utilizada para comunicação dos dados de

requisições e respostas entre clientes e

servidores

●

Formato serializado

●

Marshalling: conversão entre a representação

interna e externa

➔

CORBA Common Data Representation

➔

Serialização de objetos em Java

(5)

Marshalling

(Empacotamento)

_{(Empacotamento)}

● Processo de converter uma coleção de dados e organizá-los

em um formato próprio para transmissão

– Unmarshalling é o processo oposto

● Ideal não haver o envolvimento explícito da aplicação

(transparência)

– Responsabilidade do middleware

● Duas técnicas básicas

– Conversão dos dados para um formato binário

– Conversão dos dados para um formato texto (ASC II)

(6)

CORBA CDR

●

Representação para tipos primitivos

– inteiros, ponto flutuante, octeto – big-endian e little-endian

– posicionamento de cada item de dados na msg.

●

Representação para tipos construídos

– seqüência, string, array, struct, enumeração, união – construída a partir das seqüências de bytes

correspondentes aos tipos primitivos constituintes ●

Informação de tipo: subentendida através da

(7)

Representação de tipos construídos em

CORBA CDR

Type Repr esentation

sequence l ength (unsi gned long) fo ll ow ed by el ements i n order

stri ng l ength (unsi gned long) fo ll ow ed by characters i n o rder (can al so can have w i de characters)

ar ra y arr ay ele m ents i n order ( no l ength speci f ied b ecause i t is f i x ed)

stru ct i n t he or der o f declarati on o f the comp onents

enumer ated unsigned l ong (the v al ues are speci f ie d by t he order d ecl ared)

(8)

Mensagem em CORBA CDR

The flattened form represents a Person struct with value: {‘Smith’, ‘London’, 1934}

0–3 4–7 8–11 12–15 16–19 20-23 24–27 5 "Smit" "h___" 6 "Lond" "on__" 1934 index in

sequence of bytes 4 bytes

notes on representation length of string ‘Smith’ length of string ‘London’ unsigned long struct Person { string name; string city;

unsigned long year; };

(9)

Marshalling

em CORBA

_{em CORBA}

●

O código gerado automaticamente a partir das

definições em IDL das operações

●

Converte os parâmetros e valores de retorno

das operações

●

Seguindo as regras de representação CORBA

CDR

●

Stub

– marshalling de parâmetros e unmarshalling do valor

de retorno

(10)

Inclusão de informações de tipo no

Marshalling

● Se dados empacotados (marshalled) devem incluir

informações de seus tipos

● Informar se o tipo, por exemplo, é int ou um array

● No caso de CORBA são incluídos apenas os valores

– Considera-se que o cliente já saibam os tipos dos

dados e a ordem de chegada destes dados

● Entretanto, XML e Java inclui tanto os tipos quanto os próprios

(11)

Serialização em Java

● Transformação de um objeto Java para uma seqüência de bytes

● Informações de tipo e classe dos objetos são incluídas na forma serializada

– Permitem a reconstrução dos objetos sem

conhecimento prévio de suas classes

● Processo recursivo: serializa todos os objetos referenciados pelo objeto em questão

● Classes precisam implementar a interface Serializable ● Objetos remotos: a referência é serializada

(12)

Serialização em Java

● Forma de disponibilização ao usuário

– Classes ObjectOutputSream e ObjectInputStream e seus respectivos métodos writeObject e readObject

– Classe do objeto implementa a interface Serializable

● Conteúdo do formato serializado

– Nome da classe

– Versão da classe (quando são feitas alterações na classe) – Referências a outros objetos (handles)

(13)

Formato de serialização Java

● Objetos (instância de uma classe Java) e valores de dados primitivos

podem ser passados como argumentos e resultados de invocações de método

● Ex.: struct Person

public class Person implements Serializable { private String name;

private String place; private int year;

public Person(String aName, String aPlace, int aYear) { name = aName;

place = aPlace; year = aYear;

} // seguido dos métodos para acessar as vaiáveis de instância }

(14)

Formato de serialização Java

O formato serializado na prática contém marcadores de tipos de dados adicionais h0 and h1 são handles

Serialized values

Person 3

1934

8-byte version number int year 5 Smith java.lang.String name: 6 London h0 java.lang.String place: h1 Explanation

class name, version number number, type and name of

instance variables

values of instance variables

Serializando a instância de objeto Person:

(15)

Formato de serialização Java

● Serialização e desserialização geralmente são

operações feitas automaticamente pelo middleware ● Java oferece meios para o programador personalizar

a serialização

● Exemplo é o uso da palavra-chave transient que serve para informar que uma variável não deve ser serializada

(16)

XML (Extensible Markup Language)

● Linguagem de marcação assim como HTML ● Definir documentos estruturados para a Web

● Os itens de dados são rotulados com strings de marcação

● Diferente do HTML, permite que os usuários definam suas próprias tags (Extensível)

(17)

XML (Extensible Markup Language)

● Usos de interesse aqui:

– definir a interface de serviços Web

– prover a representação externa de dados na

comunicação entre clientes e serviços

● Representação textual: independente de plataforma ● Representação hierárquica

● Textual e Auto-descritiva: tags, esquemas e

namespaces

(18)

Definição da estrutura

Pessoa

em XML

<person id="123456789">

<name>Smith</name>

<place>London</place>

<year>1934</year>

</person >

tag atributo elementos

● Atributos: rotular dados

(19)

Namespaces

<person pers:id="123456789" xmlns:pers = "http://www.cdk4.net/person"> <pers:name> Smith </pers:name>

<pers:place> London </pers:place > <pers:year> 1934 </pers:year>

</person>

● Permitem definir contextos para os marcadores (tags)

utilizados em um documento

● Referenciados através de URLs

● Evitam choques de nomes de tags em contextos

diferentes

● As tags name, place e year podem ser usadas em

(20)

Esquemas XML

●

Definem:

– os elementos e atributos que podem aparecer em

documentos XML (i.e., um vocabulário)

– como os elementos são aninhados

– a ordem, o número e o tipo dos elementos

●

Usados para validar documentos XML

●

Um mesmo esquema pode ser compartilhado

(21)

Um esquema XML para a estrutura

Pessoa

<xsd:schema xmlns:xsd = URL of XML schema definitions > <xsd:element name= "person" type ="personType" />

<xsd:complexType name="personType"> <xsd:sequence>

<xsd:element name = "name" type="xs:string"/> <xsd:element name = "place" type="xs:string"/>

<xsd:element name = "year" type="xs:positiveInteger"/> </xsd:sequence>

<xsd:attribute name= "id" type = "xs:positiveInteger"/> </xsd:complexType>

(22)

Referências de Objetos Remotos

● Num sistema distribuído, um processo servidor pode conter vários objetos remotos

● Necessário uma maneira de identificar um objeto remoto de forma única dentro de um sistema

distribuído

● Necessária quando objetos remotos são passados como parâmetro

(23)

Referências de Objetos Remotos

Internet address port number time object number interface of _{remote object}

32 bits 32 bits 32 bits 32 bits

● Devem ser descartada quando o objeto remoto deixar de existir

● A referência é serializada (não o objeto)

● Deve conter toda informação necessária para

identificar (e endereçar) um objeto unicamente no sistema distribuído. Ex.: hora da criação, nº da porta.

(24)

Comunicação Cliente-Servidor

●

Modelo geral: requisição-e-resposta

●

Variantes:

– síncrona: cliente bloqueia até receber a resposta – assíncrona: cliente recupera (explicitamente) a

resposta em um instante posterior não sendo bloqueante

●

Implementação sobre protocolo baseado em

datagramas é mais eficiente

– evita: reconhecimentos redundantes, mensagens

(25)

Protocolo requisição-e-resposta

Request Server Client doOperation (wait) (continuation) Reply message getRequest execute method message select object sendReply

(26)

Operações utilizadas para implementar o

protocolo de requisição-e-resposta

public byte[] doOperation (RemoteObjectRef o, int methodId, byte[] arguments)

envia uma mensagem de requisição para o objeto remoto e retorna a resposta. Os argumentos especificam o objeto remoto, o método a ser chamada e os argumentos para aquele método.

public byte[] getRequest ();

obtém uma requisição de um cliente através de uma porta servidora.

public void sendReply (byte[] reply, InetAddress clientHost, int clientPort);

envia a mensagem de resposta para o cliente, endereçando-a a seu endereço IP e porta.

(27)

Estrutura de mensagens de

requisição-e-resposta

resposta

messageType requestId objectReference methodId arguments

int (0=Requisição, 1= Resposta)

int (identifica a requisição) Referência de objeto remota int (identifica o método)

array de bytes

● Identificador da mensagem pode ser formado a partir:

– requestID junto com o ID do processo remetente que fez a requisição

(28)

Modelo de falhas

● Suposições

– processos: param após falha

– canais: podem omitir mensagens

● Uso de timeouts: em doOperation. Para detectar se a

resposta (ou a requisição) foi perdida. Alternativas de tratamento:

– sinalizar a falha para o cliente (uma boa opção?) – repetir o envio da requisição (um certo número

de vezes – melhor abordagem)

● Até ter certeza sobre a natureza da falha (quem falhou? O

(29)

Modelo de falhas

● Descarte de mensagens duplicadas

– o servidor deve distinguir requisições novas de

requisições retransmitidas

– RequestIDs

● Em caso de perda da resposta (reply), o servidor:

– Pode re-executar a requisição para gerar novamente a

resposta, ou

– Pode manter um histórico das respostas geradas para o

(30)

Protocolos de troca de mensagens

R _Request

RR Reply

RRA Acknowledge reply

Request

Request Reply

Cliente Servidor Cliente Nome Mensagens enviadas pelo

(31)

Protocolos de troca de mensagens

● Protocolo R: cliente transmite requisição para o servidor. Não

há necessidade de retornar valor e o cliente não precisa de confirmação de recebimento

– Geralmente implementado sobre o protocolo UDP

● Protocolo RR: cliente transmite requisição e necessita de

confirmação de recebimento pelo servidor. Confirmação feita pela resposta (reply) do servidor

● Protocolo RRA: Semelhante ao protocolo RR sendo que o servidor

também necessita de confirmação de recebimento de resposta (reply) pelo cliente (acknowledge)

(32)

Protocolo de transporte utilizado: UDP

● Leva em conta o tamanho da mensagem

● se sessões são curtas (apenas uma requisição e sua

resposta)

– não compensa o overhead do handshake TCP

● Não oferece confiabilidade necessitando que o

programador recursos de garantia de entrega de mensagens

– Retransmissão de mensagens

– Filtragem de mensagens duplicadas

(33)

Protocolo de transporte utilizado: TCP

● Implementação mais fácil

● Não impõem limites no tamanho das mensagens

– na verdade, cuida da segmentação (divisão das

mensagens) de forma transparente

– permite argumentos de tamanho arbitrário (ex.: listas)

● Transferência confiável

– lida com mensagens perdidas e duplicadas

● Controle de fluxo

● Overhead reduzido em sessões longas (muitas requisições e respostas sucessivas)

(34)

Comunicação de Grupo

● Processo envia a mensagem para o grupo (não para seus membros diretamente)

● Entrega de uma mesma mensagem, enviada por um processo, para cada um dos processos que são membros de um determinado grupo

● O conjunto de membros do grupo é transparente para o processo que envia a mensagem

● Mensagens comunicadas através de operações de

(35)

Comunicação de Grupo

(36)

Aplicações da comunicação de grupo

● Tolerância a falhas baseada em serviços replicados

● Busca por serviços de descoberta em redes espontâneas

● Melhoria de desempenho através de dados replicados

(37)

IP Multicast

● É o protocolo básico para comunicação de grupo ● Assim como o IP (unicast): não-confiável

– mensagens podem ser perdidas (falha de omissão) – i.e., não entregues para alguns membros do grupo

mensagens podem ser entregues fora de ordem

● Acessível às aplicações através de UDP

● Grupos são identificados por: endereço IP + porta, utiliza endereços IP que iniciam por 1110 (IPv4) ● Processos se tornam membros de grupos, mas não

(38)

IP Multicast (cont.)

● Um computador é membro de um grupo se ele possui um ou mais processos com sockets que se

juntaram ao grupo: multicast sockets ● Camada de rede:

– recebe mensagens endereçadas a um grupo, se

computador for membro

– entrega as mensagens para cada um dos sockets

locais que participa do grupo

– processos membros são identificados pelo número

de porta associado ao grupo

– vários processos compartilham o mesmo número

(39)

API Java para IP Multicast

●

Classe MulticastSocket

– Derivada de DatagramSocket – Principais métodos:

joinGroup: método para entrar em um grupo leaveGroup: método para sair de um grupo setTimeToLive: serve para configurar o TTL

● TTL (Time to live): serve para limitar a distância de

propagação de um datagrama multicast pela rede

– Pequenas distâncias: redes locais

– Grandes distâncias: redes externas, Internet (uso de

(40)

Processo entra em um grupo de multicast e

envia e recebe datagramas

import java.net.*; import java.io.*;

public class MulticastPeer{

public static void main(String args[]){

// args give message contents & destination multicast group (e.g. "228.5.6.7") MulticastSocket s =null;

try {

InetAddress group = InetAddress.getByName(args[1]); s = new MulticastSocket(6789);

s.joinGroup(group);

byte [] m = args[0].getBytes(); DatagramPacket messageOut =

new DatagramPacket(m, m.length, group, 6789); s.send(messageOut);

(41)

...continuação

// get messages from others in group byte[] buffer = new byte[1000]; for(int i=0; i< 3; i++) {

DatagramPacket messageIn =

new DatagramPacket(buffer, buffer.length); s.receive(messageIn);

System.out.println("Received:" + new String(messageIn.getData()));

}

s.leaveGroup(group);

}catch (SocketException e){System.out.println("Socket: " + e.getMessage()); }catch (IOException e){System.out.println("IO: " + e.getMessage());}

}finally {if(s != null) s.close();}

}

(42)

Confiabilidade e ordenação de

multicast

_multicast

● Fontes de falhas

– membros de um grupo podem perder mensagens

devido a congestionamento (fila de chegada cheia)

– falhas em roteadores de multicast

– roteador não propaga a mensagem para os membros

que estão após ele na rede

● Falhas de ordenação

– Mensagens enviadas por um processo podem ser

recebidas por outros processos em ordens diferentes

– Mensagens enviadas por diferentes processos podem

não chegar na mesma ordem em todos os demais processos

(43)

45

Exemplo de falha de ordenação

send receive send receive m₁ _m₂ 2 1 3 4 X Y Z Physical time A m₃ receive receive send

receive receive receive

t₁ t₂ t₃

receive

receive m₂

(44)

Efeitos de falhas nas principais aplicações

de comunicação de grupo

●

Serviços replicados

– causa inconsistência das réplicas: nem todas as

réplicas terão processado todas as requisições

●

Busca por serviços de descoberta

– imune a falhas: basta que alguém responda

●

Dados replicados

– depende do modelo de replicação

●

Propagação de eventos

(45)

Conclusão sobre IP Multicast

●

Protocolo de multicast não-confiável

●

Uso sobre redes locais: utiliza multicast físico

– ex.: em redes Ethernet

●

Uso na Internet: utiliza roteadores de multicast

– configurados através de algum protocolo de

roteamento multicast time-to-live para limitar a propagação de mensagens