Capítulo2 Camadade Aplicação - Unicampmarco/cursos/ea074_12_1/slides/2012-Capit… · 2 2: Camadade Aplicação 3 Capítulo2: Camadade Aplicação • 2.1 Princípiosdas aplicaçõesde

1

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


2


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, aspectosde implementaçãodos protocolos de aplicação� Modelos de serviço da camadade transporte

� Modelo Cliente x Servidor

� Modelo Peer-to-Peer (Peer2Peer)

• Aprender sobre osprotocolos através de protocolos populares nacamada de aplicação� HTTP� FTP� SMTP / POP3 / IMAP� DNS

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

3


Algumas aplicações de rede

• E-mail

• Web

• Sistema de Mensageminstantâ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 rede

Escreva programas que� Executem em sistemas finaisdiferentes

� Comuniquem-se via rede� e.x., o software de um servidor web comunica-se com o software de um browser

Poucos softwares são escritospara os dispositivos no núcleoda rede� Os dispositivos do núcleo nãoexecutam aplicações do usuário

� Aplicações nos sistemas finaispermitem um rápidodesenvolvimento da aplicaçãoe a sua propagação

applicationtransportnetworkdata linkphysical



4


Capítulo 2: camada de aplicação


• 2.2 Web e HTTP

• 2.3 FTP


• 2.5 DNS





Arquiteturas de aplicação

• Cliente-Servidor

• Peer-to-peer (P2P)

• Híbrido de Cliente-Servidor e P2P

5


Arquitetura Cliente-ServidorServidor:

� Sempre “on”

� Endereço IP permanente

� Fazendas de servidorespara fins de escalabilidade

Cliente:

� Comunica com o servidor

� Pode ser conectado de modo intermitente

� Pode possuir endereço IP dinâmico

� Não se comunicadiretamente com outrocliente

cliente/servidor


Data Centers: Google

• Custo Estimado de um Data Center: $600M

• Google gastou $2.4B em 2007 em novosdata centers

• Cada data center utilliza 50-100 megawatts de potência

6


Arquitetura P2P Pura

� Não existem servidores sempre “on”

� Sistemas finais arbitrárioscomunicam-se diretamente

� Os pares são conectados de modo intermitente e podemter o endereço IP alterado

� exemplo: Gnutella

Altamente escalável mas difícilde gerenciar

P2P


Híbrido de Cliente-Servidor e P2P

Skype

� 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 servidorcentral quando eles tornam-se “on-line”

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

7


Processos comunicantes

Processo: programa emexecução no host

� Dentro de um mesmohost, dois processoscomunicam-se atravésdo uso da comunicaçãoentre-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 esperaser contactado

� Nota: aplicações P2P possuem processosclientes & processosservidores


Sockets

• Processo envia/recebemensagens 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 nainfra-estrutura de transportedo outro lado da porta queleva 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ãomais à frente!)

8


Identificação dos processos

• Para receber mensagens os processosdevem possuir um identificador

• O host possui um endereço IP de 32-bits

• Q: o endereço IP do host no qual o processoexecuta é suficiente para identificar o processo?


Identificação dos processos

R: Não, já quemuitos processospodem estarexecutando no mesmo host

• identificador inclui o endereço IP e o número daporta associada ao processono host.

• Exemplos de portas:� Servidor HTTP: 80

� Servidor de e-mail: 25

• Para enviar mensagensHTTP ao servidor web gaia.cs.umass.edu:� Endereço Ip: 128.119.245.12

� Número da porta: 80

9


Protocolo da camada de aplicaçãodefine:

• Tipos das mensagenstrocadas, � 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çãonos campos

• Regras para quando e comoos processos reagem à trocade mensagens

Protocolos de domínio público:

• Definidos em RFCs

• Permite a interoperabilidade

• e.x., HTTP, SMTP

Protocolos proprietários:

• e.x., Skype


Quais serviços de transporte as aplicaçõesnecessitam?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 naInternet, jogosinterativos) requerembaixo atraso paraserem “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

10


Requisitos de algumas aplicações relativamenteao serviço de transporte

AplicaçãoTransf. de arquivo

e-mailDocumentos Web

Áudio/vídeo de TR

áudio/vídeoJogos interativos

Mensagem instantânea

Perdade dadosSem perdaSem perdaSem perdaTolerante

ToleranteToleranteSem perda

Bandwidthelásticoelásticoelásticoáudio: 5kbps-1Mbpsvídeo:10kbps-5Mbpsigual 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 naInternetServiço TCP:• Orientado à conexão: requer

o estabelecimento da conexãoentre os processos cliente e servidor

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

• Controle de fluxo: o emissornã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, ougarantia de banda

11


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




• 2.2 Web e HTTP

• 2.3 FTP


• 2.5 DNS




12


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 queinclui 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 daWeb

• Modelo cliente x servidor� cliente: browser usadopara requisitar, receber, apresentarobjetos Web

� servidor: servidor Web envia objetos emresposta às requisições

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

PC executandoInt. Explorer

ServidorexecutandoServidor

Apache Web

Mac executandoNavegador

Requisição HTTP

Requisição H

TTP

Resposta HTTP

Respo

staHTTP

13


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 (clienteHTTP) e o servidor Web (servidor HTTP)

• encerramento da conexãoTCP

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

qualquer informaçãosobre as requisiçõesanteriores do cliente

Protocolos que mantêmestado são complexos!

• O passado (estado) deveser mantido

• Caso o servidor/clientefalhe, 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 umaconexão TCP.

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

HTTP Persistente

• Múltiplos objetospodem ser enviados emuma única conexão TCP entre o cliente e o servidor.

• HTTP/1.1 utilizaconexões persistentescomo modo “default”

14


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

www.someSchool.edu/someDepartment/home.index

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

2. cliente HTTP envia mensagemde requisição (contendo URL) no socket da conexão TCP. A mensagem indica que o clientedeseja o objetosomeDepartment/home.index

1b. Servidor HTTP no hostwww.someSchool.edu esperapor conexão TCP na porta 80. “aceita” a conexão notificandoao client

3. Servidor HTTP recebe a mensagem de requisição, prepara a mensagem de resposta contendo o objetorequisitado 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 respostacontendo arquivo html e, emseguida, apresenta o arquivohtml. O parsing do arquivohtml encontra 10 referênciasa objetos .jpeg.

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

4. Servidor HTTP server fechaa conexão TCP .

tempo

15


HTTP não-persistente: tempo de resposta

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

Tempo de resposta:

• um RTT para iniciar a conexãoTCP

• um RTT para a requisiçãoHTTP e o retorno da respostaHTTP

• Tempo de transmissão do arquivo

total = 2RTT + tempo de transmissão

Tempo detranmissãodo arquivo

Inicia conexãoTCP

RTT

Requisitao 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 paralelopara buscar os objetos

HTTP persistente• O servidor deixa a conexão

aberta após o envio daresposta

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

Persistente sem pipelining:• Cliente envia nova requisição

somente quando a anterior foi recebida

• um RTT para cada objetoreferenciado

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

assim que ele encontrareferência para um objeto

• Praticamente um RTT paratodos os objetosreferenciados

16


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 damensagem


Mensagem de requisição HTTP: formatogeral

17


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 é encaminhadano 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 arquivoespecificado no campo URL

18


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 HTMLrequisitado


Códigos de status nas mensagensde 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 servidor

404 Não encontrado

� Documento requisitado não encontrado no servidor

505 Versão HTTP Version não suportada

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

Alguns exemplos de códigos:

19


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 mascompleta ao Servidor HTTP

3. Analise a resposta enviada pelo servidor HTTP!


Olhando o HTTP em ação-Exemplos

• Exemplo telnet

• Exemplo Ethereal

20


Estado do usuário: cookies

Vários sítios Web utilizam cookies

Quatro componentes:1) Linha de cabeçalhocookie na mensagem de resposta HTTP

2) Linha de cabeçalhocookie na mensagem de requisição HTTP

3) Arquivo cookiearmazenado no host do usuário e gerenciadopelo browser do usuário

4) Base de dados no sítioWeb

Exemplo:

• Susan sempre acessa a Internet através do mesmoPC

• 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 ID


Cookies: mantendo o “estado” (cont.)

cliente servidor

resposta http

resposta http

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

21


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 quese aprenda bastante sobreo usuário

• Você pode fornecer seunome 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 é feitopor meio de um proxy

• Cliente envia todos ospedidos HTTP para o Web cache

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

• Ou o Web cache solicitaobjeto do servidor original e então envia o objeto aocliente

22


Mais sobre o cache Web

• O cache atua tanto comocliente como servidor

• Tipicamente, o cache éinstalado pelo ISP (universidade, companhia, ISP residencial)

Porque o cache Web?

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

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

• A densidade de caches naInternet 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.5 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.

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.500.000 = 100%

• Atraso total = atraso da LAN + atraso de acesso + atraso da Internet = alguns milissegundos + alguns minutos + 2 seg.

23


Exemplo de caching (cont)

Solução possível• Aumentar a banda do acesso do

enlace para, p. ex., 10 Mbps

consequê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 = msegs + msegs + 2 seg

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

Servidores deorigem

InternetPública


Enlace de acesso1.5 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 servidoresoriginais

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

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

Cacheinstitucional

Servidores deorigem

InternetPública


Enlace de acesso1.5 Mbps

24


GET condicional

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

• Cliente: especifica a data daversão armazenada no pedidoHTTP

If-modified-since: <date>

• Servidor: resposta nãoconté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

Objetonão

modificado

HTTP request msgIf-modified-since: <date>

HTTP responseHTTP/1.1 200 OK

<data>

Objetomodificado




• 2.2 Web e HTTP

• 2.3 FTP


• 2.5 DNS




25


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 deArquivoremoto

usuário


FTP: separa fluxo de controle e fluxode 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 protocolode 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 abreuma 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

26


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




• 2.2 Web e HTTP

• 2.3 FTP


• 2.5 DNS




27


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árioAgentedo

usuário

Servidorde e-mail

Servidorde e-mail


Correio eletrônico: servidores de e-mail

Servidores de e-mail• Mailbox: contém as

mensagens enviadas para o usuário

• Fila de mensagem: contém as mensagens de saída (a seremenviadas)

• Protocolo SMTP: protocoloentre os servidores de e-mail para troca de mensagens� cliente: servidor emissordo e-mail

� “servidor”: servidorreceptor do e-mail

Servidorde e-mail

Agentedo

usuário

SMTP

SMTP

SMTP

Agentedo

usuário

Agentedo

usuário

Agentedo

usuário

Agentedo

usuárioAgentedo

usuário

Servidorde e-mail

Servidorde e-mail

28


Correio eletrônico: SMTP [RFC 2821]

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

• Transferência direta: servidor emissor para servidorreceptor

• 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 paraBob1) Alice usa o agente (UA)

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

2) O agente de Alice envia a mensagem para o seuservidor; 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 naconexão TCP

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

6) Bob evoca o seu agentepara ler a mensagem

1

2 3 4 56

Agentedo

usuário

29


Exemplo de uma interação SMTPS: 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

• Observe 220 reply from server

• Entre os comandos para envio de um e-mail sem a utilização de um cliente de e-mail (reader) HELLO, MAIL FROM, RCPT TO, DATA, QUIT commands

30


SMTP: palavras finais

• SMTP utiliza conexãopersistente

• SMTP requer as mensagens(cabeçalho & corpo) emASCII de 7 bits

• Servidor SMTP utilizaCRLF.CRLF paradeterminar o fim damensagem

Comparação com o HTTP:

• HTTP: pull

• SMTP: push

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

• HTTP: cada objeto éencapsulado na mensagemde resposta

• SMTP: múltiplos objetosenviados na mensagem


Formato da mensagem de e-mail

SMTP: protocolo para trocade mensagens de e-mail

RFC 822: padrão para formatoda mensagem de texto:

• Linhas de cabeçalho, e.x.,� To:

� From:

� Subject:

diferentes dos comandosSMTP !

• body� mensagem codificada com caracteres ASCII

cabeçalho

body

Linhaem branco

31


Formato da mensagem: extensõesmultimí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 paracodificaçã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

32


Protocolo POP3

Fase 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 pelonú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 (mais) 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 emclientes diferentes

• POP3 é do tipo “stateless”

IMAP

• Mantém as mensagens em único lugar: o servidor

• Permite que o usuárioorganize as mensagens empastas

• IMAP mantém o estado do usuário entre sessões:� Nomes dos folders e mapeamento entre o ID das mensagens e o nome dapasta

33




• 2.2 Web e HTTP

• 2.3 FTP


• 2.5 DNS





DNS: Domain Name System

Pessoas: váriosidentificadores:� RG, name, #cic, …

Hosts Internet, roteadores:� Endereço IP (32 bits) –usado para endereçamentode 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 umahierarquia de vários servidoresde nomes

• Protocolo de aplicação permiteque hosts e servidores de nomes comuniquem-se pararesolução de nomes (traduçãonome/endereço)

� nota: função do núcleo daInternet mas implementadacomo um protocolo de camada de aplicação

34


DNS

Por que não um DNS centralizado?

• Ponto único de falha• Volume de tráfico• Base de dados centralizada distante

• manutenção

Não escala!

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; 1st aprox:• Cliente consulta um servidor root para obter o servidor DNS responsável por .com

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

• Cliente consulta servidor DNS amazon.com para obtero endereço IP de www.amazon.com

35


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 autorizado (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 Servidoresautoridades

• Servidores Top-level domain (TLD):� responsáveis por com, org, net, edu, etc, e todosos 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 autoridadespara fornecimento do mapeamento IP para o nomedos servidores da organização (e.x., Web, mail).

� Podem ser mantidos pelas organizações ou peloprovedor de serviço

36


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 servidorDNS local� Atua como um proxy encaminhando a consulta nahierarquia


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 nomeatravé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 nomedo servidor a ser contactado

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

37


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 aoservidor contactado

Exemplo de resolução de nomeDNS


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

� Os servidores TLD em geral encontram-se no cache dos servidores locais• Evita a necessidade de contactar os servidores de nomeroot

• Mecanismos de atualização e notificação encontram-se emfase de especificação pelo IETF� RFC 2136� http://www.ietf.org/html.charters/dnsind-charter.html

38


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

• Type=NS

• Nome é domínio (e.x. foo.com)� Valor é o hostname do servidor autoridade paraeste domínio

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

• Type=A� Nome é hostname

� Valor é endereço IP

• Type=CNAME� name é um alias para algumnome canônico (nome real)

www.ibm.com é, na realidade,servereast.backup2.ibm.com

� Valor corresponde aonome canônico

• Type=MX� value é o nome do servidorde e-mail associado ao name


DNS: protocolo, mensagens

Protocolo DNS : mensagens de consulta e resposta,ambas possuem o mesmo formato

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

para consulta; respostausa o mesmoidentificador

• flags:

� consulta ou resposta

� demanda de recursão

� recursão disponível

� resposta é autorizada

39


DNS: protocolo, mensagens

Nome, tipo da consulta

RRs na respostaa uma consulta

Registros paraservidores autorizados

Inormação adicional


Inserindo registros no DNS

• exemplo: novo domínio “Network Utopia”• Registro do nome networkuptopia.com no DNS (e.g., Network Solutions)� Fornece nomes, endereços IP do servidor de nomesautorizado (primário e secundário)

� 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 autorizado parao nome www.networkutopia.com; registro Type MX para mail.networkutopia.com

40




• 2.2 Web e HTTP

• 2.3 FTP


• 2.5 DNS





P2P: Compartilhamento de arquivo

Exemplo

• Alice executa umaaplicação P2P no seunotebook

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

• Pergunta por “Hey Jude”

• A aplicação informa outros“peers” que possuem umacó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áriosrealizam 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!

41


P2P: diretório centralizado

Projeto original do “Napster”

1) Quando um peer conecta-se, ele informa ao servidorcentral:� Endereço IP

� conteúdo

2) Alice pergunta por “Hey Jude”

3) Alice requisita arquivo damá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

42


Gnutella: inundação

• Completamentedistribuída� Não possui servidorcentral

• Protocolo de domíniopúblico

• Muitos clientesGnutella implementam o protocolo

Rede overlay: grafo

• Arco entre os pares X e Y caso exista uma conexãoTCP entre eles

• Todos os pares ativos e osarcos formam uma redeoverlay

• arco: enlace virtual (nãofí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

r os pares encaminham a mensagem

de Query

r mensagem de QueryHit

enviada no caminho reverso

Escalabilidade:

Limita o escopo da

inundação

43


Gnutella: associação do Peer

1. 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 vizinhosoverlay, os quais …

r 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 conexoesTCP adicionais

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


Overlay Hierárquico

• Situa-se entre a indexaçãocentralizada e a abordagembaseada em inundação

• Cada peer é um líder de grupoou é 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 algunspares 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

44


Comparando as arquiteturas Cliente-Servidor e P2PQuestão : Quanto tempo para distribuir um arquivoinicialmente em um servidor para N outroscomputadores?

us

u2d1 d2u1

dN

uN

Servidor

Rede (possui abundânciade banda)

F, tamanhodo 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 enviasequencialmente 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 Fpara N clientes usando

o modelo cliente-servidor

45


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 quetodos os nós enviam pedaços do arquivo paraalgum 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

ínim

o de

Dis

trib

uiçã

o P2P

Cliente-Servidor

46


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

• Peers podem ir e vir

• Uma vez que o peer possui todo o arquivo, ele pode sair (egoísta) ou ficar (altruista)

47


BitTorrent (2)

Obtendo Chunks

• Em um certo instante, diferentes peers possuemdiferentes subconjuntos de chunks

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

• Alice envia uma solicitaçãopara as partes que ela nãopossui

� 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 nataxa mais elevada� Reavalia os 4 tops a cada 10 segundos

• A cada 30 segundos: selecionaaleatoriamente um outro peer, para o qual começa a enviarchunks

� O novo peer pode fazerparte dos top 4


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)

48


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

• Para obter a chave, fazer o hash da chaveoriginal.� 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óximocorresponde 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

49


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ável

pela chave 1110 ?

Sou eu!

O(N) mensagens na

média para resolver

uma consulta (query)

quando existem N

peers1110

1110

1110

1110

1110

1110

Define o sucessorcomo o peer maispróximo da chave

50


DHT Circular com Atalhos

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

• Reduz as 6 mensagens anteriores para 2 mensagens.• Normalmente adota-se atalhos para O(log N) vizinhos, O(log N) mensagens no caso de uma query

1

3

4

5

810

12

15

Quem é o responsável pelachave 1110?


Dinâmica dos Peers

• Peer 5 falha• Peer 4 deteta; faz o 8 o seu sucessor imediato; perguntaao peer 8 quem é o seu sucessor imediato; torna o sucessorimediato 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 o

endereço IP dos seus 2 sucessores.

• Cada peer faz um ping periodica-

mente para os seus dois sucessores

para verificar se ambos ainda estão

vivos.

51


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 pistasobtidas via engenhariareversa)

• 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 forneceo ID do destino� SN contacta outros SNs(protocolo desconhecido, talvezpor inundação) para encontrar o addr do destino; retorna o addrpara o SC

• SC contacta diretamente o destino via TCP

52




• 2.2 Web e HTTP

• 2.3 FTP


• 2.5 DNS





Programação via Socket

API de socket• Introduzida no Unix FSD4.1,

1981

• Criada, utilizada e encerradade 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 aobyte

Trata-se de uma interface local ao host, criada pelaaplicação e controlada peloSO (“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çõescliente/servidor que se comunicam via socket

53


Programação de socket via TCP

Socket: pode ser visto como uma porta entre o processo de aplicação e o protocolo de transportefim-a-fim (UCP ou TCP)

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

processo


socket

Controlado peloprogramador

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 processoservidor precisa estarexecutando

• 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 aocliente

• Especificação do endereço IP e do número da porta associados aoprocesso servidor

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

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

� Permite que o servidorconverse com múltiplosclientes

� O número da porta de origem serve para distinguiros 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

54


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 paraconnectionSocket

TCP Setup da conexão


Client

process

client TCP socket

Stream: jargão

• um stream é umasequência de bytes queflui 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

outT

oSer

ver

para a rede da rede

inF

rom

Ser

ver

inF

rom

Use

r

teclado monitor

Processo

client

input

stream

inputstream

outputstream

TCPsocket

55


Programação de socket com TCP

Exemplo de aplicaçãocliente-servidor:

1) Cliente lê linha da entrada(input) padrão (inFromUserstream) 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 voltapara o cliente

4) Cliente lê a linha modificadavia socket (inFromServerstream) 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

56


Exemplo: Cliente Java (TCP), cont.

BufferedReader inFromServer = new BufferedReader(newInputStreamReader(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(newInputStreamReader(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

57


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 explicitamenteanexados ao segmento.

• Múltiplos clientes podem acessar o servidor?

114

58




• 2.2 Web e HTTP

• 2.3 FTP


• 2.5 DNS





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 podeser recebido fora de ordemou 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

59


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)

Client

process

client UDP socket

send

Pac

ket

para a rede da rede

rece

iveP

acke

t

inF

rom

Use

r

teclado monitor

Processo

clientSocket

UDPpacket

inputstream

UDPpacket

UDPsocket

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

Entrada: recebepacotes (lembrarque o TCP recebefluxo de bytes)

60


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 datagramacontendo o dado,

tamanho, end. IP e porta

Envia o datagramapara o servidor

Lê o datagramado servidor

61


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

62


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 transportena 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 mensagemrequest/reply:� cliente requisita informaçãoou serviço

� Servidor responde com dados e código de status

• Formatos das mensagens:� cabeçalhos: campos quefornecem informações sobreos 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 darede”

Documents

Capítulo2 Camadade Aplicação - Unicampmarco/cursos/ea074_12_1/slides/2012-Capit… · 2 2: Camadade Aplicação 3 Capítulo2: Camadade Aplicação • 2.1 Princípiosdas aplicaçõesde