1 / 41

Sistemas Operacionais de Rede APIs de Programação

Sistemas Operacionais de Rede APIs de Programação. APIs para Acesso à Rede. I/O API abrir, fechar, ler e escrever em arquivos remotos Network API conectar e navegar através de sistemas de arquivos remotos Named Pipe e MailSlot API (Microsoft Win32)

gore
Télécharger la présentation

Sistemas Operacionais de Rede APIs de Programação

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Sistemas Operacionais de RedeAPIs de Programação

  2. APIs para Acesso à Rede • I/O API • abrir, fechar, ler e escrever em arquivos remotos • Network API • conectar e navegar através de sistemas de arquivos remotos • Named Pipe e MailSlot API (Microsoft Win32) • troca de dados entre processos locais ou remotos • NetBIOS API • API compatível com soluções Novell, DOS, Windows e OS/2 antigas. • Sockets API • API compatível com o padrão Internet TCP/IP • Remote Procedure Call • API que permite construir aplicações distribuídasde forma transparente.

  3. APIs para Acesso a Rede • Sockets • NetBIOS API • Named Pipes • Remote Procedure Call

  4. Sockets • Conjunto de APIs mais difundido para programação sobre a arquitetura TCP/IP. 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

  5. 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

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

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

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

  9. 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 • ...

  10. API´s para Acesso a Rede • Sockets • NetBIOS API • Named Pipes • Remote Procedure Call Facility

  11. NetBIOS • NetBIOS (1983, IBM) define as seguintes entidades: • Uma interface de programação: • Um conjunto de APIs que permite que as aplicações se comuniquem através da rede. • NetBIOS é considerado uma facilidade IPC (Inter-Process Communication) • Corresponde a camada sessão do modelo OSI, podendo servir de interface homogênea para vários protocolos de transporte: TCP/IP, IPX/SPX, NetBEUI. • Um serviço de nomes para identificar os recursos na rede • Um serviço de transmissão por datagrama não confiável

  12. Inteface NetBIOS • O comandos NetBIOS se dividem em 4 tipos: • comandos de suporte a nomes • ADD GROUP NAME, ADD NAME • DELETE NAME • FIND NAME • comandos de suporte ao serviço de datagrama • RECEIVE BROADCAST DATAGRAM: todas as estações • RECEIVE DATAGRAM: estação específica • SEND BROADCAST DATAGRAM : todas as estações • SEND DATAGRAM : estação específica

  13. Interface NetBIOS (cont.) • comandos de suporte ao serviço orientado a conexão • CALL, HANG UP: início e fim da conexão lógica • LISTEN: espera pedidos de conexões lógicas • SEND, RECEIVE: troca de dados através de uma conexão • RECEIVE ANY: recebe dados de qualquer conexão lógica • SESSION STATUS: recebe informações das conexões lógicas ativas • comandos de serviço genérico • ADAPTER STATUS: obtém informações sobre o adaptador de rede. • CANCEL: cancela os comandos pendentes. • RESET: limpa as tabelas de nomes e sessões.

  14. Nomes NetBIOS • Utiliza nomes lógicos para identificar as estações num ambiente de rede. • Os nomes lógicos tem entre 1 e 15 caracteres de comprimento, e devem ser únicos • O comprimento máximo dos nomes é 16 caracteres. O 16o caracter é utilizado para identifica o tipo de recursos • nome de uma máquina, nome de um serviço, nome de um usuário, nome de um grupo, etc. • Os nomes permitem identificar as estações da rede de uma maneira mais amigável que os endereços de rede.

  15. API´s para Acesso a Rede • Sockets • NetBIOS API • Named Pipes • Remote Procedure Call

  16. Protocolo Orientado a Conexão • Protocolo Named Pipes • Implementa comunicação ponto a ponto com garantia de entrega. • Não permite enviar mensagens em broadcast. Processo Cliente Processo Servidor O cliente endereça um mailbox criado pelo servidor Kernel Kernel PIPE REDE • Mensagem solicitada: receive deve ser chamado antes.

  17. Protocolo MailSlot • Formato do Endereço (nome de arquivo) 1) \\.\pipe\[path]name • “.” indica a máquina local • [path]name indica o nome do mailslot 2) \\machine\pipe\[path]name • “machine” indica o nome (NEBIOS) da máquina

  18. API´s para Acesso a Rede • Sockets • NetBIOS API • Named Pipes • Remote Procedure Call

  19. 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

  20. 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. requisição Processo Cliente Processo Servidor resposta Kernel Kernel REDE

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

  22. Processo Cliente e Servidor PROCESSO CLIENTE PROCESSO SERVIDOR 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 Chamada RPC Período que o processo permanece bloqueado. SUB-ROTINA EVOCADA DINAMICAMENTE retorno Importante: o processo que efetua a chamada RPC permanece bloqueado durante a execução remota.

  23. Portabilidade UNIX SOLARIS • 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 HPUX Windows NT UNIX LINUX Windows 95 Nao suporta named pipes nem binding automático

  24. 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).

  25. Chamada de Procedimento Local retorno = sub-rotina(parâmetro 1, parâmetro 2, etc.) 2) parâmetros Programa Principal SUB-ROTINA 1) parâmetros 3) resultado Call subrotina (parâmetros,...) 4) resultado PILHA

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

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

  28. 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.

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

  30. 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.

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

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

  33. 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

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

  35. 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.

  36. 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.

  37. 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)

  38. BINDING MANUAL servidor cliente conexão chamada resposta PORTA desconexão SERVIDOR CLIENTE PROTOCOLO, IP, PORTA, UUID

  39. 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

  40. BINDING AUTOMÁTICO 3 servidor cliente conexão chamada resposta PORTA desconexão SERVIDOR CLIENTE UUID 1 UUID,PROTOCOLO,IP, PORTA PROTOCOLO, IP, PORTA 2 SERVIDOR DE NOMES

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

More Related