Comunicação em Sistemas Distribuídos

Sockets

• Conjunto de

APIs mais

difundido

para

programação

sobre a

arquitetura

TCP/IP.

Ethernet, Token Ring, FDDI, etc IP

Física Aplicações

Sockets

• Desenvolvido para o UNIX versão Berkeley

– Método padrão para conectar duas máquinas numa rede.

– Oferece mecanismos para manipular o fluxo de dados bidirecional em uma conexão de rede virtual.

– Padrão atual da Internet

• Suporta serviços para:

– protocolos orientados a conexão (TCP)

– protocolos não-orientados a conexão (UDP)

• Os seguintes protocolos usam Sockets:

Princípio

• Sockets podem ser utilizados para efetuar

comunicação sobre os protocolos TCP ou

UDP.

Fluxo de Funcionamento

O servidor cria um socket

O servidor passa a escutar uma porta

Chegou requisição?

N S _{Uma conexão bidirecional}

Mais de um cliente

• O servidor pode utilizar a mesma porta para estabelecer várias conexões.

• Cada cliente deve ser atendido por um thread separadamente.

porta 10

porta 21

Convenções de portas

• Portas de servidor têm números

< 1024

• Portas de cliente tem número

>= 1024

• Até

64K portas

são possíveis em um servidor

• Portas servidoras são

padronizadas

por RFCs:

– 22/TCP: SSH – 25/TCP: SMTP – 80/TCP: HTTP – 161/UDP: SNMP – ...

Remote Procedure Call - RPC

• API para implementar comunicação cliente-servidor entre processos.

• Encapsula os mecanismos de IPC (Inter-Process

Communication) convencionais na forma de chamada de procedimentos.

• Simplifica o desenvolvimento e torna as aplicações

independentes dos protocolos de comunicação utilizados. • É o método IPC mais flexível entre os existentes

atualmente.

• Utiliza os outros métodos IPC para manipular comunicações cliente/servidor:

Protocolo Cliente-Servidor

Processo

Cliente

Kernel

Processo

Servidor

Kernel

– Implementa comunicação ponto a ponto com garantia de entrega.

– Não permite enviar mensagens em broadcast. – Independe do protocolo de transporte utilizado.

Remote Procedure Call

• A) Princípio

– Cliente RPC : computador que chama a função. – Servidor RPC : computador que executa a função.

y= Fatorial(x) long Fatorial(short x) { ... } Rede x resultado servidor RPC cliente RPC y

Processo Cliente e Servidor

Importante: o processo que efetua a chamada RPC permanece bloqueado durante a execução remota.

Kdfh fg kghdh g k Dfh gkhdf gfh gf gf kg fdgh kdfh hgfghfgg fdkjgfd hf fg hkgd dfgkd gfhfg fjg fdgd fgh fdgd ghfgfgdf fdgdfggfhfgd

UNIX HPUX

Portabilidade

• Observação:

– RPC são suportadas pela maioria dos sistemas operacionais.

– Os mecanismos de RPC não são necessariamente compatíveis entre si.

UNIX SOLARIS UNIX LINUX Windows NT Windows 95

Nao suporta named pipes nem binding automático

Padrão OSF-DCE

• O padrão de RPCs mais difundido foi proposto pela OSF (Open Software Foundation) para redes heterogêneas • Os objetivos do padrão RPC OSF são:

– permitir que máquinas com arquiteturas diferentes se comuniquem sem os problemas usuais como diferentes tamanhos de palavras. – permitir o uso da maioria dos tipos C (int, float, pointers, etc.).

– suportar múltiplos protocolos de rede

– esconder (encapsular) ao máximo as particularidades dos protocolos de rede.

– oferecer ao programador a flexibilidade para determinar a

quantidade de controle que será exercido sobre a conexão de rede (compromisso entre conveniência e eficiência).

Chamada de Procedimento Local

Programa Principal

Call subrotina (parâmetros,...)

retorno = sub-rotina(parâmetro 1, parâmetro 2, etc.)

SUB-ROTINA PILHA 1) parâmetros 2) parâmetros 3) resultado 4) resultado

Stubs

Kernel

Kernel

Transporte de mensagens pela rede Stub do servidor Stub do cliente

Arquitetura em Camadas

APLICAÇÃO

CLIENT STUB

CLIENT RUN-TIME LIBRARY

TRANSPORTE

APLICAÇÃO

SERVER STUB

SERVER RUN-TIME LIBRARY

TRANSPORTE CLIENTE SERVIDOR 1 2 3 4 5 6 7 8 9 10 11 12 13 14

Sequência de Eventos

• 1) A aplicação cliente chama um procedimento

local do stub ao invés do código que implementa

realmente a função.

• 2) O stub empacota os dados e chama a função

da RPC run-time library para enviar a requisição

e os parâmetros pela rede (3) e (4).

• 5) A RPC run-time library do servidor aceita a

requisição e chama o stub server (6).

• 7) O stub server desempacota os dados e chama

o procedimento real no servidor.

B) Overhead de uma chamada RPC

– A utilização de chamadas RPC introduz um

overhead devido ao processo de marshalling e unmarshalling e ao tempo de transmissão das informações pela rede.

Tempo consumido pelo STUB e pela Runtime Library

Tempo consumido para transmissão e recepção dos dados

Kernel

Kernel

Considerações de Projeto

• Um custo é introduzido devido ao tempo gasto

para gerenciar a RPC (uma RPC é +/- 5000 vezes

mais lenta que uma chamada local).

– chamada local : ~ 1 microsegundo. – Chamada RPC: ~ 5 milisegundos.

• Latência na execução da função

– tempo gasto para transportar os dados pela rede. – custo do marshalling/unmarshalling

Servidor RPC Multithreaded

Cliente RPC multithreaded

Soma das parcelas e mostra o resultado = resultado1 + resultado2 Call Fatorial(param1) Call fatorial(param2) parcela1 parcela2

• Servidor

– O servidor deve sempre começar primeiro.

– Ele fornece à máquina onde está sendo

executado as seguintes informações:

• quais protocolos de rede serão usados para comunicação com os clientes.

• o nome dos “end-points” para os diferentes protocolos. Exemplos:

– uma porta TCP em TCP/IP

– um nome do tipo pipe\pipename em named pipes

C) Binding Manual e Automático

Protocolos Suportados

• Dependendo do fabricante, vários

protocolos podem ser suportados:

– TCP/IP

– NetBIOS sobre NetBEUI

– NetBIOS sobre TCP

– Named Pipes

– SPX (Novell)

– Local

• Com os protocolos e os endpoints estabelecidos,

o servidor RPC registra uma interface para as

funções que ele suporta.

– uma interface é identificada por um UUID único do tipo:

• 12345678-1234-ABCD-1234-0123456789AB

• O servidor RPC pode registrar-se opcionalmente

como um servidor de nomes.

– O servidor de nomes RPC elimina a necessidade que os clientes conheçam o nome da máquina em que roda o RPC server.

Operação do cliente

– Para que um cliente possa executar uma RPC, ele deve primeiro se associar (bind) com o servidor RPC. – A operação de bind pode ser:

• automática • manual.

– O processo automático é mais fácil de implementar, mas é mais lento se o cliente tiver que efetuar várias chamadas sucessivas.

– No caso de serem necessárias várias chamadas, o processo manual é preferível, pois o cliente pode

conectar com o servidor uma única vez e efetuar todas as chamadas que precisa.

Binding manual

– O cliente RPC deve conhecer os dados do RPC server que vai utilizar:

• nome da máquina • tipo de protocolo • nome do endpoint

– O processo é feito em 3 fases:

• conexão com o servidor (bind) • chamada da função

• desconexão (unbind)

– O programador dever escreve o código de binding no programa cliente.

– Opcionalmente, o cliente RPC pode fazer uma

consulta para o servidor de nomes e obter os dados do RPC server (assisted manual binding)

BINDING MANUAL

CLIENTE

SERVIDOR

Binding automático

– Neste modo, o programador do código do

cliente não precisa escrever o código de

binding.

– Toda vez que um programa cliente chama

uma função do RPC server, a RPC runtime

library executa os seguintes procedimentos:

• consulta o servidor de nomes RPC da rede • determina o servidor RPC apropriado

• conecta (bind) com o servidor

• executa a chamada de procedimento remoto • desconecta (unbind) do servidor

BINDING AUTOMÁTICO

2

1

3

Desenvolvimento com RPC