Camada de Aplicação Protocolos Mário Meireles Teixeira. UFMA-DEINF Tópicos & Objetivos Objetivos principais: conceitual, aspectos de implementação de protocolos de aplicação para redes paradigma clienteservidor modelos de serviço exemplos de aplicações Outros objetivos: protocolos específicos: http ftp smtp pop dns programação de aplicações de rede API de sockets 1
Aplicações e Protocolos de Aplicação Aplicações: processos distribuídos comunicando-se executam nos computadores da rede (hosts) como programas de trocam mensagens para realização da aplicação vários componentes relacionados ex: email, ftp, Web Protocolos de aplicação: definem os tipos e sintaxe das mensagens trocadas definem a semântica das mensagens definem as ações tomadas usam serviços de comunicação das camadas inferiores aplicação transporte rede enlace física aplicação transporte rede enlace física aplicação transporte rede enlace física Aplicações de Rede Processo: programa executando num host dentro do mesmo host: interprocess communication (definido pelo SO) processos executando em diferentes hosts se comunicam através de passagem de mensagens, obedecendo a um protocolo da camada de aplicação Agente : software que interage com o, de um lado e com a rede, de outro implementa um protocolo da camada de aplicação Web: browser E-mail: leitor de correio streaming audio/video: media player Aplicação vs. Protocolo 2
Paradigma Cliente-Servidor Aplicações de rede típicas têm duas partes: cliente e servidor Cliente: inicia comunicação com o servidor tipicamente solicita serviços do servidor, Web: cliente implementado no browser; e-mail: leitor de correio aplicação transporte rede enlace física pedido resposta Servidor: fornece os serviços solicitados ao cliente ex: servidor web envia a página web solicitada, servidor de e-mail envia as mensagens, etc. um host pode atuar como cliente ou servidor aplicação transporte rede enlace física Interfaces de Programação (APIs) API: application programming interface define a interface entre as camadas de aplicação e transporte socket: Internet API dois processos se comunicam enviando dados para o socket e lendo dados do socket, como se fosse um descritor de arquivo Como um processo identifica o outro processo com o qual ele deseja se comunicar? End. IP do computador no qual o processo remoto executa port number - permite ao computador receptor determinar o processo local para o qual a mensagem deve ser entregue binder informa o endereço de um serviço, a partir de um nome descritivo 3
Requisitos das Aplicações Confiabilidade algumas aplicações (aúdio e vídeo) podem tolerar alguma perda de dados outras aplicações (transferência de arquivos, telnet, web) exigem transferência de dados 100% confiável Temporização algumas aplicações (telefonia na Internet, jogos interativos) exigem baixos atraso e jitter para operar Largura de Banda algumas aplicações (multimídia) impõem um limiar inferior de banda para funcionar (aplicações inelásticas) outras aplicações (aplicações elásticas: ftp, correio, web) melhoram quando a banda disponível aumenta, mas podem operar com um valor muito baixo Requisitos de Aplicações Comuns Applicação Perdas Banda Sensível ao Atraso transf. arquivos e-mail páginas web A/V tempo real A/V armazenado jogos interativos e-business sem perdas sem perdas sem perdas tolerante tolerante tolerante sem perdas elástica elástica elástica aúdio: 5Kb-1Mb vídeo:10kb-5mb idem 1Kb-10Kb elástica não não não sim, décimos de seg sim, segundos sim, décimos de seg sim 4
Serviços de Transporte da Internet Serviço TCP: orientado a conexão: conexão requerida entre cliente e servidor transporte confiável: dados perdidos na transmissão são recuperados controle de fluxo: compatibilização de velocidade entre o transmissor e o receptor controle de congestionamento: protege a rede do excesso de tráfego Serviço UDP: não orientado a conexão transferência de dados não confiável entre os processos transmissor e receptor não oferece: estabelecimento de conexão, confiabilidade, controle de fluxo e de congestionamento (responsabilidade das aplicações) ambos não oferecem: garantias de temporização e de taxa de transmissão (banda) mínima Aplicações vs. Protocolos de Transporte Aplicação e-mail terminal remoto Web transf. arquivos streaming multimedia serviço arquivos remoto telefonia Internet Protocolo de Aplicação smtp [RFC 821] telnet [RFC 854] http [RFC 2068] ftp [RFC 959] RTP ou proprietário (ex: RealNetworks) NFS RTP ou proprietário (ex: Vocaltec) Protocolo de Transporte TCP TCP TCP TCP TCP ou UDP TCP ou UDP tipicamente UDP 5
DNS: Domain Name System Pessoas: muitos identificadores RG, nome, passporte Hosts da Internet, roteadores: endereços IP (32 bits) - usados para endereçar datagramas nomes - usados por humanos Como relacionar nomes de hosts com endereços IP? Domain Name System: base de dados distribuída: implementado numa hierarquia de vários servidores de nomes protocolo da camada de aplicação: hosts, roteadores comunicam-se com servidores de nomes para resolver nomes (tradução nome/endereço) função interna da Internet, implementada como um protocolo da camada de aplicação complexidade na borda da rede outros serviços: aliases de host e servidor de email, load balancing máquinas Unix: Bind, porta 53, udp RFCs 1034, 1035 Servidores de Nomes DNS Por que não usar um DNS centralizado? ponto único de falha volume de tráfego base de dados distante manutenção Não tem escalabilidade! Solução distribuída, hierárquica: nenhum servidor tem todos os mapeamentos de nomes para endereços IP servidor de nomes local: cada empresa/instituição tem um servidor de nomes local (default) Consultas dos computadores locais ao DNS vão primeiro para o servidor de nomes local servidor de nomes com autoridade: para um computador: sempre contém o nome e o endereço IP daquele computador muitos servidores de nomes locais também são authoritative 6
DNS: Servidores de Nomes Raiz São contactados pelos servidores de nomes locais quando estes não conseguem resolver um nome Funcionalidades: buscam servidores de nomes com autoridade se o mapeamento do nome não for conhecido; realizam o mapeamento; retornam o mapeamento para o servidor de nomes local. a NSI Herndon, VA c PSInet Herndon, VA d U Maryland College Park, MD g DISA Vienna, VA h ARL Aberdeen, MD j NSI (TBD) Herndon, VA k RIPE London i NORDUnet Stockholm m WIDE Tokyo e NASA Mt View, CA f Internet Software C. Palo Alto, CA Existem 13 servidores de nomes raiz no mundo b USC-ISI Marina del Rey, CA l ICANN Marina del Rey, CA DNS: exemplo simples servidor de nomes raiz host pc01.deinf.ufma.br quer o endereço IP de xingu.icmc.usp.br 2 5 3 4 1. contacta seu servidor DNS local, caetano.deinf. ufma.br 2. caetano.deinf.ufma.br contacta o servidor de nomes raiz, se necessário 3. o servidor de nomes raiz contata o servidor de nomes autoritativo, dns.usp.br, se necessário servidor de nomes local caetano.deinf.ufma.br 1 6 computador solicitante pc01.deinf.ufma.br servidor de nomes autoritativo dns.usp.br xingu.icmc.usp.br 7
DNS: exemplo servidor de nomes raiz Servidor de nomes raiz: pode não conhecer o servidor de nomes com autoridade para um certo nome 2 7 3 6 pode conhecer apenas o servidor de nomes intermediário, aquele que deve ser contactado para encontrar o servidor de nomes com autoridade servidor de nomes local caetano.deinf.ufma.br 1 8 computador solicitante pc01.deinf.ufma.br servidor de nomes intermediário dns.usp.br 4 5 servidor de nomes autoritativo dns.icmc.usp.br xingu.icmc.usp.br DNS: consultas iterativas consulta recursiva: transfere a tarefa de resolução do nome para o servidor de nomes consultado mais mensagens consulta iterativa: servidor contactado responde com o nome de outro servidor de nomes para contato diminui a carga na rede e nos servidores caches DNS: guarda mapeamentos recentes servidor de nomes local caetano.deinf.ufma.br 1 2 8 computador solicitante pc01.deinf.ufma.br 3 4 7 servidor de nomes raiz consulta iterativa servidor de nomes intermediário dns.usp.br 5 6 servidor de nomes autoritativo dns.icmc.usp.br xingu.icmc.usp.br 8
Registros do DNS DNS: base de dados distribuída que armazena registros de recursos (RR) formato dos RR: (Name, Value, Type, TTL) Type=A name é o nome do computador value é o endereço IP Type=NS name é um domínio (ex: deinf. ufma.br) value é o endereço IP do servidor de nomes com autoridade para este domínio Type=CNAME name é um apelido value é o nome canônico (o nome real) www.deinf.ufma.br é realmente caetano.deinf.ufma.br Type=MX value é o nome do servidor de correio associado com name (deinf.ufma.br,caetano.deinf. ufma.br,mx) DNS: protocolo e mensagens protocolo DNS: mensagens de consulta e resposta, ambas com o mesmo formato cabeçalho: identificação: número de 16 bits identifica consulta; resposta usa o mesmo número flags: consulta ou resposta recursão desejada recursão disponível resposta é autoritativa 9
DNS: protocolo e mensagens Campos de nome e tipo para uma consulta RRs de resposta a uma consulta registros para servidores autoritativos informação adicional que pode ser útil FTP Protocolo de Transferência de Arquivos FTP interface de FTP cliente transferência de arquivos FTP servidor sistema de arquivos local sistema de arquivos remoto transferência de arquivos de/para um host remoto modelo cliente servidor: cliente: lado que inicia a transferência (em qualquer sentido) servidor: host remoto FTP: RFC 959 (de 1971) servidor ftp: porta 21 10
ftp: controle separado, conexões de dados cliente ftp contacta o servidor ftp na porta 21, especificando TCP como protocolo de transporte duas conexões TCP paralelas são abertas: controle: troca de comandos e respostas entre cliente e servidor (controle out of band ) dados: dados trocados com o servidor (porta 20); não persistente servidor ftp mantém o estado: diretório corrente, autenticação anterior cliente FTP TCP conexão de controle porta 21 TCP conexão de dados porta 20 servidor FTP ftp: comandos, respostas Exemplos de comandos: envio de um texto ASCII sobre canal de controle USER username PASS password LIST retorna lista de arquivos no diretório corrente RETR filename recupera (obtém) o arquivo STOR filename armazena o arquivo no host remoto Códigos de retorno: código de status e explicação (como no http) 331 Username OK, password required 125 data connection already open; transfer starting 425 Can t open data connection 452 Error writing file 11
Correio Eletrônico Três componentes principais: agentes de servidores de correio simple mail transfer protocol: smtp Agente de leitor de correio composição, edição, leitura de mensagens ex: Eudora, Outlook, mail, pine mensagens de entrada e de saída são armazenadas no servidor de correio (smtp) servidor de correio SMTP servidor de correio agente agente SMTP SMTP agente fila de saída de mensagem mail server caixa postal agente agente agente Correio eletrônico: servidores de correio Servidores de Correio caixa postal: contém mensagens que chegaram (ainda não lidas) para o fila de mensagens: contém as mensagens de correio a ser enviadas protocolo smtp: permite aos servidores de correio trocar mensagens entre eles cliente: servidor de correio que envia servidor: servidor de correio que recebe servidor de correio SMTP servidor de correio agente agente SMTP SMTP agente mail server agente agente agente 12
Correio Eletrônico: SMTP [RFC 821] SMTP usa TCP para transferência confiável de mensagens de correio do cliente ao servidor, pela porta 25 transferência direta: servidor de origem envia para o servidor de destino; não usa servidores intermediários na sua forma padrão, as mensagens SMTP devem ser formatadas em código ASCII de 7 bits (legado dos primórdios da Internet) --> codificação/decodificação três fases de transferência: apresentação: troca de endereços de origem/destino transferência de mensagens (via TCP); conexões persistentes encerramento interação comando/resposta comandos: texto ASCII resposta: código de status e frase de explicação Exemplo de interação SMTP S: 220 hamburger.edu C: HELO crepes.fr S: 250 Hello crepes.fr, pleased to meet you C: MAIL FROM: <alice@crepes.fr> S: 250 alice@crepes.fr... Sender ok C: RCPT TO: <bob@hamburger.edu> S: 250 bob@hamburger.edu... Recipient ok C: DATA S: 354 Enter mail, end with "." on a line by itself C: Do you like ketchup? C: How about pickles? C:. S: 250 Message accepted for delivery C: QUIT S: 221 hamburger.edu closing connection 13
SMTP: comentários SMTP usa conexões persistentes SMTP exige que as mensagens (cabeçalho e corpo) estejam em ASCII de 7 bits Algumas seqüências de caracteres não são permitidas nas mensagens (ex., CRLF.CRLF). Dados binários têm que ser codificados em ASCII CRLF.CRLF indica o final da mensagem Comparação com http: http: pull (recuperação) smtp: push (envio) Ambos usam comandos e respostas em ASCII, interação comando / resposta e códigos de status http: cada objeto encapsulado na sua própria mensagem de resposta smtp: múltiplos objetos são enviados numa mensagem multipart Formato das Mensagens SMTP: protocolo para troca de mensagens RFC 822: define formato das mensagens tipo texto. linhas de cabeçalho: To: From: Subject: corpo: a mensagem em ASCII, somente com caracteres header body linha em branco 14
Formato das Mensagens: extensões multimídia MIME: Multipurpose Internet Mail Extensions para transmitir textos que não estão no padrão ASCII. Ex: imagens, outro idioma que não o Inglês linhas adicionais no cabeçalho declaram o tipo de conteúdo versão MIME método usado para codificação (RFC 2045) dados multimídia: tipo, subtipo, parâmetro dados codificados terminador From: alice@crepes.fr To: bob@hamburger.edu Subject: Picture of yummy crepe. MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Type: image/jpeg base64 encoded data.........base64 encoded data. Tipos MIME (RFC 2046) Content-Type: type/subtype; parameters Text text/plain, text/html text/plain; charset= ISO-8859-1 (lín guas latinas) Image image/jpeg, image/gif Audio audio/basic (8 bits), audio/32kadpcm (32 Kbps) Video video/mpeg, video/ quicktime Application dados que precisam ser processados por uma aplicação antes de serem apresentados application/msword, application/octet-stream (dados binários genéricos) 15
Tipo Multipart From: alice@crepes.fr To: bob@hamburger.edu Subject: Picture of yummy crepe. MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=98766789 delimitador --98766789 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain Dear Bob, Please find a picture of a crepe. --98766789 Content-Transfer-Encoding: base64 Content-Type: image/jpeg base64 encoded data.........base64 encoded data --98766789-- Protocolos de acesso a correio SMTP SMTP POP3 ou agente IMAP agente servidor de correio de origem servidor de correio de destino SMTP: entrega e armazena mensagens no servidor de destino Protocolo de acesso: recupera mensagens do servidor de correio POP: Post Office Protocol [RFC 1939] autorização (agente <--> servidor), download, atualização IMAP: Internet Mail Access Protocol [RFC 2060] maiores recursos (mais complexo) manipulação de caixas postais remotas (criação de pastas, leitura parcial de mensagens, busca, etc.) HTTP: Hotmail, Yahoo, BOL (http: browser <--> servidor) 16
Protocolo POP3 fase de autorização comandos do cliente: user: nome do pass: senha respostas possíveis do servidor: +OK -ERR fase de transação, cliente: list: lista mensagens e tamanhos retr: recupera mensagem pelo número dele: apaga quit POP3 não mantém estado entre sessões dos clientes S: +OK POP3 server ready C: user alice S: +OK C: pass hungry S: +OK user successfully logged on C: list S: 1 498 S: 2 912 S:. C: retr 1 S: <message 1 contents> S:. C: dele 1 C: retr 2 S: <message 1 contents> S:. C: dele 2 C: quit S: +OK POP3 server signing off World Wide Web Permite o acesso a documentos interligados, espalhados pela Internet Tornou-se tão popular que se confunde com a própria Internet 1945 - Vannevar Bush: conceito de hipertexto 1965 - Ted Nelson: cunhou o termo 1989 - Tim Berners-Lee: no CERN, criou a Web e o protocolo http 1994 Marc Andreesen: desenvolveu o Mosaic; links para diferentes mídias Em 1995, a Web tornou-se responsável pela maior parte do tráfego na Internet, porém foi ultrapassada pelas redes P2P em 2004 Sistema hipermídia em escala global Sistema de nomenclatura: URLs Interações entre os componentes: paradigma C/S A Web funciona sobre dois padrões principais: Linguagem HTML Protocolo HTTP 17
Sistema de Nomenclatura URLs URLs permitem que os s acessem páginas web e outros serviços como FTP, telnet e notícias, a partir do próprio navegador: http - Hipertexto (HTML) ftp - Transferência de arquivos file - Acesso a arquivos locais news - Grupos de notícias e artigos gopher - recuperar informações pelo gopher mailto - Enviar e-mail telnet - Login remoto Protocolo HTTP HTTP: hypertext transfer protocol protocolo da camada de aplicação da Web modelo cliente/servidor cliente: browser que solicita, recebe e apresenta objetos da Web server: envia objetos em resposta a pedidos PC com Explorer http request http response http request http response Servidor com Apache web server HTTP 1.0: RFC 1945 HTTP 1.1: RFC 2616 Mac com Navigator 18
Protocolo HTTP http: protocolo de aplicação sobre TCP cliente inicia conexão TCP (cria socket) com o servidor na porta 80 servidor aceita uma conexão TCP do cliente mensagens http são trocadas entre o browser (cliente http) e o servidor web (servidor http) A conexão TCP é fechada http é stateless : o servidor não mantém informações sobre os pedidos dos clientes Protocolos que mantêm informações de estado são complexos: necessidade de organizar informações passadas se ocorrer uma falha, as informações podem ser perdidas ou gerar inconsistências entre o cliente e o servidor baixa escalabilidade Exemplo de Operação HTTP (1) Usuário digita a URL: www.deinf.ufma.br/prof/index.html (referencia 10 imagens) 1a. cliente http inicia conexão TCP com o servidor http (processo) em www.deinf. ufma.br, pela porta 80 (default) 1b. servidor http no host www.deinf.ufma.br, aguardando pela conexão TCP na porta 80, aceita a conexão, notificando o cliente 2. cliente http client envia http request, contendo a URL, ao servidor web 3. servidor http recebe mensagem de pedido, recupera o objeto e envia uma http response, contendo o objeto solicitado, ao cliente tempo 19
Exemplo (2) 4. servidor http fecha conexão TCP (http 1.0) tempo 5. cliente http recebe mensagem de resposta contendo o arquivo html e o apresenta ao 5a. ao analisar o arquivo html, cliente encontra 10 objetos jpeg referenciados 6. cliente repete Passos 1-5 para cada um dos 10 objetos jpeg Conexões persistentes e nãopersistentes Não-persistente http/1.0: servidor analisa pedido, envia resposta e fecha a conexão TCP 2 RTTs para obter um objeto: estabelecimento de conexão TCP solicitação e transferência do objeto cada transferência sofre ainda por causa do mecanismo de slow-start do TCP muitos browsers abrem várias conexões paralelas Persistente modo default para http/1.1 na mesma conexão TCP, são recuperados vários objetos o cliente solicita todos os objetos referenciados, tão logo ele receba a página HTML básica (pipelining) poucos RTTs, menos slow start 20
Cliente-servidor na Web (duas camadas) Cliente-servidor na Web (três camadas) 21
HTTP request: formato geral <método> <id. recurso> <versão HTTP> <crlf> [<Header>: <valor>] <crlf>... [<Header>: <valor>] <crlf> <crlf> [Entity body] Mensagens HTTP: request Dois tipos de mensagens HTTP: request, response Formato ASCII (legível para humanos) linha de pedido (comandos GET, POST,HEAD ) linhas de cabeçalho Carriage return, line feed indica fim da mensagem GET /dir/page.html HTTP/1.0 User-agent: Mozilla/4.0 Accept: text/html, image/gif, image/jpeg Accept-language: fr (linha em branco) Corpo da mensagem 22
HTTP response: formato geral <versão HTTP> <cód. status> [<explicação>] <crlf> [<Header>: <valor>] <crlf>... [<Header>: <valor>] <crlf> <crlf> [Entity body] Mensagens HTTP: response linha de status (protocolo código de status frase de status) dados, p.ex., arquivo html linhas de cabeçalho HTTP/1.0 200 OK Date: Thu, 06 Aug 1998 12:00:15 GMT Server: Apache/1.3.0 (Unix) Last-Modified: Mon, 22 Jun 1998... Content-Length: 6821 Content-Type: text/html dados dados dados dados... 23
Métodos HTTP GET Solicita o objeto identificado pela URL HEAD Obtém informações sobre o objeto sem que o mesmo seja retornado ao cliente (depuração) POST Envia informações adicionais ao servidor web (p.ex., dados de formulários) OPTIONS Obtém opções de comunicação disponíveis ou os requisitos associados ao objeto solicitado PUT Cria ou modifica um objeto no servidor web DELETE Remove um objeto do servidor web TRACE Envia mensagem de teste (loopback) ao servidor CONNECT Reservado para comunicação com servidores proxy Códigos de Status 1xx Informational 2xx Success 200 OK 3xx Redirection 301 Moved Permanently 304 Not Modified 307 Temporary Redirect 4xx Client Error 400 Bad Request 401 Unauthorized 404 Not Found 5xx Server Error 503 Service Unavailable 505 HTTP Version Not Supported 24
Cookies Gerados e lembrados pelo servidor (RFC 2109), usados mais tarde para: autenticação lembrar preferências dos s ou escolhas prévias Servidor envia cookie ao cliente na resposta HTTP Set-cookie: 1678453 Cliente apresenta cookie em pedidos posteriores Cookie: 1678453 cliente http request msg http response + Set-cookie: # http request msg Cookie: # http response msg http request msg Cookie: # usual http response msg servidor ação específica do cookie ação específica do cookie ação específica do cookie GET Condicional: caches no cliente servidor: só envia o objeto solicitado se sua versão for mais atual que a do cliente cliente: especifica, na requisição HTTP, a data da versão armazenada no cache local: If-Modified-Since: <date> servidor: resposta não contém o objeto se a cópia do cliente estiver atualizada: 304 Not Modified cliente http request If-Modified-Since: <date> http response HTTP/1.0 304 Not Modified http request If-Modified-Since: <date> http response HTTP/1.1 200 OK <data> servidor objeto não modificado objeto modificado 25
Web Caches Objetivo: atender o cliente sem envolver o servidor Web, detentor da informação original configura o browser: acesso à Web é feito através de um servidor proxy cliente envia todos os pedidos http para o proxy: se o objeto existe no cache, o proxy retorna o objeto senão, o proxy solicita o objeto ao servidor original e o envia ao cliente cliente cliente http request http response http request http response Proxy server http request http response servidor original Por que Web Caching? armazenamento fica perto do cliente (p.ex., na mesma rede) menor tempo de resposta reduz o tráfego para servidores distantes: links externos podem ser caros e facilmente congestionáveis caches hierárquicos e cooperativos (NLANR) ICP (RFC 2186) Internet Caching Protocol, suportado pelo Squid rede institucional Internet pública /media/dados/documentos/disciplinas/ enlace de acesso Grad/Redes II/aulas/05_aplicacao.ppt 1,5 Mbps 10 Mbps LAN servidores originais cache institucional 26
Compartilhamento de arquivos P2P Compartilhamento de Arquivos P2P Exemplo Alice executa a aplicação cliente P2P em seu notebook intermitentemente, conecta-se à Internet; obtém novos endereços IP para cada conexão pede por Hey Jude a aplicação exibe outros pares que possuem uma cópia de Hey Jude Alice escolhe um dos pares, Bob o arquivo é copiado do PC de Bob para o notebook de Alice: HTTP enquanto Alice faz o download, outros s fazem upload de Alice o par de Alice é tanto um cliente Web como um servidor Web transiente Todos os pares são servidores = altamente escaláveis! 2-53 P2P: diretório centralizado P2P: Diretório centralizado Projeto original Napster 1) Quando um par se conecta, ele informa ao servidor central: Endereço IP Conteúdo 2) Alice procura por Hey Jude 3) Alice requisita o arquivo de Bob 2-54 27
P2P: problemas com diretório centralizado Desvantagens do diretório centralizado Ponto único de falhas Gargalo de desempenho Infração de copyright Transferência de arquivo é descentralizada, mas a localização de conteúdo é altamente centralizada 2-55 Query flooding: Gnutella Inundação de consultas - Gnutella Totalmente distribuído Sem servidor central Protocolo de domínio público Muitos clientes Gnutella implementando o protocolo Rede de cobertura: grafo Aresta entre o par X e o Y se houver uma conexão TCP Todos os pares ativos e arestas estão na rede de sobreposição aresta não é um enlace físico Um determinado par será tipicamente conectado a <10 vizinhos na rede de sobreposição 2-56 28
Gnutella: protocolo Protocolo Gnutella Mensagem de consulta (Query) é enviada pelas conexões TCP existentes Os pares encaminham a mensagem de consulta QueryHit (acerto) é enviado pelo caminho reverso Download do arquivo é feito via HTTP 2-57 Escalabilidade: flooding de alcance limitado (num. hops < 7) Gnutella: conectando pares Protocolo Gnutella 1. Para se conectar, o par X precisa encontrar algum outro par na rede Gnutella: utiliza a lista de pares candidatos 2. X, seqüencialmente, tenta fazer conexão TCP com os pares da lista até estabelecer conexão com Y 3. X envia mensagem de Ping para Y; Y encaminha a mensagem de Ping 4. Todos os pares que recebem a mensagem de Ping respondem com mensagens de Pong 5. X recebe várias mensagens de Pong. Ele pode então estabelecer conexões TCP adicionais 2-58 29
Explorando heterogeneidade: KaZaA KaZaA Cada par é ou um líder de grupo ou está atribuído a um líder de grupo (supernó/ultranó) Conexão TCP entre o par e seu líder de grupo Conexões TCP entre alguns pares de líderes de grupo (rede sobreposta) O líder de grupo acompanha o conteúdo em todos os seus discípulos 2-59 KaZaA KaZaA Cada arquivo possui um hash e um descritor O cliente envia a consulta de palavra-chave para o seu líder de grupo O líder de grupo responde com os acertos: Para cada acerto: metadados do arquivo, hash, endereço IP Se o líder de grupo encaminha a consulta para outros líderes de grupo, eles também respondem com os acertos O cliente então seleciona os arquivos para download Requisições HTTP usando hash como identificador são enviadas aos pares que contêm o arquivo desejado 2-60 30
Artifícios do KaZaA Artifícios do KaZaA Limitações em transferências simultâneas Requisita enfileiramento de requisições Incentiva prioridades (> para peers que contribuem com arquivos para a rede) Realiza downloads em paralelo 2-61 31