Comunicação em Sistemas Distribuídos

Comunicação em Sistemas Distribuídos

Sockets Aplicações Protocolo de Aplicação FTP, SMTP, HTTP, Telnet, SNMP, etc. sockets TCP, UDP IP Data Link Ethernet, Token Ring, FDDI, etc Física Conjunto de APIs mais difundido para programação sobre a arquitetura TCP/IP.

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: NWLink, TCP/IP e AppleTalk

Princípio Sockets podem ser utilizados para efetuar comunicação sobre os protocolos TCP ou UDP. Servidor Comunicação bidirecional Porta Porta Cliente

Fluxo de Funcionamento O servidor cria um socket O servidor passa a escutar uma porta N Chegou requisição? S Uma conexão bidirecional é criada com o cliente

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. Thread Principal Thread Cliente 1 porta 1 porta 10 Cliente 1 Servidor Thread Cliente 2 porta 1 porta 21 Cliente 2 Thread Cliente N porta 1 porta 10 Cliente N

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: NetBIOS, Named Pipes, Sockets

Protocolo Cliente-Servidor RPC (Remote Procedure Call) Implementa comunicação ponto a ponto com garantia de entrega. Não permite enviar mensagens em broadcast. Independe do protocolo de transporte utilizado. REDE Processo Cliente Kernel requisição resposta Processo Servidor Kernel

Remote Procedure Call A) Princípio Cliente RPC : computador que chama a função. Servidor RPC : computador que executa a função. cliente RPC y= Fatorial(x) Rede servidor RPC long Fatorial(short x) {... } x y resultado

Processo Cliente e Servidor PROCESSO CLIENTE PROCESSO SERVIDOR Kdfh fg kghdh g k Período que o processo permanece bloqueado. Dfh gkhdf gfh gf gf kg fdgh kdfh hgfghfgg fdkjgfd hf fg hkgd dfgkd gfhfg fjg fdgd fgh fdgdfggfhfgd fdgd ghfgfgdf Chamada RPC retorno SUB-ROTINA EVOCADA DINAMICAMENTE Importante: o processo que efetua a chamada RPC permanece bloqueado durante a execução remota.

Portabilidade UNIX SOLARIS UNIX HPUX Windows NT UNIX LINUX Windows 95 Observação: Nao suporta named pipes nem binding automático RPC são suportadas pela maioria dos sistemas operacionais. Os mecanismos de RPC não são necessariamente compatíveis entre si.

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 retorno = sub-rotina(parâmetro 1, parâmetro 2, etc.) Programa Principal 2) parâmetros Call subrotina (parâmetros,...) 1) parâmetros 4) resultado 3) resultado SUB-ROTINA PILHA

Parameter marshalling Stubs Parameter unmarshalling Stub do cliente Stub do servidor chamada Empacotamento de parâmetros Desempacotamento de parâmetros chamada CLIENTE SERVIDOR retorno Desempacotamento de parâmetros Empacotamento de parâmetros retorno Kernel Kernel REDE Transporte de mensagens pela rede

Arquitetura em Camadas CLIENTE SERVIDOR APLICAÇÃO APLICAÇÃO 1 14 8 7 2 CLIENT STUB 13 9 SERVER STUB 6 CLIENT RUN-TIME LIBRARY SERVER RUN-TIME LIBRARY 3 12 10 5 4 TRANSPORTE 11 TRANSPORTE

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. chamada marshalling unmarshalling chamada CLIENTE SERVIDOR retorno unmarshalling marshalling retorno Kernel Kernel Tempo consumido pelo STUB e pela Runtime Library Tempo consumido para transmissão e recepção dos dados

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 aproximadamente 5 milisegundos por chamada.

Servidor RPC Multithreaded Cliente 1 Thread p/ cliente 1 Thread p/ cliente 2 Cliente 2 Servidor RPC SERVIDOR

Cliente RPC multithreaded Cliente Thread principal Thread 1 Thread 2 Call Fatorial(param1) parcela2 parcela1 Call fatorial(param2) Calcula a Soma das parcelas e mostra o resultado = resultado1 + resultado2 Servidor 1 calcula primeira parcela do numero fatorial Servidor 2 calcula segunda parcela do numero fatorial

C) Binding Manual e Automático 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

Protocolos Suportados Dependendo do fabricante, vários protocolos podem ser suportados: TCP/IP NetBIOS sobre NetBEUI NetBIOS sobre TCP Named Pipes SPX (Novell) Local

Interface e Servidor de Nomes 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 conexão servidor chamada resposta desconexão PORTA CLIENTE SERVIDOR PROTOCOLO, IP, PORTA, UUID

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 cliente 3 conexão servidor chamada resposta desconexão PORTA 2 CLIENTE PROTOCOLO, IP, PORTA UUID SERVIDOR DE NOMES SERVIDOR 1 UUID, PROTOCOLO,IP, PORTA

Desenvolvimento com RPC Arquivo IDL Código do Cliente Stub do Cliente Compilador C Compilador MIDL Arquivo ACF Stub do Servidor Código do Servidor Compilador C