UNIVERSIDADE Sistemas Distribuídos Ciência da Computação Prof. Jesus José de Oliveira Neto Comunicação Inter-Processos Sockets e Portas
Introdução Sistemas distribuídos consistem da comunicação entre processos Compartilhamento de memória Troca de mensagens Cópia de dados de um espaço de memória a outro Passagem de mensagem Conjunto de primitivas para comunicação entre processos baseado em um protocolo de troca de mensagens Esconde detalhes de protocolos de comunicação-interface simples Tratamento de heterogeneidade Exemplos: Sockets, RPC, RMI etc.
Características necessárias(1) Simplicidade e clareza de uso Semântica uniforme Eficiência Processos locais e remotos usam a mesma interface de comunicação Necessidade de Marshalling/Unmarshalling Busca de baixo custo de processamento Minimizar custos de estabelecimento/manutenção de conexões Uso do piggybacking para eliminar msgs adicionais Confiabilidade Garantir a entrega das mensagens em presença de falhas Eliminar (tratar) replicação de mensagens Ordenamento de mensagens
Características necessárias(2) Correção (associado a comunicação em grupo) Atomicidade: todos ou nenhum recebem Entrega ordenada: mensagens chegam na mesma ordem a todos os processos Garantia de entrega Flexibilidade Nem todas as aplicações tem as mesmas necessidades Ex.: Certas aplicações suportam perda de pacotes Segurança Autenticação de pares Codificação de mensagens Portabilidade Das aplicações e da própria biblioteca (implica em heterogeneidade)
Protocolos utilizados Aplicações e Serviços RMI ou RPC Protocolo de requisição-e-resposta Marshalling Representação externa de dados Middleware UDP e TCP
Modelos de comunicação Duas primitivas básicas: send e receive Duas semânticas: bloqueante e não bloqueante Envio de mensagem (send) Inclusão da mensagem em uma fila remota Recepção de mensagem (receive) Retirada da mensagem em uma fila local
Modelos de comunicação
Comunicação síncrona vs. assíncrona Comunicação Síncrona: sincronização entre processos Primitivas send e receive são bloqueantes Vantagens Simplicidade de programação Desvantagens Limitação de concorrência Possibilidade de deadlocks
Comunicação síncrona vs. assíncrona Comunicação Assíncrona: inexistência de sincronização Primitiva send não é bloqueante Processo remetente prossegue logo após a msg ser copiada no buffer local Transmissão ocorre paralelamente ao processo remetente Primitiva receive apresenta duas variantes Com bloqueio Sem bloqueio
Semântica de sincronização - send Bloqueante: o processo do send espera a execução do receive correspondente Não bloqueante: o processo do send prossegue com a execução tão logo a mensagem seja bufferizada localmente e enviada
Semântica de sincronização - receive Bloqueante: o processo destino é bloqueado até que a mensagem seja recebida Processos que suportam multithreads (único processo) não apresentam desvantagens. Outras threads permanecem ativas com sincronização simples Não bloqueante (implementação complexa): Processo destino prossegue execução após bufferização da msg Necessidade de notificação de chegada da msg no buffer Por meio do polling ou interrupção
API para a camada de transporte: Sockets e portas Sockets: interface entre processo de aplicação e o protocolo de transporte fim-a-fim Sockets é a maneira mais popular de utilizar as funcionalidades de comunicação TCP/IP Um dado socket pode utilizar um (e somente um) destes protocolos
API para a camada de transporte: Sockets e portas Um Socket é um ponto final (endpoint) de um canal bidirecional de comunicação entre dois programas rodando em uma rede Todos os mecanismos Sockets são gerenciados pela camada de transporte Define um ponto da comunicação (IP, Porta) Uma porta não pode ser compartilhada por vários processos Vários processos podem enviar para uma mesma porta
API para a camada de transporte: Sockets e portas socket any port agreed port socket client Internet address = 138.37.94.248 message other ports server Internet address = 138.37.88.249
API para a camada de transporte: Sockets e portas O servidor apenas fica ouvindo o Socket aguardando um pedido de conexão do cliente O cliente sabe o nome do host e qual porta está associada à aplicação servidora Assim que o servidor aceitar a conexão, este cria um novo Socket (e conseqüentemente o associa a uma nova porta) e pode ficar esperando novas conexões no Socket original enquanto atende às requisições do cliente pelo novo Socket.
API para a camada de transporte: Sockets e portas
Protocolos de sockets com TCP Serviço TCP: transferência confiável de bytes de um processo para outro
Protocolos de sockets com TCP Cliente deve contatar o servidor Processo servidor já deve estar em execução Servidor deve ter criado socket (porta) que aceita o contato do cliente Criando um socket TCP local Cliente contata o servidor Especificando endereço IP e número da porta do processo servidor Quando o cliente cria o socket: cliente TCP estabelece conexão com otcp do servidor Quando contatado pelo cliente, o TCP do servidor cria um novo socket para o processo servidor comunicar-se com o cliente Permite ao servidor conversar com múltiplos clientes Números da porta de origem são usados para distinguir o cliente
Comunicação por fluxo TCP Define a abstração de fluxo (stream) Dados podem ser lidos (receive) e escritos (send) Características de um fluxo TCP Não define limites de tamanho para as mensagens Faz controle de erros Faz controle de fluxo (regula a taxa de leitura e escrita em fluxo para evitar perdas por overflow) Garante entrega ordenada e a não duplicação dos dados Define a abstração de conexão com identificadores de processos origem e destino
Modelo de falhas TCP Funcionamento do TCP Validade: usa time-outs e retransmissões para tratar perda de mensagens Integridade: uso do checksum e de número de seqüências para garantir mensagens não corrompidas nem duplicadas Porém, NÃO É uma comunicação confiável pois as conexões TCP podem ser desfeitas, implicando em Processos não distinguem entre falha de rede e falha de processo Processos não sabem identificar se mensagens enviadas recentemente foram recebidas ou não
Interação cliente-servidor TCP
Cliente TCP: estabelece conexão com servidor, envia requisição e recebe resposta
Cliente TCP: estabelece conexão com servidor, envia requisição e recebe resposta
Servidor TCP: aceita conexões dos clientes e ecoa seu conteúdo de volta ao cliente
Servidor TCP: continuação
Protocolos de sockets com UDP Baseado em uma unidade de transmissão: datagrama Transmitido do remetente ao destino sem confirmações ou tentativas de reenvio Mensagens podem não chegar Um processo executa send e outro receive O método receive retorna o endereço e a porta do remetente Associação IP-Porta antes do envio Exemplos de aplicação: DNS, VOIP, etc. (Baixo overhead) Aspectos a considerar
Protocolos de sockets com UDP Tamanho da mensagem Bloqueio Time-out Necessidade de especificar o tamanho da mensagem Se maior que o array do receptor mensagem truncada IP permite datagramas de 2 16 bytes (64KB) maioria contém 8KB Normalmente o send é não bloqueante e o receive é bloqueante Recomendação: uso de várias threads Limitar o tempo de espera do receive (Qual o time-out?????) Recepção anônima Receive não especifica uma origem, porém é possível identificar a fonte
Modelo de falhas UDP Comunicação confiável implica em duas propriedades Validade: qualquer msg é entregue no destino Integridade: msgs não podem ser corrompidas nem duplicadas Motivos das falhas de datagramas UDP Omissão: msgs podem ser perdidas e/ou descartadas Ordenamento: msgs podem ser entregues fora de ordem Conseqüência óbvia: Aplicativos precisam tratar as falhas
Interação cliente-servidor UDP
Cliente UDP: envia uma mensagem a um servidor e obtém uma resposta
Cliente UDP: (continuação)
Servidor UDP: recebe requisição e envia seu conteúdo de volta para o cliente
Servidor UDP: (continuação)