Capítulo 2 Camada de Aplicaçãomarco/cursos/ea074_14_1/slides/2014-Capitulo2.pdf2: Camada de Aplicação 21 Aplicações Internet: protocolos de aplicação & de transporte Applicação

2: Camada de Aplicação 1

Capítulo 2 Camada de Aplicação

Computer Networking: A Top Down Approach, 5th edition. Jim Kurose, Keith RossAddison-Wesley, July 2009.

A note on the use of these ppt slides:We’re making these slides freely available to all (faculty, students, readers). They’re in PowerPoint form so you can add, modify, and delete slides (including this one) and slide content to suit your needs. They obviously represent a lot of work on our part. In return for use, we only ask the following: If you use these slides (e.g., in a class) in substantially unaltered form, that you mention their source (after all, we’d like people to use our book!) If you post any slides in substantially unaltered form on a www site, that you note that they are adapted from (or perhaps identical to) our slides, and note our copyright of this material.

Thanks and enjoy! JFK/KWR

All material copyright 1996-2009J.F Kurose and K.W. Ross, All Rights Reserved



Capítulo 2: Camada de Aplicação

• 2.1 Princípios das aplicações de rede• 2.2 Web e HTTP• 2.3 FTP • 2.4 Correio Eletrônico

SMTP, POP3, IMAP• 2.5 DNS• 2.6 Aplicações P2P• 2.7 Programação de Socket com TCP• 2.8 Programação de Socket com UDP


Capítulo 2: Camada de AplicaçãoObjetivos: • Conceitual, aspectos

de implementação dos protocolos de aplicação Modelos de

serviço da camada de transporte

Modelo Cliente x Servidor

Modelo Peer-to-Peer (Peer2Peer)

• Aprender sobre os protocolos através de protocolos populares na camada de aplicação HTTP FTP SMTP / POP3 / IMAP DNS

• Programação de aplicações de rede socket API


Algumas aplicações de rede• E-mail• Web• Sistema de Mensagem

instantânea (Instant Messaging)

• Login remoto• Compartilhamento de

arquivo P2P• Jogos de rede multi-

usuários• Vídeo sob demanda

• Voz sobre IP (VoiP)• Vídeo-conferência• Computação GRID• …• …• …


Criando uma aplicação de redeEscreva programas que

Executem em sistemas finais diferentes

Comuniquem-se via rede e.x., o software de um

servidor web comunica-se com o software de um browser

Poucos softwares são escritos para os dispositivos no núcleo da rede Os dispositivos do núcleo não

executam aplicações do usuário

Aplicações nos sistemas finais permitem um rápido desenvolvimento da aplicação e a sua propagação

applicationtransportnetworkdata linkphysical




Capítulo 2: camada de aplicação




Arquiteturas de aplicação

• Cliente-Servidor• Peer-to-peer (P2P)• Híbrido de Cliente-Servidor e P2P


Arquitetura Cliente-ServidorServidor:

Sempre “on” Endereço IP permanente Fazendas de servidores

para fins de escalabilidadeCliente:

Comunica com o servidor Pode ser conectado de

modo intermitente Pode possuir endereço IP

dinâmico Não se comunica

diretamente com outro cliente

cliente/servidor


Data Centers: Google

• Custo Estimado de um Data Center: $600M• Google tem gasto mais de $3B/ano em data

centers• Cada data center utilliza 50-100 megawatts

de potência


Arquitetura P2P Pura Não existem servidores

sempre “on” Sistemas finais arbitrários

comunicam-se diretamente Os pares são conectados de

modo intermitente e podem ter o endereço IP alterado

exemplo: Gnutella

Altamente escalável mas difícil de gerenciar

P2P


Híbrido de Cliente-Servidor e P2PSkype

Aplicação P2P de voz sobre IP (VoiP) Servidor centralizado: permite encontrar o endereço de um

parceiro remoto; Conexão cliente-cliente: direta (sem passar pelo servidor)

Mensagem Instantânea Conversa entre dois usuários (P2P) Serviço centralizado: deteção/localização da presença do

cliente• Usuários registram seus endereços IP no

servidor central quando eles tornam-se “on-line”

• Usuário contacta o servidor central para obter o endereço IP dos pares


Processos comunicantesProcesso: programa em

execução no host Dentro de um mesmo

host, dois processos comunicam-se através do uso da comunicação entre-processos (definida pelo OS)

Processos em hosts diferentes comunicam-se através da troca de mensagens

Processo cliente: processo que inicia a comunicação

Processo servidor: processo que espera ser contactado

Nota: aplicações P2P possuem processos clientes & processos servidores


Sockets• Processo envia/recebe

mensagens para/do seu socket

• O socket é análogo a uma porta o processo emissor empurra a

mensagem através da porta o processo emissor confia na

infra-estrutura de transporte do outro lado da porta que leva a mensagem ao socket do processo receptor.

processo

TCP combuffers,variáveis

socket

host ou servidor

processo


socket

host ou servidor

Internet

Controlado pelo OS

Controlado pelodesenvolvedor daaplicação

• API: (1) escolha do protocolo de transporte; (2) possibilidade de fixar alguns parâmetros (discussão mais à frente!)


Identificação dos processos

• Para receber mensagens os processos devem possuir um identificador

• O host possui um endereço IP de 32-bits• Q: o endereço IP do host no qual o

processo executa é suficiente para identificar o processo?


Identificação dos processosR: Não, já que

muitos processos podem estar executando no mesmo host

• identificador inclui o endereço IP e o número da porta associada ao processo no host.

• Exemplos de portas: Servidor HTTP: 80 Servidor de e-mail: 25

• Para enviar mensagens HTTP ao servidor web gaia.cs.umass.edu: Endereço Ip: 128.119.245.12 Número da porta: 80


Protocolo da camada de aplicação define:• Tipos das mensagens

trocadas, e.x., requisição (request),

resposta (response) • Sintaxe da mensagem:

Quais campos fazem parte da mensagem, ordem e tamanho dos campos

• Semântica da mensagem Significado da informação

nos campos• Regras para quando e como

os processos reagem à troca de mensagens

Protocolos de domínio público:• Definidos em RFCs• Permite a

interoperabilidade• e.x., HTTP, SMTPProtocolos proprietários:• e.x., Skype


Quais serviços de transporte as aplicações necessitam?Perda de dados• Algumas aplicações (e.x., áudio)

podem tolerar alguma perda• Outras aplicações (e.x.,

transferência de arquivos, telnet) requerem 100% para a transferência confiável de dados

Temporização• Algumas aplicações

(ex. Telefonia na Internet, jogos interativos) requerem baixo atraso para serem “efetivas”

Bandwidth• Algumas aplicações

(e.x. multimídia) requerem uma quantidade mínima de banda para serem “efetivas”

• Outras aplicações (“aplic. elásticas) utilizam qualquer banda que eles obtêm


Requisitos de algumas aplicações relativamente ao serviço de transporte

AplicaçãoTransf. de arquivo

e-mailDocumentos Web

Áudio/vídeo em teleconferência

Áudio/vídeo armazenado Jogos interativos

Mensagem instantânea

Perda de dadosSem perdaSem perdaSem perdaTolerante

ToleranteToleranteSem perda

Bandwidthelásticoelásticoelásticoáudio: 5kbps-1Mbpsvídeo:10kbps-5Mbps igual ao de cimaAlguns kbps a maiselástico

Sensibilidadeao temponãonãonãosim, 100’s msec

sim, alguns secssim, 100’s msecsim e não


Protocolos de transporte na InternetServiço TCP:• Orientado à conexão: requer

o estabelecimento da conexão entre os processos cliente e servidor

• Transporte confiável: entre os processos emissor e receptor

• Controle de fluxo: o emissor não deve sobrecarregar o receptor

• Controle de congestionamento: regular o emissor quando a rede está sobrecarregada

• Não suporta: temporização, garantia de banda mínima

Serviço UDP:• Transferência não-

confiável de dados entre os processos emissor e receptor

• Não suporta: estabelecimento de conexão, controle defluxo, controle de congestionamento, temporizações, ou garantia de banda


Aplicações Internet: protocolos de aplicação & de transporte

Applicação

e-mailAcesso de terminal remoto

Web Transferência de arquivos

Fluxo multimídia

Telefonia Internet

Protocolo dacamada de aplicação

SMTP [RFC 2821]Telnet [RFC 854]HTTP [RFC 2616]FTP [RFC 959]proprietário(e.g. RealNetworks)proprietary(e.g., Vonage,Dialpad)

Protocolo detransporte associado

TCPTCPTCPTCPTCP or UDP

tipicamente UDP






Web e HTTP

Inicialmente algumas definições• página Web consiste de objetos• Objeto pode ser um arquivo HTML, imagem

JPEG, applet Java, arquivo de áudio, …• Página Web consiste de um arquivo HTML que

inclui referências a outros objetos• Cada objeto é endereçável através de uma URL• Exemplo URL:

www.someschool.edu/someDept/pic.gif

Nome do host Nome do caminho (path)


Descrição do HTTP

HTTP: hypertext transfer protocol

• Protocolo de aplicação da Web

• Modelo cliente x servidor cliente: browser usado

para requisitar, receber, apresentar objetos Web

servidor: servidor Web envia objetos em resposta às requisições

• HTTP 1.0: RFC 1945• HTTP 1.1: RFC 2068

PC executandoInt. Explorer

Servidor executando

ServidorApache Web

Mac executandoNavegador

Requisição HTTP

Requisição HTTP

Resposta HTTP

Resposta HTTP


Descrição HTTP (continuação)Utiliza TCP:• Cliente inicia conexão TCP

(cria socket) com o servidor, porta 80

• Servidor aceita pedido de conexão TCP do cliente

• Troca de mensagens HTTP entre o browser (cliente HTTP) e o servidor Web (servidor HTTP)

• encerramento da conexão TCP

HTTP é “stateless”• Servidor não mantém

qualquer informação sobre as requisições anteriores do cliente

Protocolos que mantêm estado são complexos!

• O passado (estado) deve ser mantido

• Caso o servidor/cliente falhe, suas visões de “estado” podem ser inconsistentes e devem ser reconciliadas

Obs.


Conexões HTTP

HTTP não-persistente• No máximo um objeto

é enviado em uma conexão TCP.

• HTTP/1.0 utiliza o HTTP não-persistente

HTTP Persistente• Múltiplos objetos

podem ser enviados em uma única conexão TCP entre o cliente e o servidor.

• HTTP/1.1 utiliza conexões persistentes como modo “default”


HTTP Não-PersistenteSuponha que o usuário entre a seguinte URL

www.someSchool.edu/someDepartment/home.index

1a. cliente HTTP inicia conexãoTCP com o servidor HTTP (processo) em www.someSchool.edu on port 80

2. cliente HTTP envia mensagem de requisição (contendo URL) no socket da conexão TCP. A mensagem indica que o cliente deseja o objeto someDepartment/home.index

1b. Servidor HTTP no host www.someSchool.edu espera por conexão TCP na porta 80. “aceita” a conexão notificando ao client

3. Servidor HTTP recebe a mensagem de requisição, prepara a mensagem de resposta contendo o objeto requisitado e a envia no socket

tempo

(contém texto e referências p/10

Imagens jpeg)


HTTP não-persistente (cont.)

5. Cliente HTTP recebe a mensagem de resposta contendo arquivo html e, em seguida, apresenta o arquivo html. O parsing do arquivo html encontra 10 referências a objetos .jpeg.

6. Repete os passos 1-5 para cada um dos 10 objetos jpeg

4. Servidor HTTP server fecha a conexão TCP .

tempo


HTTP não-persistente: tempo de resposta

Definição de RTT: tempo de ida e volta de um pacote (cliente-servidor-cliente).

Tempo de resposta:• um RTT para iniciar a

conexãoTCP• um RTT para a requisição

HTTP e o retorno da resposta HTTP

• Tempo de transmissão do arquivo

total = 2RTT + tempo de transmissão

Tempo detranmissãodo arquivo

Inicia conexãoTCP

RTTRequisitao arquivo

RTT

Arquivorecebido

tempo tempo


HTTP persistente

HTTP não-persistente:• requer 2 RTTs por objeto• Overhead do OS para cada

conexão TCP• Em geral os browsers abrem

conexões TCP em paralelo para buscar os objetos

HTTP persistente• O servidor deixa a conexão

aberta após o envio da resposta

• Mensagens HTTP subsequentes entre o par cliente/servidor são enviadas na conexão aberta

Persistente sem pipelining:• Cliente envia nova

requisição somente quando a anterior foi recebida

• um RTT para cada objeto referenciado

Persistente com pipelining:• default no HTTP/1.1• Cliente envia requisições

assim que ele encontra referência para um objeto

• Praticamente um RTT para todos os objetos referenciados


Mensagem de requisição HTTP

• Dois tipos de mensagens HTTP messages: request, response

• Mensagem de requisição HTTP: ASCII (formato legível ao ser-humano)

GET /somedir/page.html HTTP/1.1Host: www.someschool.edu User-agent: Mozilla/4.0Connection: close Accept-language:fr

(carriage return, line feed extras)

Linha de requisição(comandos GET,

POST, HEAD)

cabeçalho

Carriage return, line feed

indicam o fim da mensagem


Mensagem de requisição HTTP: formato geral


Enviando dados de formulário

Método Post:• Página Web inclui um

formulário• A entrada é encaminhada

(uploaded) ao servidor no “entity body”

Método URL:• Usa o método Get• A entrada é encaminhada

no campo URL da linha de requisição:

www.somesite.com/animalsearch?monkeys&banana


Tipos de métodos

HTTP/1.0• GET• POST• HEAD

Similar ao Get. O servidor não retorna o objeto especificado (usado para debugging)

HTTP/1.1• GET, POST, HEAD• PUT

Envia arquivo no “entity body” para o caminho (path) especificado no campo URL

• DELETE Deleta o arquivo

especificado no campo URL


Mensagem de resposta HTTP

HTTP/1.1 200 OK Connection closeDate: 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 data data data data data ...

Linha de status

Cabeçalho

dado, e.x., Arquivo HTML

requisitado


Códigos de status nas mensagens de resposta HTTP

200 OK Requisição bem sucedida; objeto requisitado incluído na

mensagem;301 Objeto deslocou

Objeto requisitado moveu; nova localização incluída na mensagem; 400 Requisição incorreta

Mensagem de requisição não entendida pelo servidor404 Não encontrado

Documento requisitado não encontrado no servidor505 Versão HTTP Version não suportada

Aparecem na primeira linha da mensagem de resposta servidor ->cliente

Alguns exemplos de códigos:


Acessando um servidor HTTP via linha de comandos

1. Comando telnet para um servidor Web:abre conexão TCP na porta 80(porta default do servidor Web) em cis.poly.edu.Qualquer comando é enviado para a porta 80 emcis.poly.edu

telnet cis.poly.edu 80

2. comando de requisição GET HTTP:GET /~ross/ HTTP/1.1Host: cis.poly.edu

Ao entrar este comando (bater duasvezes o carriage return), voce enviauma requisição GET mínima mas completa ao Servidor HTTP

3. Analise a resposta enviada pelo servidor HTTP!


Olhando o HTTP em ação-Exemplos

• Exemplo telnet• Exemplo Wireshark (ferramenta livre de

monitoramento de redes)


Estado do usuário: cookiesVários sítios Web utilizam

pequenos arquivos chamados cookies

Quatro situações:1) Cookie é gerado no sítio

Web na primeira conexão e guardado em base de dados.

2) Cookie é inserido no cabeçalho da mensagem de resposta HTTP

3) Cookie é armazenado e gerenciado pelo browser no host do usuário

4) Cookie é enviado pelo browser ao servidor a cada nova requisição HTTP

Exemplo:• Susan sempre acessa a

Internet através do mesmo PC

• Visita um sítio específico de e-comércio pela primeira vez

• Quando a requisição HTTP inicial chega no destino, o sítio cria: ID único Entrada na base de dados

para o IDe devolve tais informações na forma de um arquivo cookie.


Cookies: mantendo o “estado”

cliente servidor

resposta http customizada

resposta http customizada

Arquivo cookie

Uma semana após:

requisição http cookie: 1678

cookieaccesso

ebay 8734requisição http Servidor Amazon

cria ID 1678 para o usuário cria

entradaresposta http Set-cookie: 1678

ebay 8734amazon 1678

ebay 8734amazon 1678

Base dedados

requisição httpcookie: 1678

accesso

cookie


Cookies (cont.)O quê os cookies oferecem:• autorização• cartões de compra• recomendações• estado da sessão do

usuário

Cookies e privacidade:• Os cookies permitem que

se aprenda bastante sobre o usuário

• Você pode fornecer seu nome e e-mail para os sítios

Obs


Caches Web (servidor proxy)Objetivo: atender a requisição do cliente sem envolver o

servidor original• Usuário configura o browser: acesso Web é feito por meio de um proxy

• Cliente envia todos os pedidos HTTP para o Web cache

• Se o objeto existe no Web cache: Web cache retorna o objeto

• Ou o Web cache solicita objeto do servidor original e então envia o objeto ao cliente


Mais sobre o cache Web• O cache atua tanto como

cliente como servidor• Tipicamente, o cache é

instalado pelo ISP (universidade, companhia, ISP residencial)

Porque o cache Web?

• Reduz o tempo de resposta para a requisição do cliente.

• Reduz o tráfego num enlace de acesso de uma instituição.

• A densidade de caches na Internet habilita os “fracos” provedores de conteúdo a efetivamente entregarem o conteúdo (mas fazendo P2P file sharing)


Exemplo de caching Servidores de

origem

InternetPública

Redeinstitucional 10 Mbps LAN

Enlace de acesso1 Mbps

Suponha:• Tamanho médio objeto = 100.000 bits

• Taxa média de requisições dos browsers da instituição para os servidores de origem = 15/s

• Atraso típico na nuvem Internet Pública = 2 seg.

• Atraso típico na LAN = 10 ms

Conseqüências: • Utilização da LAN = 100.000 x 15 / 10.000.00 = 15%

• Utilização do enlace de acesso = 100.000 x 15 / 1.000.000 = 150%

• Atraso total = atraso da LAN + atraso de acesso + atraso da Internet = 10 ms + alguns minutos (sobrecarga) + 2 s = alguns minutos


Exemplo de caching (cont)Solução possível• Aumentar a banda do acesso do

enlace para, p. ex., 10 Mbpsconsequência• Utilização da LAN =

= 100.000 x 15 / 10.000.000 = 15%

• Utilization do enlace de acesso == 100.000 x 15 / 10.000.000 = 15%

• Atraso total = atraso da LAN + atraso do acesso + atraso Internet = 10 ms + 10 ms + 2 s = 2,02 s

• Trata-se, em geral, de um “upgrade” caro!

Servidores deorigem

InternetPública


Enlace de acesso1 Mbps -> 10 Mbps


Exemplo de caching (cont)

Solução possível: instalação de um cache

• Suponha que a tx. de sucesso é de 0,4 (40% dos dados pedidos já estão no cache)

Consequência• 40% das requisições serão

satisfeitas imediatamente• 60% das requisições serão

atendidas pelos servidores originais (usam enlace)

• A utilização do enlace de acesso é reduzida para 60% implicando em atrasos negligíveis (~10 ms)

• Atraso médio total= atraso de LAN + atraso de acesso + atraso Internet = 0.4* 10 ms + 0.6*(10 ms + 2.0 s) = 1.21 s

Cacheinstitucional

Servidores deorigem

InternetPública


Enlace de acesso1 Mbps


GET condicional

• Razão: não enviar objeto se a versão que o cliente já possui está atualizada.

• Cliente: especifica a data da versão armazenada no pedido HTTP If-modified-since: <date>

• Servidor: resposta não contém objeto se a cópia é atualizada:

HTTP/1.0 304 Not Modified

Cliente Servidor

HTTP request msgIf-modified-since: <date>

HTTP responseHTTP/1.0

304 Not Modified

Objeto não

modificado

HTTP request msgIf-modified-since: <date>

HTTP responseHTTP/1.1 200 OK

<data>

Objeto modificado






FTP: the file transfer protocol

• Transferência de arquivo para/do host remoto• Modelo cliente x servidor

cliente: lado que inicia a transferência (seja para/do host remoto)

servidor: host remoto• ftp: RFC 959• Servidor ftp: porta 21

Transf. de arquivoServidor

FTP

Interface de usuário

FTP

ClienteFTP

Sistema deArquivo local

Sistema deArquivo remoto

usuário


FTP: separa fluxo de controle e fluxo de dados

ClienteFTP

ServidorFTP

Conexão de controle TCPporta 21

Conexão TCP de dadosporta 20

• Cliente FTP contata o servidor FTP na porta 21 especificando o TCP como protocolo de transporte

• Cliente obtém autorização pela conexão de controle• Cliente procura o diretório remoto enviando comandos pela conexão de

controle• Quando o servidor recebe um comando para uma transferência de arquivo,

ele abre uma conexão de dados TCP para o cliente• Após a transferência de um arquivo, o servidor fecha a conexão• Servidor abre uma segunda conexão de dados TCP para transferir outro

arquivo• Conexão de controle: “fora da banda”• Servidor FTP mantém “estado”: diretório atual, autenticação anterior


FTP commands, responses

Exemplos de comandos:• Envie um texto ASCII sobre canal de controle

• USER username• PASS password

• LIST retorna listagem do arquivo no diretório atual• RETR filename recupera (obtém) o arquivo• STOR filename armazena o arquivo no hospedeiro remoto

Exemplos de códigos de retorno• Código de status e frase (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






Correio eletrônicoTrês componentes principais: • Agentes do usuário • Servidores de e-mail• Protocolo de transferência de

e-mail: SMTP

Agente do usuário• Conhecido como “leitor de e-

mail”• Composição, edição, leitura de

mensagens de e-mail• E.x., Eudora, Outlook, elm,

Mozilla Thunderbird• O servidor armazena as

mensagens enviadas e recebidas

Mailbox do usuário

Fila demensagens de saída

Servidorde e-mail

Agentedo

usuário

SMTP

SMTP

SMTP

Agentedo

usuário

Agentedo

usuário

Agentedo

usuário

Agentedo

usuárioAgente

do usuário

Servidorde e-mail

Servidorde e-mail


Correio eletrônico: servidores de e-mailServidores de e-mail • Mailbox: contém as

mensagens enviadas para o usuário

• Fila de mensagens: contém as mensagens de saída (a serem enviadas)

• Protocolo SMTP: protocolo tipo cliente-servidor entre os servidores de e-mail para troca de mensagens “cliente”: servidor

emissor do e-mail “servidor”: servidor

receptor do e-mail

Servidorde e-mail

Agentedo

usuário

SMTP

SMTP

SMTP

Agentedo

usuário

Agentedo

usuário

Agentedo

usuário

Agentedo

usuárioAgente

do usuário

Servidorde e-mail

Servidorde e-mail


Correio eletrônico: SMTP [RFC 2821]

• Utiliza o TCP para transferência confiável das mensagens de e-mail do cliente para o servidor via porta 25

• Transferência direta: servidor emissor para servidor receptor

• Transferência em três fases: handshaking (cumprimentos) Transferência de mensagens encerramento

• Interação comando/resposta comandos: texto ASCII resposta: frase e código de status

• As mensagens devem ser codificadas em ASCII de 7-bits


Servidorde e-mail

Servidorde e-mail

Agentedo

usuário

Cenário: Alice envia mensagens para Bob1) Alice usa o agente (UA)

para compor a mensagem e enviar “to” [email protected]

2) O agente de Alice envia a mensagem para o seu servidor; a mensagem é colocada na fila de mensagem

3) O lado cliente do SMTP abre uma conexão TCP com o servidor de e-mail do Bob

4) O cliente SMTP envia a mensagem da Alice na conexão TCP

5) O servidor de e-mail do Bob coloca a mensagem no mailbox do Bob

6) Bob evoca o seu agente para ler a mensagem

1

2 3 4 56

Agentedo

usuário


Exemplo de uma interação SMTP S: 220 hamburger.edu C: HELO crepes.fr S: 250 Hello crepes.fr, pleased to meet you C: MAIL FROM: <[email protected]> S: 250 [email protected]... Sender ok C: RCPT TO: <[email protected]> S: 250 [email protected] ... 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


Tente uma interação SMTP!

• Entre telnet servername 25• Aguarde resposta tipo: 220 reply from server• Entre os comandos para envio de um e-mail sem

a utilização de um cliente de e-mail (reader): HELO, MAIL FROM:, RCPT TO:, DATA, QUIT


SMTP: características• SMTP utiliza conexão

persistente• SMTP requer as

mensagens (cabeçalho & corpo) em ASCII de 7 bits: necessidade de codificação de mensagens com outras codificações que usam mais de 7 bits

• SMTP utiliza CRLF.CRLF para determinar o fim da mensagem

Comparação com o HTTP:• HTTP: pull• SMTP: push

• Ambos interagem via comandos/resposta e códigos de status em ASCII

• HTTP: cada objeto é encapsulado na mensagem de resposta

• SMTP: múltiplos objetos enviados na mensagem


Formato da mensagem de e-mail

SMTP: protocolo para troca de mensagens de e-mail

RFC 822: padrão para formato da mensagem de texto:

• Linhas de cabeçalho, e.x., To: From: Subject:(não são os comandos SMTP !)

• body mensagem codificada com

caracteres ASCII de 7 bits

cabeçalho

body

Linhaem brancoCRLFCRLF


Formato da mensagem: extensões multimídia• MIME: extensão multimedia para o e-mail, RFC 2045,

2056• Linhas adicionais no cabeçalho da mensagem declaram

o conteúdo do tipo MIME

From: [email protected] To: [email protected] Subject: Picture of yummy crepe. MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Type: image/jpeg

base64 encoded data ..... ......................... ......base64 encoded data

Dado multimídiatipo, subtipo,

Método usado para codificação do dado

Versão MIME

dado codificado


Protocolos de acesso ao e-mail

• SMTP: entrega/armazenamento no servidor de recepção• Protocolo de acesso ao e-mail: recebimento da mensagem do

servidor POP: Post Office Protocol [RFC 1939]

• autorização (agente <-->servidor) e download IMAP: Internet Mail Access Protocol [RFC 1730]

• Mais características (mais complexo)• Manipulação das mensagens armazenadas no servidor

HTTP: gmail, Hotmail, Yahoo! Mail, etc.

Servidor de e-mailemissor

SMTP SMTP Protocolode acesso

Servidor de e-mailreceptor

Agentedo

usuário

Agentedo

usuário


Protocolo POP3Fase de autorização• Comandos do cliente:

user: declara username pass: password

• Respostas do servidor +OK -ERR

Fase de transação, cliente:• list: lista número da

mensagem • retr: recupera mensagem

pelo número• dele: deleta• quit

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

S: +OK POP3 server ready C: user bob S: +OK C: pass hungry S: +OK user successfully logged on


POP3 e IMAP

Mais sobre o POP3• Exemplo anterior utiliza o

modo “download and delete”.

• Bob não pode reler o e-mail caso ele troque de cliente

• “Download-and-keep”: cópias das mensagens em clientes diferentes

• POP3 é do tipo “stateless”

IMAP• Mantém as mensagens em

único lugar: o servidor• Permite que o usuário

organize as mensagens em pastas

• IMAP mantém o estado do usuário entre sessões: Nomes dos folders e

mapeamento entre o ID das mensagens e o nome da pasta






DNS: Domain Name System

Pessoas: vários identificadores: RG, name, #cic, …

Hosts Internet, roteadores: Endereço IP (32 bits) –

usado para endereçamento de datagramas

“nome”, e.x., ww.yahoo.com – usado por humanos

Q: como mapear nomes e endereços IP?

Domain Name System:• Base de dados distribuída

implementada através de uma hierarquia de vários servidores de nomes

• Protocolo de aplicação permite que hosts e servidores de nomes comuniquem-se para resolução de nomes (tradução nome/endereço) nota: função do núcleo da

Internet mas implementada como um protocolo de camada de aplicação


DNS Por que não um DNS

centralizado?• Ponto único de falha• Alto volume de tráfego• Base de dados

centralizada distante• Dificuldades de

manutenção

Conclusão: não é escalável!

Serviços DNS• Tradução do nome do

host no endereço IP• Aliasing do host

Canonical, sinônimos (aliases)

• Aliasing do servidor de e-mail

• Distribuição da carga Servidores Web

replicados: conjunto de endereços IP para um nome canônico


Servidores DNS Root

Servidores DNS .com Servidores DNS .org Servidores DNS .edu

Servidores DNSpoly.edu

Servidores DNSumass.edu

ServidoresDNS yahoo.com

Servidores DNSamazon.com

Servidores DNSpbs.org

Base de dados Hierárquica e distribuída

Cliente deseja IP para www.amazon.com; 1a aprox:• Cliente consulta um servidor root para obter o

servidor DNS responsável por .com• Cliente consulta servidor DNS .com para obter

servidor DNS amazon.com • Cliente consulta servidor DNS amazon.com para

obter o endereço IP de www.amazon.com


DNS: servidores de nome raiz (Root)• Contactado pelo servidor de nome local que não é capaz de resolver o

nome Servidor de nome raiz:

Contata o servidor de nome autoridade (authoritative) se o mapeamento do nome não é conhecido

Obém o mapeamento Retorna o mapeamento para o servidor de nome local

13 servidores de nome raiz no mundo!b USC-ISI Marina del Rey, CA

l ICANN Los Angeles, CA

e NASA Mt View, CAf Internet Software C. Palo Alto, CA (and 36 other locations)

i Autonomica, Stockholm (plus 28 other locations)

k RIPE London (also 16 other locations)

m WIDE Tokyo (also Seoul, Paris, SF)

a Verisign, Dulles, VAc Cogent, Herndon, VA (also LA)d U Maryland College Park, MDg US DoD Vienna, VAh ARL Aberdeen, MDj Verisign, ( 21 locations)


Servidores TLD e Servidores autoridades• Servidores Top-level domain (TLD):

responsáveis por com, org, net, edu, etc, e todos os domínios de países como br, uk, fr, ca, jp.

Network Solutions mantém servidores TLD .com Educause mantém TLD .edu

• Servidores DNS autoridades: Servidores DNS das organizações são autoridades para

fornecimento do mapeamento IP para o nome dos servidores da organização (e.x., Web, mail).

Podem ser mantidos pelas organizações ou pelo provedor de serviço


Servidor de Nome Local

• Na verdade, não pertence à hierarquia do DNS• cada ISP (ISP residencial, empresa,

universidade) possui um. Também chamado de “default name server”

• Quando um host faz uma consulta DNS, a consulta é encaminhada ao seu servidor DNS local Atua como um proxy encaminhando a consulta na hierarquia


requesting hostcis.poly.edu

gaia.cs.umass.edu

root DNS server

local DNS serverdns.poly.edu

1

23

4

5

6

authoritative DNS serverdns.cs.umass.edu

78

TLD DNS server

Exemplo de resolução de nome através do DNS

• Host em cis.poly.edu deseja o endereço IP para gaia.cs.umass.edu

Consulta iterativa:• Servidor contactado

responde com o nome do servidor a ser contactado

• “Eu não conheço este nome mas pergunte a este servidor”


requesting hostcis.poly.edu

gaia.cs.umass.edu

root DNS server

local DNS serverdns.poly.edu

1

2

45

6

authoritative DNS serverdns.cs.umass.edu

7

8

TLD DNS server

3Consulta recursiva:• Transfere o ônus da

resolução de nome ao servidor contactado

Exemplo de resolução de nome DNS


DNS: caching e atualização dos registros• Uma vez que qualquer servidor de nomes

aprende um mapeamento, ele faz o cache deste mapeamento As entradas do cache possuem validade por

um tempo (timeout) desaparecendo após expirado este tempo

Parte do conteúdo dos servidores TLD em geral encontra-se no cache dos servidores locais• Isso evita a necessidade de contactar os

servidores de nome root a todo momento.


Registros DNSDNS: base de dados distribuída armazenando “resource records” (RR)

• Type=NSNome é domínio (e.x. foo.com) Valor é o hostname do

servidor autoridade para este domínio

Formato RR: (name, value, type, ttl)

• Type=A Nome é hostname Valor é endereço IP

• Type=CNAME name é um alias para algum

nome canônico (nome real) www.ibm.com é, na realidade, servereast.backup2.ibm.com Valor corresponde ao nome canônico

• Type=MX value é o nome do servidor

de e-mail associado ao name


DNS: protocolo, mensagensProtocolo DNS : mensagens de consulta e

resposta, ambas possuem o mesmo formato

Cabeçalho da mensagem• identificação: 16 bits

para consulta; resposta usa o mesmo identificador

• flags: consulta ou resposta demanda de recursão recursão disponível resposta é de

autoridade do domínio


DNS: protocolo, mensagens

Nome, tipo da consulta

RRs na resposta a uma consulta

Registros para servidores autoridades

Informação adicional


Inserindo registros no DNS• Exemplo: novo domínio “Network Utopia”

Registro do nome networkuptopia.com no DNS (e.g., Network Solutions) Fornece nome e endereço IP do servidor de nomes autoridade

(deve haver primário e secundário) É preciso inserir 2 registros RRs no servidor TLD:

(networkutopia.com, dns1.networkutopia.com, NS)(dns1.networkutopia.com, 212.212.212.1, A)

Criar registros do Tipo A no servidor autoridade para o servidor web www.networkutopia.com e do Type MX para o servidor de mail mail.networkutopia.com






P2P: Compartilhamento de arquivo

Exemplo• Alice executa uma

aplicação P2P no seu notebook

• Intermitentemente conecta-se à Internet; obtém um novo endereço IP a cada acesso

• Pergunta por “Hey Jude”• A aplicação informa

outros “peers” que possuem uma cópia de Hey Jude.

• Alice escolhe um dos “peers”, Bob.

• Uma cópia do arquivo é trazida do PC do Bob para o notebook da Alice: HTTP

• Enquanto Alice faz o download, outros usuários realizam uploading do notebook da Alice.

• Os pares da Alice são, simultaneamente, um cliente e um Servidor.

Todos os pares são servidores = alta escalabilidade!


P2P: diretório centralizado

Projeto original do “Napster”1) Quando um peer conecta-

se, ele informa ao servidor central: Endereço IP conteúdo

2) Alice pergunta por “Hey Jude”

3) Alice requisita arquivo da máquina do Bob

centralizeddirectory server

peers

Alice

Bob

1

1

1

12

3


P2P: problemas relacionados a um diretório centralizado

• Ponto único de falha• Gargalo no desempenho• Problemas de copyright: a ação da lei é óbvia

A transferência do arquivo é descentralizada, mas a localização do conteúdo é altamente centralizada


Gnutella: inundação• Completamente

distribuída Não possui servidor

central• Protocolo de domínio

público• Muitos clientes

Gnutella implementam o protocolo

Rede overlay: grafo• Arco entre os pares X e

Y caso exista uma conexão TCP entre eles

• Todos os pares ativos e os arcos formam uma rede overlay

• arco: enlace virtual (não físico)

• Um “peer” conecta-se, tipicamente, com < 10 vizinhos overlay.


Gnutella: protocolo

Query

QueryHit

Query

Query

QueryHit

Query

Query

QueryHit

File transfer:HTTP

mensagem de query nas conexões TCP existentes❒ os pares encaminham a mensagem

de Query❒ mensagem de QueryHit

enviada no caminho reverso

Escalabilidade:Limitada pelo esquema de inundação


Gnutella: associação do Peer1. Ao associar-se, o peer Alice precisa encontrar

um outro peer Gnutella na rede: utiliza a lista de candidatos a “peers”

2. Alice tenta, sequencialmente, conexões TCP com os candidatos “peers” até o “set up” com Bob

3. Flooding: Alice envia mensagem de Ping para Bob; Bob encaminha a mensagem para os seus vizinhos overlay.

❒ Pares ao receberem a mensagem Ping de Alice respondem com mensagem Pong

4. Alice recebe várias mensagens do tipo Pong e pode, portanto, estabelecer conexões TCP adicionais

Desassociação de um Peer: veja a lista de exercícios!


Overlay Hierárquico• Situa-se entre a indexação

centralizada e a abordagem baseada em inundação

• Cada peer é um líder de grupo ou é atribuído a um líder de grupo. Conexão TCP entre o peer e o

seu líder de grupo. Conexões TCP entre alguns

pares de líderes de grupo.• Líder de grupo pesquisa o

conteúdo no seus liderados Peer comum

Peer líder de grupo

Relações de vizinhança na rede overlay


P2P Estudo de caso: Skype

• P2P (pc-to-pc, pc-to-phone, phone-to-pc) Voice-Over-IP (VoIP) também IM

• Protocolo proprietário (algumas pistas obtidas via engenharia reversa)

• Overlay hierárquico

Clientes Skype (SC)

Super nó (SN)

Skype Servidor de login


Skype: Realizando uma chamada

• Usuário inicia o Skype

Skype login server

• SC registra-se no SN Lista de SNs de bootstrap

• SC realiza o login (authenticate)

• Call: SC contacta o SN e fornece o ID do destino SN contacta outros SNs

(protocolo desconhecido, talvez por inundação) para encontrar o addr do destino; retorna o addr para o SC

• SC contacta diretamente o destino via TCP


Estudo de Caso P2P: BitTorrent

tracker: registra os peers participantes de um torrent

torrent: grupo depeers que estãotrocando pedaçosde um arquivo

Obtém alista de peers

Negociandopartes doarquivo

peer

• Distribuição de arquivo P2P


BitTorrent (1)

• O arquivo é divido em pedaços (chunks) de 256KB.• Peer ao associar-se a um torrent:

Não possui “chunks”, mas irá acumulá-los com o tempo Registra-se com o “tracker” para obter a lista dos “peers” e

conecta-se ao sub-conjunto dos pares (“neighbors”)• Enquanto faz o download, o peer realiza o upload para outros

pares. • Peers podem ir e vir• Uma vez que o peer possui todo o arquivo, ele pode sair

(egoísta) ou ficar (altruista)


BitTorrent (2)Obtendo Chunks• Em um certo instante,

diferentes peers possuem diferentes subconjuntos de chunks

• Periodicamente, um peer (Alice) pergunta a cada vizinho pela lista dos chunks que ele possui.

• Alice envia uma solicitação para as partes que ela não possui Raramente ocorre de ser

o primeiro!

Enviando Chunks: tit-for-tat• Alice envia chunks para 4

vizinhos que estão, atualmente, enviando chunks para ela na taxa mais elevada Reavalia os 4 tops a cada 10

segundos• A cada 30 segundos: seleciona

aleatoriamente um outro peer, para o qual começa a enviar chunks O novo peer pode fazer

parte dos top 4


Comparando as arquiteturas Cliente-Servidor e P2PQuestão : Quanto tempo para distribuir um arquivo

inicialmente em um servidor para N outros computadores?

us

u2d1 d2u1

dN

uN

Servidor

Rede (possui abundânciade banda)

F, tamanho do arquivo

us: banda de upload do servidor

ui: banda de upload do peer cliente i

di: banda de download do peer cliente i


Cliente-servidor: tempo de distribuição do arquivo

us

u2d1 d2u1

dN

uN

Server

Network (with abundant bandwidth)

F• O servidor envia N cópias: Tempo: NF/us

• Cliente i gasta F/di

de tempo para download

Cresce linearmente com N

= dcs = max { NF/us, F/min(di) }i

Tempo para distribuir F para N clientes usando

o modelo cliente-servidor


P2P: tempo de distribuição do arquivo

us

u2d1 d2u1

dN

uN

Servidor

Rede (com abundânciade banda)

F• Servidor precisa enviar uma

cópia de F: tempo de F/us • cliente i gasta o tempo F/di

para download• NF bits no total devem ser

recebidos (downloaded)• Maior taxa de upload possível (assumindo que

todos os nós enviam pedaços do arquivo para algum peer): us + Σ ui

i=1,N

dP2P = max { F/us, F/min(di) , NF/(us + Σui }i i=1,N


Comparando as arquiteturas Cliente-Servidor e P2P

0

0.5

1

1.5

2

2.5

3

3.5

0 5 10 15 20 25 30 35

N

Tem

po

Mín

imo

de

Dis

trib

uiç

ão P2P

Cliente-Servidor


Distributed Hash Table (DHT)

• DHT = base de dados distribuída P2P• A base de dados possui tuplas (chave,valor);

chave: cpf; valor: nome de alguém chave: nome de música; valor: endereço IP

• Peers consultam o BD com uma chave BD retorna valor(es) que casam com a chave

• Peers também podem inserir tuplas (chave, valor)


Identificadores na DHT

• Atribui um identificador inteiro para cada peer no intervalo [0,2n-1]. Cada identificador é representado por n bits.

• Requer que cada chave seja um inteiro no mesmo intervalo.

• Para obter a chave, fazer o hash da chave original. ex, chave = h(“Led Zeppelin IV”) Esta é a razão do nome distributed “hash” table


Como atribuir chaves aos peers?

• Questão central: Atribuir as tuplas (chave, valor) aos peers.

• Regra: atribua a chave ao peer que possui o ID mais próximo do ID.

• Convenção adotada: mais próximo corresponde ao sucessor imediato ao valor da chave.

• Ex: n=4; peers: 1,3,4,5,8,10,12,14; chave = 13, então o sucessor é o peer = 14 chave = 15, então o sucessor é o peer = 1


1

3

4

5

810

12

15

DHT Circular (1)

• Cada peer é ciente somente do sucessor e do predecessor imediatos.

• “Exemplo de uma Rede Overlay”


DHT Circular (2)

0001

0011

0100

0101

10001010

1100

1111

Quem é o responsávelpela chave 1110 ?

Sou eu!

O(N) mensagens namédia para resolveruma consulta (query)quando existem Npeers

1110

1110

1110

1110

1110

1110


DHT Circular com Atalhos

• Cada peer conhece os endereços IP do sucessor e do predecessor, assim como, alguns atalhos.

• Reduz o número de mensagens necessárias.• Normalmente adota-se atalhos para O(log N) vizinhos,

O(log N) mensagens no caso de uma query

13

4

5

810

12

15

Quem é o responsável pela chave 1110?


Dinâmica dos Peers

• Peer 5 falha• Peer 4 deteta; faz o 8 o seu sucessor imediato; pergunta

ao peer 8 quem é o seu sucessor imediato; torna o sucessor imediato de 8 seu segundo sucessor.

• O que acontece se um peer 13 associa-se à rede?

1

3

4

5

810

12

15

• Para gerenciar a dinâmica dos peers,requere-se que cada peer conheça oendereço IP dos seus 2 sucessores. • Cada peer faz um ping periodica-mente para os seus dois sucessorespara verificar se ambos ainda estão vivos.






Programação via Socket

API de socket• Introduzida no Unix FSD4.1,

1981• Criada, utilizada e encerrada

de forma explícita pela aplicação

• Paradigma cliente/servidor • Dois tipos de serviços de

transporte oferecidos pela API de socket: Datagrama não-confiável Confiável e orientada ao

byte

Trata-se de uma interface local ao host, criada pela

aplicação e controlada pelo SO (“porta”) através da qual

processos de aplicação podem enviar e receber mensagens de/para outro processo de

aplicação

socket

Objetivo: aprender como desenvolver aplicações cliente/servidor que se comunicam via socket


Programação de socket via TCPSocket: pode ser visto como uma porta entre o

processo de aplicação e o protocolo de transporte fim-a-fim (UCP ou TCP)

Serviço TCP: transferência confiável de bytes de um processo para outro

processo


socket

Controlado pelo programador

Controlado peloSO

host ouservidor

processo


socket

Controlado peloprogramador

Controlado peloSO

host ouservidor

internet


Programação de socket com TCPCliente deve contactar o servidor• Primeiramente, o processo

servidor precisa estar executando

• O servidor precisa ter criado o socket (porta) que receberá o contacto do cliente

Cliente contacta o servidor via:• Criação de um socket TCP local

ao cliente• Especificação do endereço IP e

do número da porta associados ao processo servidor

• Quando cliente cria o socket: o cliente TCP estabelece uma conexão com o servidor TCP

• Quando contactado pelo cliente, o servidor TCP cria um novo socket para o processo servidor comunicar-se com o cliente Permite que o servidor

converse com múltiplos clientes

O número da porta de origem serve para distinguir os clientes (mais no cap. 3)

O TCP provê uma transferênciaconfiável e ordenada de bytes

(“pipe”) entre o cliente e o servidor

Ponto de vista da aplicação


Interação cliente/servidor via socket: TCP

Espera um pedidode conexãoconnectionSocket =welcomeSocket.accept()

cria socket,porta=x, para receberas requisições:welcomeSocket =

ServerSocket()

Cria socket e conecta aohostid, porta=xclientSocket =

Socket()

encerraconnectionSocket

Lê resposta declientSocket

encerraclientSocket

Servidor (executando no hostid) Cliente

Envia requisição viaclientSocketLê a requisição do

connectionSocket

Responde para connectionSocket

TCP Setup da conexão


client TCP socket

Stream: jargão• um stream é uma

sequência de bytes que flui para/de um processo.

• um stream de entrada é associado a alguma fonte de entrada para o processo, ex., teclado ou socket.

• Um stream de saída é associado a uma saída, ex., monitor ou socket

ou

tToS

erv

er

para a rededa rede

inF

rom

Se

rve

r

inF

rom

Use

r

teclado monitor

Processo cliente

client

input

stream

inputstream

outputstream


Programação de socket com TCPExemplo de aplicação cliente-servidor:1) Cliente lê linha da entrada (input) padrão

(inFromUser stream) e envia para o servidor via socket (outToServer stream)

2) Servidor lê a linha via socket3) Servidor converte a linha para maiúscula e envia de

volta para o cliente4) Cliente lê a linha modificada via socket

(inFromServer stream) e imprime


Exemplo: Cliente Java (TCP)import java.io.*; import java.net.*; class TCPClient {

public static void main(String argv[]) throws Exception { String sentence; String modifiedSentence;

BufferedReader inFromUser = new BufferedReader(new InputStreamReader(System.in));

Socket clientSocket = new Socket("hostname", 6789);

DataOutputStream outToServer = new DataOutputStream(clientSocket.getOutputStream());

Cria fluxo (stream)de entrada

Cria socket do cliente e conecta

ao servidor

Cria fluxo de saídaassociado ao socket


Exemplo: Cliente Java (TCP), cont.

BufferedReader inFromServer = new BufferedReader(new InputStreamReader(clientSocket.getInputStream()));

sentence = inFromUser.readLine();

outToServer.writeBytes(sentence + '\n');

modifiedSentence = inFromServer.readLine();

System.out.println("FROM SERVER: " + modifiedSentence);

clientSocket.close(); } }

Cria fluxo de entrada

associado ao socket

Envia linha para oservidor

Lê linha enviadapelo servidor


Exemplo: servidor Java (TCP)import java.io.*; import java.net.*;

class TCPServer {

public static void main(String argv[]) throws Exception { String clientSentence; String capitalizedSentence;

ServerSocket welcomeSocket = new ServerSocket(6789); while(true) { Socket connectionSocket = welcomeSocket.accept();

BufferedReader inFromClient = new BufferedReader(new InputStreamReader(connectionSocket.getInputStream()));

Cria socket derecepção na porta

6789

Espera no socketde recepção um

contacto de cliente

Cria um fluxode entrada associado

ao socket


Exemplo: Servidor Java (TCP), cont.

DataOutputStream outToClient = new DataOutputStream(connectionSocket.getOutputStream());

clientSentence = inFromClient.readLine();

capitalizedSentence = clientSentence.toUpperCase() + '\n';

outToClient.writeBytes(capitalizedSentence); } } }

Lê linhaRecebida no socket

Cria fluxo desaída associado

ao socket

Escreve linhano socket

Final do loop do while; passa aesperar por uma nova conexão de cliente


TCP: Observações e Questões

• O Servidor possui dois tipos de sockets: ServerSocket e Socket

• Quando o cliente “bate na porta” do serverSocket, o Servidor cria o connectionSocket e completa a conexão TCP.

• O IP destino e a porta não são explicitamente anexados ao segmento.

• Múltiplos clientes podem acessar o servidor?

114






Programação de Socket com UDP

UDP: não existe conexão entre cliente e servidor

• sem handshaking• A origem associa

explicitamente um endereço IP de destino e uma porta de destino a cada pacote

• O servidor deve extrair o endereço IP e a porta de origem do pacote recebido

UDP: o dado transmitido pode ser recebido fora de ordem ou perdido

ponto de vista da aplicação

UDP provê uma transferênciade bytes não confiável

(“datagramas”) entre o clientee o servidor

ponto de vista da aplicação

UDP provê uma transferênciade bytes não confiável

(“datagramas”) entre o clientee o servidor


Interação Cliente/Servidor via socket UDP

Servidor (executando no hostid)

encerraclientSocket

Lê a resposta declientSocket

cria socket,clientSocket = DatagramSocket()

Cliente

Cria datagrama de requisiçãocontendo (endereço hostid e porta=x)e envia através de clientSocket

cria socket,porta=x, para recebimentoda requisição:serverSocket = DatagramSocket()

Lê requisição deserverSocket

Responde viaserverSocketespecificandoo endereço do host docliente e o número da porta


Exemplo: cliente Java (UDP)

Clientprocess

client UDP socket

sen

dP

ack

et

para a rede da rede

rece

ive

Pa

cke

t

inF

rom

Use

r

teclado monitor

Processo

clientSocket

UDPpacket

inputstream

UDPpacket

UDPsocket

Saída: envia pacote (lembrar que oTCP envia fluxo de bytes)

Entrada: recebe pacotes (lembrar que o TCP recebe fluxo de bytes)


Exemplo: cliente Java (UDP)

import java.io.*; import java.net.*; class UDPClient { public static void main(String args[]) throws Exception { BufferedReader inFromUser = new BufferedReader(new InputStreamReader(System.in)); DatagramSocket clientSocket = new DatagramSocket(); InetAddress IPAddress = InetAddress.getByName("hostname"); byte[] sendData = new byte[1024]; byte[] receiveData = new byte[1024]; String sentence = inFromUser.readLine();

sendData = sentence.getBytes();

Cria fluxo deentrada

Cria socket docliente

Traduz o nome dohost para o

endereço IP via DNS


Example: Java client (UDP), cont.

DatagramPacket sendPacket = new DatagramPacket(sendData, sendData.length, IPAddress, 9876); clientSocket.send(sendPacket); DatagramPacket receivePacket = new DatagramPacket(receiveData, receiveData.length); clientSocket.receive(receivePacket); String modifiedSentence = new String(receivePacket.getData()); System.out.println("FROM SERVER:" + modifiedSentence); clientSocket.close(); }

}

Cria o datagrama contendo o dado,

tamanho, end. IP e porta

Envia o datagramapara o servidor

Lê o datagramado servidor


Exemplo: servidor Java (UDP)

import java.io.*; import java.net.*; class UDPServer { public static void main(String args[]) throws Exception { DatagramSocket serverSocket = new DatagramSocket(9876); byte[] receiveData = new byte[1024]; byte[] sendData = new byte[1024]; while(true) { DatagramPacket receivePacket = new DatagramPacket(receiveData, receiveData.length);

serverSocket.receive(receivePacket);

Cria odatagrama socket

na porta 9876

Cria o espaço parareceber o datagrama

Recebe o datagrama


Exemplo: servidor Java (UDP), cont String sentence = new String(receivePacket.getData()); InetAddress IPAddress = receivePacket.getAddress(); int port = receivePacket.getPort(); String capitalizedSentence = sentence.toUpperCase();

sendData = capitalizedSentence.getBytes(); DatagramPacket sendPacket = new DatagramPacket(sendData, sendData.length, IPAddress, port); serverSocket.send(sendPacket); } }

}

Obtém o end. IP# da porta da

origem

Escreve odatagrama no

Socket de saída

Fim do loop do while e volta aesperar um outro datagrama

Cria datagramapara enviar ao

cliente


Capítulo 2: resumo

• Arquiteturas de aplicação Cliente-servidor P2P híbrida

• Requisitos do serviço de aplicação: confiabilidade, banda, atraso

• Modelo de serviço de transporte na Internet Confiável e orientado a conexão:

TCP Não-confiável, datagrama: UDP

O estudo das aplicações de rede está completo!

• Protocolos específicos: HTTP FTP SMTP, POP, IMAP DNS P2P: BitTorrent, Skype

• Programação via socket


Capítulo 2: resumo

• Troca típica de mensagem request/reply: cliente requisita informação

ou serviço Servidor responde com

dados e código de status• Formatos das mensagens:

cabeçalhos: campos que fornecem informações sobre os dados

Dado: informação que é comunicada

Importante: conceitos sobre protocolos

Temas importantes: • Mensagens de controle vs.

mensagens de dado in-band, out-of-band

• centralizado vs. decentralizado

• stateless vs. stateful• Transferência confiável vs.

não-confiável de mensagem • “complexidade na borda da

rede”

Documents

Capítulo 2 Camada de Aplicaçãomarco/cursos/ea074_14_1/slides/2014-Capitulo2.pdf2: Camada de Aplicação 21 Aplicações Internet: protocolos de aplicação & de transporte Applicação