Parte 2: Camada de Aplicação Aplicações e Protocolo de Aplicação

Nossos objetivos: Outros objetivos do capítulo Aplicação: processos distribuídos em aplicação

transporte

• conceitual, aspectos de comunicação rede

enlace
• protocolos específicos: física
implementação de – rodam nos computadores
– http
protocolos de aplicação usuários da rede como
– ftp
para redes programas de usuário
– smtp
– trocam mensagens para
– paradigma cliente- – pop
realização da aplicação
servidor – dns
– e.x., email, ftp, Web
– modelos de serviço • programação de aplicações aplicação

de rede
Protocolos de aplicação aplicação
transporte
transporte
rede
• aprenda sobre protocolos rede enlace
– socket API – fazem parte das aplicações enlace física
examinando algumas física

aplicações populares – definem mensagens trocadas e

as ações tomadas
– usam serviços de comunicação
das camadas inferiores

Paradigma Cliente-Servidor
Aplicações de Rede
Aplicações de rede típicas têm duas aplicação
transporte
partes: cliente and servidor rede
enlace

Processo: programa executando • agente usuário: software que física

interfaceia com o usuário de um Cliente: pedido

num host. lado e com a rede de outro. • inicia comunicação com o servidor
• dentro do mesmo host: – implementa protocolo da (“fala primeiro”)
interprocess communication camada de aplicação • tipicamente solicita serviços do resposta
(definido pelo OS). – Web: browser servidor,
• processos executando em – E-mail: leitor de correio • Web: cliente implementado no browser;
– streaming audio/video: e-mail: leitor de correio aplicação
diferentes hosts se transporte
rede
media player Servidor: enlace
comunicam com um protocolo física

da camada de aplicação • fornece os serviços solicitados ao cliente

• e.x., Web server envia a página Web solicitada,
servidor de e-mail envia as mensagens, etc.
 Interfaces de Programação
API: application programming
interface
• define a interface entre a
camada de aplicação e de
transporte
• socket: Internet API
– dois processos se comunicam
enviando dados para o socket
e lendo dados de dentro do
socket
Q: Como um processo “identifica” o
outro processo com o qual ele quer
se comunicar?
– IP address do computador no qual o
processo remoto executa
– “port number” - permite ao
computador receptor determinar o
processo local para o qual a
mensagem deve ser entregue.
Serviços de Transporte
Perda de dados Banda Passante
• algumas aplicações (e.x., aúdio) • algumas aplicações (e.x.,
podem tolerar alguma perda multimedia) exigem uma
• outras aplicações (e.x., banda mínima para serem
transferência de arquivos, telnet)
utilizáveis
exigem transferência de dados
• outras aplicações (“aplicações
100% confiável
elasticas”) melhoram quando
Temporização
a banda disponível aumenta
• algumas aplicações (e.x.,
telefonia Internet, jogos
interativos) exigem baixos
atrasos para operarem

Serviços de Transporte da Internet

Requisitos de Transporte de Aplicações Comuns
serviço TCP: serviço UDP:
Applicação Perdas Banda Sensível ao Atraso • orientado á conexão: conexão • transferência de dados não
requerida entre cliente e servidor confiável entre os processos
file transfer sem perdas elástica não transmissor e receptor
• transporte confiável dados
e-mail sem perdas elástica não perdidos na transmissão são • não oferece: estabelecimento de
Web documents tolerante elástica não recuperados conexão, confiabilidade, controle
real-time audio/video tolerante aúdio: 5Kb-1Mb sim, 100’s msec de fluxo e de congestionamento,
• controle de fluxo:
vídeo:10Kb-5Mb garantia de temporização e de
compatibilização de velocidade
stored audio/video tolerante igual à anterior sim, segundos banda mínima.
entre o transmissor e o receptor
jogos interativos tolerante Kbps sim, 100’s msec
e-business sem perda elástica sim • controle de congestionamento :
protege a rede do excesso de
tráfego
• não oferece: garantias de
temporização e de banda mínima
 Aplicações e Protocolos de Transporte da Internet Protocolo HTTP
Protocolo de Protocolo de
Aplicação Aplicação Transporte
http: hypertext transfer htt
pr
eq u
e-mail smtp [RFC 821] TCP protocol PC rodando htt es t
pr
acesso de terminais remotos telnet [RFC 854] TCP Explorer esp
• protocolo da camada de ons
Web http [RFC 2068] TCP e
aplicação da Web
transferência de arquivos ftp [RFC 959] TCP
• modelo cliente/servidor st
streaming multimedia RTP ou proprietario TCP ou UDP ue
eq Servidor
– cliente: browser que pr nse
htt
(e.g. RealNetworks) po
es rodando
pr
servidor de arquivos remoto NSF TCP ou UDP solicita, recebe e apresenta
t NCSA Web
objetos da Web ht
telefonia Internet RTP ou proprietary tipicamente UDP server
(e.g., Vocaltec) – server: envia objetos em
resposta a pedidos Mac rodando
• http1.0: RFC 1945 Navigator
• http1.1: RFC 2068

Protocolo HTTP Exemplo de Operação

http: protocolo de transporte
TCP:
• cliente inicia conexão TCP (cria
socket) para o servidor na porta
80
• servidor aceita uma conexão
TCP do cliente
• mensagens http (mensagens do
protocolo de camada de
aplicação) são trocadas entre o
browser (cliente http) e o servidor
Web (servidor http)
• A conexão TCP é fechada
http é “stateless”
• o servidor não mantém
informação sobre os pedidos
passados pelos clientes
Protocolos que mantém informações
de estado são complexos!
• necessidade de organizar
informações passadas
• se ocorrer um crash as
informações podem ser perdidas
ou gerar inconsistências entre o
cliente e o servidor
Usuário entra com a URL:
www.someSchool.edu/someDepartment/home.index
1a. cliente http inicia conexão TCP ao
servidor http (processo) em
www.someSchool.edu. Porta 80
é a default para o servidor http .
2. cliente http client envia http request
message (contendo a URL) para o
socket da conexão TCP
tempo
(contém referência a
10 imagens jpeg)
1b. servidor http no host
www.someSchool.edu esperando
pela conexão TCP na porta 80.
“aceita” conexão, notificando o cliente
3. servidor http recebe mensagem de
pedido, forma response message
contendo o objeto solicitado
(someDepartment/home.index),
envia mensagem para o socket
 Exemplo (cont.) Conexões persistentes e não-persistentes

4. servidor http fecha conexão TCP. Não-persistente Persistente

• http/1.0: servidor analisa pedido, • modo default para htp/1.1
envia resposta e fecha a conexão • na mesma conexão TCP são
5. cliente http recebe mensagem de TCP trazidos vários objetos
resposta contendo o arquivo html,
apresenta o conteúdo html. • 2 RTTs para obtr um objeto • o cliente envia pedido para todos
Analisando o arquivo html – Conexão TCP os objetos referenciados tão logo
tempo encontra 10 objetos jpeg – solicitação e transferência do ele recebe a página HTML básica .
referenciados • poucos RTTs, menos slow start.
objeto
6. Passos 1-5 são repetidos para cada um • cada transferência sofre por causa
dos 10 objetos jpeg. do mecanismo de slow-start do TCP
• muitos browser abrem várias
conexões paralelas

Formato das Mensagens HTTP request: formato geral

• dois tipos de mensagens HTTP: request, response
• http request message:
– ASCII (formato legível para humanos)

linha de pedido
(comandos GET GET /somedir/page.html HTTP/1.0
, POST,HEAD ) User-agent: Mozilla/4.0
Accept: text/html, image/gif,image/jpeg
linhas de Accept-language:fr
cabeçalho

Carriage return, (extra carriage return, line feed)

line feed
indica fim da mensagem
 formatos HTTP: response Códigos de status das respostas
linha de status
(protocolo 200 OK
código de status HTTP/1.0 200 OK – request succeeded, requested object later in this message
frase de status) Date: Thu, 06 Aug 1998 12:00:15 GMT
Server: Apache/1.3.0 (Unix) 301 Moved Permanently
Last-Modified: Mon, 22 Jun 1998 …...
linhas de – requested object moved, new location specified later in this
Content-Length: 6821
cabeçalho message (Location:)
Content-Type: text/html
400 Bad Request
data data data data data ...
dados, e.x., – request message not understood by server
arquivo html
404 Not Found
– requested document not found on this server
505 HTTP Version Not Supported

HTTP Cliente: faça você mesmo! Cookies

cliente servidor
1. Telnet para um servidor Web: • gerados e lembrados pelo
servidor, usados mais tarde usual http request msg ação
telnet www.eurecom.fr 80 Abre conexão TCP para a porta 80 específica
(porta default do servidor http) em www.eurecom.fr. para: usual http response +
do cookie
Qualquer coisa digitada é enviada Set-cookie: #
para a porta 80 em www.eurecom.fr
– autenticação
– lembrar preferencias usual http request msg
dos usuários ou prévias ação
2. Digite um pedido GET http: cookie: #
específica
Digitando isto (tecle carriage escolhas usual http response msg
GET /~ross/index.html HTTP/1.0 do cookie
return duas vezes), você envia este • servidor envia “cookie” ao
pedido HTTP GET mínimo (mas completo)
ao servidor http
cliente na resposta HTTP usual http request msg
ação
Set-cookie: 1678453 cookie: #
específica
3. Examine a mensagem de resposta enviada pelo servidor • cliente apresenta o cookie usual http response msg do cookie
http! em pedidos posteriores
cookie: 1678453
 Conditional GET: armazenando no cliente Web Caches (proxy server)
cliente servidor Objetivo: atender o cliente sem envolver o servidor Web
• Razão: não enviar objeto se a
versão que o cliente já possui http request msg
originador da informação
servidor
objeto
If-modified-since:
está atualizada. original
<date>
não Proxy
• cliente: specifica data da • usuário configura o browser: htt
http response modificado pr server reques
t
versão armazenada no pedido acesso Web é feito através de eq u
cliente http es t
htt p se
pon
HTTP/1.0 um proxy res
HTTP 304 Not Modified pon p res
• cliente envia todos os pedidos se htt
If-modified-since: est
u
http para o web cache eq
<date>
http request msg pr nse
– se o objecto existe no web htt es
po
r
• servidor: resposta não tp
If-modified-since:
<date> objeto cache: web cache returna o ht
contém objeto se a cópia é objecto
modificado cliente
atualizada: http response – ou o web cache solicita objecto
servidor
HTTP/1.1 200 OK do servidor original, então original
HTTP/1.0 304 Not envia o objeto ao cliente.
<data>
Modified

Porque Web Caching? ftp: o protocolo de transferência de arquivos

servidores
• armazenamento está originais
“perto” do cliente (ex., na FTP transferência de
Internet FTP FTP
interface cliente arquivos
mesma rede) pública servidor
de usuário
• menor tempo de resposta user
at host sistema de sistema de
arquivos arquivos remoto
• reduz o tráfego para
enlace de acesse local
servidor distante 1.5 Mbps
– links externos podems er rede
• transferência de arquivos de e para o computador remoto
caros e facilmente institucional • modelo cliente servidor
10 Mbps LAN
congestionáveis
– cliente: lado que inicia a transferência (seja de ou para o
lado remoto)
cache – servidor: host remoto
institucional
• ftp: RFC 959
• ftp servidor: porta 21
 ftp: controle separado, conexões de dados ftp: controle separado, conexões de dados

• cliente ftp contata o servidor ftp

na porta 21, especificando TCP
como protocolo de transporte
TCP conexão de controle
• duas conexões TCP paralelas são porta 21
abertas:
– controle: troca de comandos e
TCP conexão de dados
respostas entre cliente e FTP porta 20 FTP
servidor. cliente servidor
“controle out of band”
– dados: dados do arquivo
trocados com o servidor
• servidor ftp mantém o “estado”:
diretório corrente, autenticação PI: protocol interpreter
anterior DTP: data transfer process

fila de
ftp comandos, respostas Correio Eletrônico saída de mensagem
caixa postal
agente
Três componentes principais: usuário

Exemplos de comandos: Exemplos de códigos de • agentes de usuário servidor

agente
de correio
• envie um texto ASCII sobre retorno • servidores de correio usuário
canal de controle • código de status e frase (como • simple mail transfer protocol: SMTP mail
• USER username no http) smtp server agente
usuário
• PASS password • 331 Username OK, SMTP
password required Agente de usuário
• LIST retorna listagem do
• 125 data connection • “leitor de correio” SMTP
arquivo no diretório atual agente
servidor
already open; • composição, edição, leitura de de correio
usuário
• RETR filename recupera transfer starting mensagens de correio
(obtém) o arquivo
• 425 Can’t open data • ex., Eudora, Outlook, elm, agente
• STOR filename armazena o Netscape Messenger usuário
connection
agente
arquivo no host remoto • 452 Error writing • mensagens de entrada e de saída usuário
file são armazenadas no servidor
Correio eletrônico: servidores de correio
Correio Eletrônico: smtp [RFC 821]
agente
usuário
Servidores de Correio
servidor • usa TCP para transferência confiável de mensagens de correio do
• caixa postal contém mensagens agente
de correio cliente ao servidor, porta 25
usuário
que chegaram (ainda não lidas)
SMTP • transferência direta: servidor que envia para o servidor que recebe
para o usuário mail
server • três fases de trasnferência
• fila de mensagens contém as agente
usuário
mensagens de correio a serem SMTP – handshaking (apresentação)
enviadas – transferência de mensagens
• protocolo smtp permite aos SMTP – fechamento
agente
servidor
servidores de correio trocarem usuário • interação comando/resposta
de correio
mensagens entre eles – comandos: texto ASCII
– cliente: servidor de correio agente
usuário – resposta: código de status e frase
que envia
agente • mensagens devem ser formatadas em código ASCII de
– “servidor”: servidor de usuário
correio que recebe 7 bits

Exemplo de interação SMTP

Tente o SMTP você mesmo:
S: 220 hamburger.edu
C: HELO crepes.fr
S: 250 Hello crepes.fr, pleased to meet you
C: MAIL FROM: <alice@crepes.fr> • telnet nome do servidor 25
S: 250 alice@crepes.fr... Sender ok • veja resposta 220 do servidor
C: RCPT TO: <bob@hamburger.edu>
S: 250 bob@hamburger.edu ... Recipient ok • envie comandos HELO, MAIL FROM, RCPT
C: DATA
S: 354 Enter mail, end with "." on a line by itself TO, DATA, QUIT
C: Do you like ketchup? a seqüência acima permite enviar um comando sem
C: How about pickles?
C: . usar o agente de usuário do rementente
S: 250 Message accepted for delivery
C: QUIT
S: 221 hamburger.edu closing connection
 SMTP: palavras finais
• SMTP usas conexões persistentes
• SMTP exige que as mensagens
(cabeçalho e corpo) estejam em
ASCII de 7 bits
• algumas seqüências de caracteres
não são permitidas nas mensagens
(ex., CRLF.CRLF). Assim
mensagens genéricas têm que ser
codificadas (usualmente em “base-
64” ou “quoted printable”)
• Servidor SMTP usa CRLF.CRLF
para indicar o final da mensagem
Formato das Mensagens
Comparação com http: smtp: protocolo para trocar header
• http: pull mensagens de e-mail linha
• email: push em branco
RFC 822: padrão para
• ambos usam comandos e respostas mensagens do tipo texto:
em ASCII, interação comando /
resposta e códigos de status • linhas de cabeçalho, e.g., body
– To:
• http: cada objeto encapsulado na
sua própria mensagem de resposta – From:
• smtp: múltiplos objetos são – Subject:
enviados numa mensagem diferente dos comandos
multiparte SMTP!
• corpo
– a “mensagem”, ASCII
somente com caracteres

Formato das Mensagens: extensões multimedia Tipos MIME

Content-Type: type/subtype; parâmetros
• MIME: multimedia mail extension, RFC 2045, 2056
• linhas adicionais no cabeçalho declaram o tipo de conteúdo
Text Video
MIME
• exemplo de subtipos: plain, • exemplo de subtipos: mpeg,
From: alice@crepes.fr
html quicktime
MIME versão To: bob@hamburger.edu
Subject: Picture of yummy crepe.
método usado MIME-Version: 1.0
Image Application
para codificar dados Content-Transfer-Encoding: base64 • exemplo de subtipos: jpeg, • outros dados que devem ser
Content-Type: image/jpeg gif
multimedia data processados pelo leitor antes de
tipo, subtipo, base64 encoded data .....
serem apresentados
declaração de parâmetro ......................... Audio “visualmente”
......base64 encoded data • exemplo de subtipos: basic • exemplo de subtipos:
dados codificados msword, octet-stream
(codificado 8-bit µ-law ),
32kadpcm (codificação 32
kbps)
 Tipo Multiparte Protocolos de acesso ao correio
From: alice@crepes.fr
To: bob@hamburger.edu SMTP SMTP POP3 or agente
agente
IMAP
Subject: Picture of yummy crepe.
usuário
MIME-Version: 1.0 usuário
Content-Type: multipart/mixed; boundary=98766789
servidor de servidor de
--98766789
correio da origem correio do destino
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain
• SMTP: entrega e armazena no servidor do destino
Dear Bob, • Protocolo de acesso: recupera mensagens do servidor
Please find a picture of a crepe.
--98766789
– POP: Post Office Protocol [RFC 1939]
Content-Transfer-Encoding: base64 • autorização (agente <-->servidor) e download
Content-Type: image/jpeg
– IMAP: Internet Mail Access Protocol [RFC 1730]
base64 encoded data ..... • maiores recursos (mais complexo)
.........................
......base64 encoded data
• manipulação de mensagens armazenadas no servidor
--98766789-- – HTTP: Hotmail , Yahoo! Mail, etc.

protocolo POP3 S: +OK POP3 server ready DNS: Domain Name System
C: user alice
fase de autorização S: +OK
C: pass hungry Domain Name System:
• comandos do cliente: S: +OK user successfully logged on
Pessoas: muitos • base de dados distribuída
– user: declara nome do usuário implementada numa hierarquia de
C: list identificadores:
– pass: password S: 1 498 muitos servidores de nomes
– RG, nome, passporte
• respostas do servidor S: 2 912 • protocolo de camada de aplicação
– +OK S: . Internet hosts, roteadores: host, roteadores se comunicam com
C: retr 1
– -ERR – endereços IP (32 bit) - servidores de nomes para resolver
S: <message 1 contents>
usados para endereçar nomes (translação nome/endereço)
fase de transação, cliente: S: .
C: dele 1 datagramas – nota: função interna da Internet,
• list: lista mensagens e tamanhos C: retr 2 – “nome”, ex., implementeda como protocolo da
• retr: recupera mensagem pelo S: <message 1 contents> gaia.cs.umass.edu - usados camada de aplicação
número S: . por humanos
C: dele 2
– complexidade na “borda” da rede
• dele: apaga Q: relacionar nomes com
C: quit
• quit S: +OK POP3 server signing off endereços IP?
 Servidores de Nomes DNS DNS: Servidores de Nomes Raiz
• são contatados pelos servidores de nomes locais que não podem resolver um nome
• nenhum servidor tem todos os • servidores de nomes raiz::
Porque não centralizar o mapeamentos de nomes para endereços – buscam servidores de nomes autoritativos se o mapeamento do nome não for
DNS? IP conhecido
• ponto único de falha servidores de nomes locais: – conseguem o mapeamento
– cada ISP ou empresa tem um servidor
– returnam o mapeamento para o servidor de nomes local
• volume de tráfego de nomes local (default)
a NSI Herndon, VA
– Consultas dos computadores locais ao c PSInet Herndon, VA k RIPE London
• base de dados distante DNS vão primeiro para o servidor de
d U Maryland College Park, MD
g DISA Vienna, VA
i NORDUnet Stockholm

h ARL Aberdeen, MD
nomes local m WIDE Tokyo
• manutenção e NASA Mt View, CA
j NSI (TBD) Herndon, VA

servidor de nomes autoritativo: f Internet Software C. Palo Alto, CA

– para um computador: armazena o nome

e o endereço IP daquele computador
Não cresce junto com a rede! existem 13 servidores
– pode realizar mapeamentos de nomes de nomes raiz no
b USC-ISI Marina del Rey, CA
para endereços para aquele nome de l ICANN Marina del Rey, CA
mundo
computador

DNS: exemplo simples servidor de nomes DNS: exemplo servidor de nomes

raiz raiz

Servidor de nomes raiz: 2 6

host surf.eurecom.fr quer o 2 4 • pode nãso conhecer o 7 3
5 3
endereço IP de servidor de nomes
gaia.cs.umass.edu autoritativo para um certo
1. contata seu servidor DNS local, nome
dns.eurecom.fr • pode conhecer: servidor de servidor de nomes local servidor de nomes intermediário
2. dns.eurecom.fr contata o servidor de nomes local servidor de nomes autoritativo nomes intermediário: dns.eurecom.fr dns.umass.edu
dns.eurecom.fr dns.umass.edu
servidor de nomes raiz se aquele que deve ser 4 5
necessário 1 8
1 6 contactado para encontrar o
3. o servidor de nomes raiz contata o servidor de nomes
servidor de nomes autoritativo, servidor de nomes autoritativo
dns.umass.edu, se
autoritativo dns.cs.umass.edu
necessário computador solicitante
computador solicitante gaia.cs.umass.edu surf.eurecom.fr
surf.eurecom.fr

gaia.cs.umass.edu
 DNS: consultas encadeadas
consulta recursiva:
• transfere a tarefa de
resolução do nome para o
servidor de nomes
consultado
• carga pesada?
consulta encadeada:
• servidor contactado
responde com o nome de
outro servidor de nomes
para contato computador solicitante
• “Eu não sei isto ,mas
pergunte a este servidor”
DNS: armazenando e atualizando
servidor de nomes
raiz registros
consulta
2 • uma vez que um servidor de nomes apreende um
3 encadeada
4 mapeamento, ele armazena o mapeamento num
registro to tipo cache
7
servidor de nomes local servidor de nomes intermediário
– registro do cache tornam-se obsoletos
dns.eurecom.fr dns.umass.edu (desapareçem) depois de um certo tempo
5 6
1 8 • mecanismos de atualização e notificação estão sendo
projetados pelo IETF
servidor de nomes autoritativo
dns.cs.umass.edu
– RFC 2136
surf.eurecom.fr – http://www.ietf.org/html.charters/dnsind-charter.html
gaia.cs.umass.edu

registros do DNS DNS: protocolo e mensagens

DNS: base de dados distribuída que armazena registros de recursos protocolo DNS: mensagen de consulta e resposta , ambas com o
(RR) mesmo formato de mensagem
formato dos RR: (name, value, type,ttl)
cabeçalho da msg
• identificação: número de 16 bit
• Type=A • Type=CNAME para consulta, resposta usa o
– name é o nome do computador – name é um “apelido” para algum mesmo número
– value é o endereço IP nome “canônico” (o nome real) • flags:
www.ibm.com é realmente
• Type=NS – consulta ou resposta
servereast.backup2.ibm.com
– name é um domínio (ex. – recursão desejada
– value é o nome canônico
foo.com) – recursão disponível
– value é o endereço IP do • Type=MX – resposta é autoritativa
servidor de nomes autoritativo
– value é o nome do servidor de
para este domínio
correio associado com name
 DNS: protocolo e mensagens Programação de Sockets
Objetivo: aprender a construir aplicações cliente/servidor
Campos de nome e tipo que se comunicam usando sockets
para uma consulta
socket
Socket API
RRs de resposta • introduzida no BSD4.1 UNIX, 1981 uma interface local, criada e
a uma consulta possuída pelas aplicações,
• explicitamente criados, usados e
liberados pelas aplicações controlada pelo OS (uma
registros para “porta”) na qual os processo
• paradigma cliente/servidor
servidores autoritativos de aplicação podem tanto
• dois tipos de serviço de transporte
via socket API:
enviar quanto receber
informação adicional mensagens de e para outro
– datagrama não confiável
que pode ser útil processo de aplicação (local
– confiável, orientado a cadeias de
ou remoto)
bytes

Programação de Sockets com TCP

Programação de Sockets com TCP
Cliente deve contactar o servidor • Quando o cliente cria o socket:
Socket: uma porta entre o processo de aplicação e o cliente TCP estabelece conexão com
• processo servidor já deve estar
protocolo de transporte fim-a-fim (UCP or TCP) executando antes de ser contactado o TCP do servidor
serviço TCP: trnasferência confiável de bytes de um • servidor deve ter criado socket • Quando contactado pelo cliente, o
(porta) que aceita o contato do TCP do servidor cria um novo
processo para outro cliente socket para o processo servidor
comunicar-se com o cliente
Cliente contata o servidor através de:
controlado pelo – permite o servidor conversar
controlado pelo processo processo
criador da aplicação • criando um socket TCP local
com múltiplos clientes
criador da aplicação
socket socket • especificando endereço IP e
TCP com TCP com controlado pelo
controlado pelo número da porta do processo ponto de vista da aplicação
sistema buffers, buffers, sistema
internet variáveis
servidor
TCP fornece a transferência
operacional variáveis operacional
confiável, em ordem de bytes
host o host ou (“pipe”) entre o cliente e o
servidor servidor servidor
 Programação de Sockets com TCP Interação Cliente/servidor: TCP
teclado monitor
Servidor (executando em hostid) Cliente
Exemplo de aplicação cliente-
servidor: cria socket,
port=x, para

inFromUser
input
• cliente lê linha da entrada padrão do stream
solicitação entrante:
welcomeSocket =
sistema (inFromUser stream) , processo stream de entrada:
ServerSocket()
Process
envia para o servidor via socket cliente seqüência de bytes TCP cria socket,
(outToServer stream) para dentro do processo
espera por pedido
estabel. de conexão
stream de saída: de conexão entrante conecta com hostid, port=x
• servidor lê linha do socket clientSocket =
seqüência de bytes connectionSocket =
Socket()
para fora do processo welcomeSocket.accept()
• servidor converte linha para letras

inFromServer
outToServer
maiúsculas e envia de volta ao cliente output input
envia pedido usando
stream stream
lê pedido de clientSocket
• cliente lê a linha modificada através connectionSocket
do (inFromServer stream)
TCP socket
clientSocket
escreve resposta para
cliente TCP
connectionSocket lê resposta de
socket clientSocket
fecha
para rede da rede fecha
connectionSocket
clientSocket

Exemplo: cliente Java (TCP) Exemplo: cliente Java (TCP), cont.

import java.io.*;
import java.net.*; Cria BufferedReader inFromServer =
class TCPClient { stream de entrada new BufferedReader(new
ligado ao socket InputStreamReader(clientSocket.getInputStream()));
public static void main(String argv[]) throws Exception
{ sentence = inFromUser.readLine();
String sentence;
String modifiedSentence; Envia linha outToServer.writeBytes(sentence + '\n');
para o servidor
Cria
BufferedReader inFromUser = modifiedSentence = inFromServer.readLine();
stream de entrada Lê linha
new BufferedReader(new InputStreamReader(System.in));
do servidor
Cria System.out.println("FROM SERVER: " + modifiedSentence);
socket cliente, Socket clientSocket = new Socket("hostname", 6789);
conecta ao servidor clientSocket.close();
Cria DataOutputStream outToServer =
stream de saída new DataOutputStream(clientSocket.getOutputStream()); }
ligado ao socket }
 Exemplo: servidor Java (TCP) Exemplo: servidor Java (cont)
import java.io.*;
import java.net.*;
Cria stream de
class TCPServer { saída, ligado ao DataOutputStream outToClient =
socket new DataOutputStream(connectionSocket.getOutputStream());
public static void main(String argv[]) throws Exception
{ Lê linha do
String clientSentence;
socket clientSentence = inFromClient.readLine();
Cria String capitalizedSentence;
socket de aceitação capitalizedSentence = clientSentence.toUpperCase() + '\n';
ServerSocket welcomeSocket = new ServerSocket(6789);
na porta 6789 Escreve linha
outToClient.writeBytes(capitalizedSentence);
Espera, no socket while(true) { para o socket
}
de aceitação por Socket connectionSocket = welcomeSocket.accept(); }
contato do cliente } Fim do while loop,
BufferedReader inFromClient = retorne e espere por
Cria stream de new BufferedReader(new outra conexão do cliente
entrada, ligado InputStreamReader(connectionSocket.getInputStream()));
ao socket

Programaçaõ de Sockets com UDP Interação Cliente/servidor: UDP

Servidor (executando hostid) Cliente
UDP: não há conexão entre o cria socket, cria socket,
cliente e o servidor port=x, para clientSocket =
solicitação entrante: DatagramSocket()
• não existe apresentação ponto de vista da aplicação serverSocket =

UDP fornece a transferência

• transmissor envia
explicitamente endereço IP e
porta de destino em cada
DatagramSocket()
Cria, endereço (hostid, port=x,
não confiável de grupos de bytes envia datagrama de pedido
(“datagramas”) entre o cliente e o lê pedido de:
usando clientSocket

mensagem servidor serverSocket

• servidor deve extrair o endereço escreve resposta para

IP e porta do transmissor de serverSocket
lê resposta de
especificando endereço
cada datagrama recebido do host cliente e clientSocket

• UDP: dados transmitidos número da porta fecha

podem ser recebidos foram de clientSocket

ordem ou perdidos
 Exemplo: cliente Java (UDP) Exemplo: cliente Java (UDP)
teclado monitor

import java.io.*;
import java.net.*;

inFromUser
stream
de entrada
class UDPClient {
processo public static void main(String args[]) throws Exception
Process Entrada: recebe
cliente Cria
{
pacote (TCP recebe
“byte stream”) stream de entrada BufferedReader inFromUser =
Saída: envia pacote
new BufferedReader(new InputStreamReader(System.in));
(TCP envia “byte Cria

receivePacket
sendPacket
stream”) pacote pacote
socket cliente DatagramSocket clientSocket = new DatagramSocket();
UDP UDP
Translada
nome do host para InetAddress IPAddress = InetAddress.getByName("hostname");
socket UDP
clientSocket endereço IP
cliente UDP usando DNS byte[] sendData = new byte[1024];
socket
byte[] receiveData = new byte[1024];
para rede da rede

String sentence = inFromUser.readLine();

sendData = sentence.getBytes();

Exemplo: cliente Java (UDP), cont. Exemplo: servidor Java (UDP)

Cria datagrama com
dados a enviar, import java.io.*;
DatagramPacket sendPacket = import java.net.*;
tamanho, endereço IP
new DatagramPacket(sendData, sendData.length, IPAddress, 9876);
porta
class UDPServer {
Envia datagrama clientSocket.send(sendPacket); public static void main(String args[]) throws Exception
para servidor Cria {
DatagramPacket receivePacket =
socket datagrama
new DatagramPacket(receiveData, receiveData.length); DatagramSocket serverSocket = new DatagramSocket(9876);
na porta 9876
Lê datagrama
clientSocket.receive(receivePacket);
do servidor byte[] receiveData = new byte[1024];
byte[] sendData = new byte[1024];
String modifiedSentence =
new String(receivePacket.getData()); while(true)
{
System.out.println("FROM SERVER:" + modifiedSentence);
Cria espaço para
clientSocket.close();
}
datagramas recebidos DatagramPacket receivePacket =
new DatagramPacket(receiveData, receiveData.length);
} Recebe serverSocket.receive(receivePacket);
datagrama
 Exemplo: servidor Java, (cont.) Programação de Sockets: referências
String sentence = new String(receivePacket.getData());
Obtém endereço IP
tutorial sobre C-language tutorial (audio/slides):
InetAddress IPAddress = receivePacket.getAddress();
e número da porta
do transmissor • “Unix Network Programming” (J. Kurose),
int port = receivePacket.getPort();
http://manic.cs.umass.edu.
String capitalizedSentence = sentence.toUpperCase();

sendData = capitalizedSentence.getBytes();
Cria datagrama Tutoriais sobre Java:
DatagramPacket sendPacket =
para enviar ao cliente
new DatagramPacket(sendData, sendData.length, IPAddress, • “Socket Programming in Java: a tutorial,”
port);
Escreve o http://www.javaworld.com/javaworld/jw-12-1996/jw-12-
datagrama para serverSocket.send(sendPacket);
dentro do socket } sockets.html
}
} Termina o while loop,
retorna e espera por
outro datagrama

Parte 2: Sumário
Parte 2: Sumário
Nosso estudo das aplicações está agora completo!
Mais importante: características dos protocolos
• tipica troca de mensagens
• exigências dos serviços de • protocolos especificos: • controle vs. dados
comando/resposta:
aplicação: – http – in-band, out-of-band
– cliente solicita informação ou
– confiabilidade, banda – ftp serviço • centralizado vs. descentralizado
passante, atraso – smtp, pop3 • stateless vs. stateful
– servidor responde com dados e
• paradigma cliente-servidor – dns código de status • transferência de mensagens
• programação de sockets confiável vs. não confiável
• modelo do serviço de – formatos das mensagens:
• “complexidade na borda da rede”
transporte da Internet l – implementação cliente/servidor – cabeçalhos: campos que dão
informações sobre os dados • segurança: autenticação
– orientado à conexão, – usando sockets tcp, udp
confiável: TCP – dados: informação sendo
– não confiável, datagramas: comunicada
UDP