La Capa de Aplicación

Albeiro Corts Cabezas. Ph.D.
Grupo de Tratamiento de Seales y Telecomunicaciones - GTST

LA CAPA DE APLICACIN
Unidad Temtica 1
Principios de las
aplicaciones de red
Web y HTTP
FTP
Correo electrnico
SMTP, POP3, IMAP
DNS
Aplicaciones P2P
Programacin de
Sockets con TCP
Programacin de
Sockets con UDP
Capa de aplicacin
Principios de las
aplicaciones de red
Web y HTTP
FTP
Correo electrnico
SMTP, POP3, IMAP
DNS
Aplicaciones P2P
Programacin de
Sockets con TCP
Programacin de
Sockets con UDP
Capa de aplicacin
Aplicaciones: la interfaz entre las
personas y la red de datos
Algunas aplicaciones de red
Correo electrnico
Navegadores
Mensajera
instantnea
Acceso remoto
Intercambio de
archivos P2P
Juegos multiusuario
Clip de videos
almacenados
Voz sobre IP
Videoconferencia en
tiempo real
Diseo de aplicaciones de red
Escribir programas que:
Se puedan ejecutar sobre
diferentes sistemas
terminales
Se comuniquen a travs de la
red
ej., el software del servidor
web se comunica con
diferentes navegadores
No es necesario escribir software
para los dispositivos en el corazn
de la red
Los dispositivos del corazn no
ejecutan aplicaciones de
usuario
Las aplicaciones en los
sistemas terminales permiten
un rpido desarrollo y
propagacin de las aplicaciones
Arquitecturas de las aplicaciones de red
Cliente-servidor
Peer-to-peer (P2P)
Hbridas entre cliente-servidor y P2P
Arquitectura Cliente-servidor
servidor:
Siempre encendido
Direccin IP permanente
Granja de servidores
clientes:
Solicita comunicacin con
el servidor
Se conecta en forma
intermitente
Puede tener direccin IP
dinmica
No se comunica
directamente con otros
clientes
Arquitectura Cliente-servidor
Arquitectura P2P pura
No hay servidor encendido
permanentemente
Los sistemas terminales se
comunican directamente
Los pares se conectan en
forma intermitente y
cambian dinmicamente sus
direcciones IP
Es altamente escalable pero
difcil de administrar
Hbrido entre cliente-servidor y P2P
Skype
Aplicacin P2P de voz sobre IP
Servidor centralizado: Buscando
direcciones de pares remotos
Conexin directa cliente-cliente
Mensajera instantnea
El chat entre dos usuarios es P2P
Servicio centralizado: registro del
cliente
El usuario registra su direccin IP con el
servidos central cuando igresa al sistema
Los usuarios contactan al servidos central
para encontrar la direccin IP de sus amigos
Procesos de comunicacin
Proceso: programa en
ejecucin dentro de un
host.
Dentro del mismo host
dos programas procesos
se comunican usando
comunicacin inter-
procesos (definido por
el S.O).
Procesos en diferentes
hosts se comunican a
travs del intercambio
de mensajes
Proceso Cliente: proceso
que inicia la
comunicacin
Proceso Servidor:
proceso que espera
para ser contactado
Nota: aplicaciones con
arquitectura P2P tienen
procesos cliente y procesos
servidor
Sockets
Los procesos envan/reciben
mensajes a/desde su socket
El socket es anlogo a una
puerta
El proceso transmisor pone el
mensaje en la puerta
El proceso transmisor depende
de la infraestructura de
transporte al otro lado de la
puerta, la cual lleva al mensaje
hasta el socket en el proceso
receptor
API: (1) escoge el protocolo de transporte; (2) puede fijar unos pocos
parmetros
Direccionamiento
Para recibir mensajes, el proceso debe tener
un identificador
El host tiene una direccin IP nica de 32-bit
Q: La direccin IP de un host es suficiente
para identificar el proceso?
- No, muchos procesos pueden ejecutarse
simultneamente en el mismo host
Direccionamiento
El identificador incluye una direccin IP y unos
nmeros de puertos asociados con el proceso que
se ejecuta sobre el host.
Ejemplos de nmeros de puerto:
HTTP server: 80
Mail server: 25
Para enviar mensajes HTTP al servidor web
gaia.cs.umass.edu web server:
Direccin IP: 128.119.245.12
Puerto nmero: 80
Los protocolos de la capa de aplicacin
definen
Tipos de mensajes
intercambiados,
ej., requerimiento, respuesta
Sintaxis del mensaje:
Campos en el mensaje y como
son delineados
Semantica del mensaje
Significado de la informacin
contenida en los campos
Reglas para definir cuando
y como los procesos envian
y responden los mensajes
Protocolos de dominio
pblico:
Definidos en RFCs
Permiten
interoperabilidad
entre diferentes
redes y equipos
ej., HTTP, SMTP
Protocolos propietarios:
ej., Skype
Qu servicios de transporte necesitan las
aplicaciones?
Prdida de datos
Algunas aplicaciones (ej.,
audio) pueden tolerar
algunas prdidas
Otras aplicaciones (ej.,
transferencia de archivos,
telnet) requieren una
transferencia de datos
100% confiable
Retardo
Algunas aplicaciones
(ej., VoIP, juegos
interactivos) requieren
bajo retardo para ser
efectivos
Caudal
Algunas aplicaciones (ej.,
multimedia) requieren un
caudal mnimo para ser
efectivas
Otras aplicaciones
(aplicaciones elsticas)
del caudal disponible
Seguridad
Cifrado, integridad de los
datos,
Requerimiento de servicios de transporte en
aplicaciones comunes
Application
file transfer
e-mail
Web documents
real-time audio/video
stored audio/video
interactive games
instant messaging
Data loss
no loss
no loss
no loss
loss-tolerant
loss-tolerant
loss-tolerant
no loss
Throughput
elastic
elastic
elastic
audio: 5kbps-1Mbps
video:10kbps-5Mbps
same as above
few kbps up
elastic
Time Sensitive
no
no
no
yes, 100s msec
yes, few secs
yes, 100s msec
yes and no
Servicios de los protocolos de
transporte en Internet
ServiciosTCP:
Orientado a conexin: requiere
establecer una sesin entre los
procesos cliente y servidor
Ttransporte confiable entre el
proceso transmisor y receptor
Control de flujo: el transmisor
no abrumar al receptor
Control de congestin: regular
al transmisor cuando la red este
sobrecargada
No provee: control de retardo,
garantas de caudal mnimo,
seguridad
Servicios UDP:
Transferencia de datos no
confiable entre procesos
transmisor y receptor
No provee:
establecimiento de sesin,
confiabilidad, control de
flujo, control de
congestin, control de
retardo, garantas de
caudal, ni seguridad
Q: porque existe UDP?
Aplicaciones de Internet: protocolos de
aplicacin y transporte
Application
e-mail
remote terminal access
Web
file transfer
streaming multimedia
Internet telephony
Application
layer protocol
SMTP [RFC 2821]
Telnet [RFC 854]
HTTP [RFC 2616]
FTP [RFC 959]
HTTP (eg Youtube),
RTP [RFC 1889]
SIP, RTP, proprietary
(e.g., Skype)
Underlying
transport protocol
TCP
TCP
TCP
TCP
TCP or UDP
typically UDP
Principios de las
aplicaciones de red
Web y HTTP
FTP
Correo electrnico
SMTP, POP3, IMAP
DNS
Aplicaciones P2P
Programacin de
Sockets con TCP
Programacin de
Sockets con UDP
Capa de aplicacin
Web y HTTP
Una pgina Web est compuesta de objetos
Los objetos pueden ser archivos HTML, imgenes
JPEG, applets Java, archivos de audio,
Una pgina Web page consta de un archivo HTML
base el cual incluye varias referencias a objetos
Cada objeto es direccionable por medio de un URL
Ejemplo URL:
www.someschool.edu/someDept/pic.gif
host name
path name
HTTP: introduccin
HTTP: protocolo de
transferencia de
hipertexto
Protocolo de aplicaciones
Web
Modelo cliente/servidor
cliente: browser que
solicita, recibe y
despliega objetos
Web
servidor: servidor Web
enva objetos en
respuesta a
requerimientos
Usa TCP:
El cliente inicia una conexin
TCP (crea un socket) con el
servidor, puerto 80
El servidor acepta la
conexin TCP del cliente
Los mensajes HTTP
(amensajes del protocolo de
capa de aplicacin) son
intercambiados entre el
browser (cliente HTTP) y el
servidor Web (servidor
HTTP)
La conexin TCP es cerrada
HTTP es sin estados
El servidor no guarda
informacin de las
solicitudes que el
cliente hizo antes.
HTTP: introduccin
Conexiones HTTP
Conexin HTTP no
persistente
A lo sumo un objeto es
enviado a travs de
una conexin TCP.
Conexin HTTP
persistente
Mltiples objetos
pueden ser enviados a
travs de la misma
conexin TCP entre
cliente y servidor.
Una de las principales diferencias entre la versin HTTP1.0 y HTTP1.1
HTTP no-persistente
Suponga que el usuario ingresa la URL
www.someSchool.edu/someDepartment/home.index
1a. El cliente HTTP inicia una
conexin TCP con el servidor
HTTP (proceso) en
www.someSchool.edu sobre el
puerto 80
2. El cliente HTTP enva un
mensaje de solicitud HTTP
(conteniendo el URL) a travs
del socket de conexin TCP. El
mensaje indica que el cliente
desea el objeto
someDepartment/home.index
1b. El servidor HTTP en el host
www.someSchool.edu esta
esperando solicitudes de
conexin TCP en el puerto 80.
acepta la conexin y notifica
al cliente
3. El servidor HTTP recibe el
mensaje de solicitud, crea un
mensaje de respuesta
conteniendo el objeto
solicitado, y enva el mensaje
al socket
(contiene texto,
referencias a 10
Imgenes jpeg
5. El cliente HTTP recibe el
conteniendo el archivo html y
lo despliega. Analiza
gramticamente el archivo,
encuentra 10 referencias a
objetos jpeg
6. Los pasos 1-5 son repetidos
para cada uno de los 10
objetos jpeg
4. El servidor HTTP cierra la
conexin TCP.
HTTP no-persistente (cont..)
HTTP no-persistente: tiempo de
respuesta
Definicin de RTT: tiempo
necesario para que un
paquete pequeo viaje
desde el cliente hasta el
servidor y regrese.
Tiempo de respuesta:
Un RTT para iniciar la
conexinTCP
Un RTT para la solicitud
HTTP y primeros bytes de
la respuesta HTTP
Tiempo de transmisin del
archivo
total = 2RTT+transmit time
HTTP persistente
Desventajas de HTTP no-
persistente:
Consume 2 RTTs por objeto
El OS se sobrecarga por
cada conexin TCP
Los browsers a menudo
abren conexiones TCP
paralelas TCP para traer
objetos referenciados
HTTP persistente
El servidor deja abierta la
conexin despus de enviar
la respuesta
Subsecuentes mensajes
HTTP entre el mismo
cliente y servidor se envan
sobre la conexin abierta
El cliente enva solicitudes
tan pronto como encuentra
objetos referenciados
Mensaje de solicitud HTTP
Dos tipos de mensajes HTTP: solicitud, respuesta
Mensaje de solicitud HTTP:
ASCII (formato legible por humanos)
GET /somedir/page.html HTTP/1.1
Host: www.someschool.edu
User-agent: Mozilla/4.0
Connection: close
Accept-language:fr
(extra carriage return, line feed)
request line
(GET, POST,
HEAD commands)
header
lines
Carriage return,
line feed
indicates end
of message
Mensaje de solicitud HTTP: formato
general
Cargando formatos de entrada
Mtodo Post:
Las pginas Web a
menudo incluyen
formularios de entrada
El formulario es
cargado al servidor en
el cuerpo de la entidad
entity body
Mtodo HEAD:
Similar al mtodo GET
La informacin es
cargada en la lnea de
campo URL:
www.somesite.com/animalsearch?monkeys&banana
Tipos de Mtodos
HTTP/1.0
GET
POST
HEAD
Indica al servidor que
no incluya el objeto
solicitado en la
respuesta. Utilizado en
operaciones de prueba y
configuracin.
HTTP/1.1
GET, POST, HEAD
PUT
Permite subir objetos
en el servidor en una
ruta especificada en el
URL
DELETE
Borra archivos
especificados en el
campo URL
Mensaje de respuesta HTTP
Cdigos de estado HTTP en los
mensajes de respuesta
200 OK
request succeeded, requested object later in this message
301 Moved Permanently
requested object moved, new location specified later in
this message (Location:)
400 Bad Request
request message not understood by server
404 Not Found
requested document not found on this server
505 HTTP Version Not Supported
En la primera lnea en el mensaje de respuesta del servidor al cliente.
Algunos ejemplos de cdigos :
Web caches (servidor proxy)
Usuarios configuran el
browser: acceso Web
va cache
El browser enva todas
las solicitudes HTTP a
la cache
La cache retorna los
objetos
La cache tambin
solicita objetos al
servidor original, y
entonces entrega los
objetos al cliente.
meta: satisfacer las solicitudes del cliente sin involucrar el servidor original
Ms sobre Web caching
La cache acta como
cliente y servidor
Tpicamente la cache
es instalada por el ISP
(university, company,
residential ISP)
Porqu usar Web caching?
reduce el tiempo de
respuesta a las solicitudes
del cliente
Reduce el trfico sobre el
enlace de acceso a una
institucin.
Ayuda a reducir el trfico
en Internet.
GET condicional
meta: no enviar un objeto a la
cache si sta tiene una
versin actualizada
cache: especifica la fecha de
la copia almacenada en la
solicitud HTTP
If-modified-since: <date>
server: si los objetos de la
copia almacenada estn
actualizados responde:
HTTP/1.0 304 Not Modified
Cookies?
Principios de las
aplicaciones de red
Web y HTTP
FTP
Correo electrnico
SMTP, POP3, IMAP
DNS
Aplicaciones P2P
Programacin de
Sockets con TCP
Programacin de
Sockets con UDP
Capa de aplicacin
FTP: file transfer protocol
Transferencia de archivos a/desde un host remoto
Modelo cliente/servidor
cliente: lado que inicia la conexin
server: host remoto
ftp: RFC 959
ftp server: puerto 21
file transfer
FTP
server
FTP
user
interface
FTP
client
local file
system
remote file
system
user
at host
FTP: separa conexiones de control y datos
El cliente FTP contacta al
servidor FTP a travs del puerto
21
El cliente es autorizado a travs
de la conexin de control
El cliente navega en el directorio
remoto enviando comandos a
travs de la conexin de control
Cuando el servidor recibe un
comando de transferencia de
archivo abre una segunda
conexin TCP para transferir el
archivo al cliente
Despus de transferir un archivo
el servidor cierra la conexin de
datos
FTP
client
FTP
server
TCP control connection
port 21
TCP data connection
port 20
El servidor abre otra
conexin de datos TCP para
transferir otro archivo
Conexin de control: out of
band
El servidor FTP mantiene el
estado: directorio actual,
previa autenticacin del
usuario
FTP comandos, respuestas
Comandos comunes:
Enviados como texto
ASCII a travs del canal
de control
USER username
PASS password
LIST retorna la lista de
archivos en el directorio
actual
RETR filename recupera
(extrae) un archivo
STOR filename almacena
(pone) un archivo en el host
remoto
Respuestas comunes
Cdigo de estado y frase
(como en HTTP)
331 Username OK,
password required
125 data connection
already open; transfer
starting
425 Cant open data
connection
452 Error writing file
Principios de las
aplicaciones de red
Web y HTTP
FTP
Correo electrnico
SMTP, POP3, IMAP
DNS
Aplicaciones P2P
Programacin de
Sockets con TCP
Programacin de
Sockets con UDP
Capa de aplicacin
Correo electrnico
Correo electrnico
Tres principales componentes:
Agentes de usuario
Servidores de correo
Protocolo de transferencia de
archivo simple: SMTP
Agente de usuario
Conocido como. lector de correo
composicin, edicin, lectura de
mensajes de correo
ej., Eudora, Outlook, Mozilla
Thunderbird
Salida, entrada de mensajes
almacenados en el servidor
Correo electrnico
Servidores de correo
Buzn de correo contiene los
mensajes entrantes para el
usuario
Cola de mensajes de coreo
de salida (para ser enviados)
Protocolo SMTP entre
servidores de correo para
intercambiar mensajes de
correo
cliente: enva correo al
servidor
servidor: recibe correo
de servidor
Utiliza TCP para transferir mensajes de correo desde el
cliente al servidor, puerto 25
Transferencia directa: de servidor transmisor a servidor
receptor
Tres fases de transferencia
handshaking (saludo)
Transferencia de mensajes
cierre
Interaccin comando/respuesta
comandos: texto ASCII
respuesta: cdigo de estado y frase
Los mensajes deben estar en cdigo ASCII de
7-bits
Correo electrnico: SMTP [RFC 2821]
Correo electrnico: escenario
SMTP usa conexiones
persistentes
SMTP requiere que los
mensajes (header & body)
tengan formato ASCII 7-
bit
El servidor el servidor
SMTP usa CRLF.CRLF para
indicar el final del mensaje
Comparacin con HTTP:
HTTP: pull
SMTP: push
Ambos tienen interaccin
comando/respuesta ASCII,
cdigos de estado
HTTP: cada objeto es
encapsulado en su propio
SMTP: mltiples objetos
son enviados en un mismo
mensaje
Correo electrnico
SMTP: protocolo para
intercambiar mensajes de
correo
RFC 822: estndar para el
formato de los mensajes de
texto:
Lneas de cabecera, ej.,
To:
From:
Subject:
cuerpo
El mensaje, caracteres
ASCII solamente
header
body
blank
line
Formato de mensaje
Protocolos de acceso a los mensajes
SMTP: entrega/almacenamiento al servidor del receptor
Protocolo de acceso al correo: recupera mensajes del servidor
POP: Post Office Protocol [RFC 1939]
autorizacin (agent <-->server) y descarga
IMAP: Internet Mail Access Protocol [RFC 1730]
Ms caractersticas (ms complejo)
Manipulacin de mensajes almacenados en el servidor
HTTP: gmail, Hotmail, Yahoo! Mail, etc.
Ms de POP3
El ejemplo previo
utiliza el modo
descargue y borre.
El usuario no puede
releer el mensaje si
cambia el cliente
descargue y guarde:
copia de mensajes en
diferentes clientes
POP3 es sin estados a
travs de las secciones
IMAP
Mantiene todos los
mensajes en un lugar: el
servidor
Permite a los usuarios
organizar los mensajes el
folders
IMAP mantiene el estado
del usuario a travs de las
secciones:
Protocolo POP3 e IMAP
Principios de las
aplicaciones de red
Web y HTTP
FTP
Correo electrnico
SMTP, POP3, IMAP
DNS
Aplicaciones P2P
Programacin de
Sockets con TCP
Programacin de
Sockets con UDP
Capa de aplicacin
DNS: Domain Name System
Internet hosts, routers:
Direcciones IP (32 bits)
usadas para direccionar
datagramas
nombres, ej.,
ww.yahoo.com usado
por los seres humanos
Q: porque mapear entre
direcciones IP y
nombres?
Domain Name System:
Base de datos distribuida
implementada
jerarquicamente en muchos
servidores de nombre
Protocolo de capa de
aplicacin
host, routers, servidores de
nombres se comunican para
resolver nombres (traduccin
direccin/nombre)
nota: funcin del corazn
de Internet, implementada
como protocolo de la capa
de aplicacin
DNS
Porqu no centralizar DNS?
nico punto de falla
Volumen de trfico
Base de datos
centralizada y distante
Mantenimiento
No es escalable
Servicios DNS
Traduccin nombre de
host a direccin IP
Alias de host
Nombres cannicos,
alias
Alias del servidor de
correo
Distribucin de carga
Servidores web
replicados: conjunto de
direcciones IP para un
nombre cannico
Root DNS Servers
com DNS servers
org DNS servers edu DNS servers
poly.edu
DNS servers
umass.edu
DNS servers
yahoo.com
DNS servers
amazon.com
DNS servers
pbs.org
DNS servers
Base de datos jerrquica y distribuida
Un cliente desea la direccin IP de www.amazon.com; 1
st
aprox:
Solicita a un servidor raz encontrar el servidor DNS .com
Solicita al servidor DNS .com obtener el servidor DNS de
amazon.com
Solicita al servidor DNS amazon.com resolver la direccin IP
para www.amazon.com
DNS: servidores de nombre raz
Contactado por servidores de nombre local que no pueden resolver un
nombre
Servidor de nombre raz:
Contacta a servidores de nombre autoritativos si no conoce la
traduccin.
Realiza la traduccin
Devuelve la readuccin al servidor DNS local
Servidores TLD y Autoritativos
Servidores de nivel superior (TLD):
responsables por com, org, net, edu, etc, y todos
los dominios de nivel superior de los pases, uk, fr,
ca, jp.
La empresa Network Solutions mantiene los
servidores para el dominio de nivel superior TLD
.com
Educause mantiene el dominio TLD .edu
Servidores DNS autoritativos:
Los servidores DNS de las organizaciones prestan
el servicio de traduccin a los host y servidores de
la empresa
Puede ser mantenido por la organizacin o un ISP
Servidor de nombres local
No pertenece estrictamente a la jerarqua
Cada ISP (ISP residencial, compaia,
universidad) tiene uno.
Tambin llamado servidor de nombres
por defecto
Cuando un host hace una solicitud DNS,
sta es enviada a su servidor de nombres
local
Acta como proxy, pasa la solicitud a
travs de la jerarqua
Ejemplo de resolucin DNS
El host en cis.poly.edu
desea la direccin IP
de gaia.cs.umass.edu
Solicitud interactiva:
El servidor
contactado responde
con el nombre del
servidor a contactar
no conozco este
nombre, pero
pregntale a este
servidor
DNS: Cacheo y actualizacin de
registros
Una vez cualquier servidor de nombres aprende
una traduccin almacena una nueva entrada
Las entradas desaparecen despus de algn
tiempo
Los servidores TLD son cacheados
tpicamente en servidores de nobres locales
Por lo tanto los servidores de nombres raz no son
visitados con frecuencia
Los mecansmos de actualizacin y notificacin
son diseados por la IETF
RFC 2136
http://www.ietf.org/html.charters/dnsind-charter.html
Registros DNS
DNS: base de datos distribuida que almacena registros de recursos (RR)
Type=NS
name es un dominio (ej.
foo.com)
value es un nombre de
host de un servidor de
nombres autoritativo
para este dominio
Formato RR: (name, value, type, ttl)
Type=A
name es un nombre de host
value es una direccin IP
Type=CNAME
name es un alias para algn
nombre canonico (el real)
www.ibm.com es realmente
servereast.backup2.ibm.com
value es un nombre cannico
Type=MX
value es el nombre de un
servidor de correo asociado
con name
Mensajes del protocolo DNS
Protocolo DNS : mensajes de solicitud y respuesta, ambos
tienen el mismo formato de mensaje
Encabezado de msg
identificacin: 16 bit #
para solicitud, respuestas
a solicitud usan el mismo #
flags:
Solicitud o respuesta
recursin deseada
recursin disponible
Respuesta es
autoritativa
DNS protocol, messages
Name, type fields
for a query
RRs in response
to query
records for
authoritative servers
additional helpful
info that may be used
Principios de las
aplicaciones de red
Web y HTTP
FTP
Correo electrnico
SMTP, POP3, IMAP
DNS
Aplicaciones P2P
Programacin de
Sockets con TCP
Programacin de
Sockets con UDP
Capa de aplicacin
Aplicaciones P2P
No siempre hay un servidor
encendido
Sistemas terminales
arbitrario se comunican
directamente
Los pares se comunican de
forma intermitente y
cambian sus direcciones IP
Distribucin de archivos: cliente-
servidor vs P2P
Q : cuanto tiempo se necesita para distribuir un archivo
desde un servidor a N pares?
u
s
: ancho de banda de
subida desde el
servidor
u
i
: ancho de banda
de subida desde el
par i
d
i
: ancho de banda
de descarga del par i
Tiempo de distribucin del archivo:
servidor-cliente
El servidor
secuencialmente
enva N copias:
Tiempo = NF/u
s
El cliente i toma F/d
i
minutos para
descargar
Incrementa linealmente en N
(para N grande)
= d
cs
= max { NF/u
s
, F/min(d
i
) }
i
Tiempo para distribuir F a
N clientes usando
el mtodo cliente/servidor
Tiempo de distribucin del archivo : P2P
El servidor debe enviar
una copia: tiempo=F/u
s
El cliente i gasta F/d
i
segundos en descargarlo
NF bits deben ser
descargados (aggregate)
La ms rpida velocidad de descarga posible: u
s
+ Su
i
d
P2P
= max { F/u
s
, F/min(d
i
) , NF/(u
s
+ Su
i
) }
i
0
0.5
1
1.5
2
2.5
3
3.5
0 5 10 15 20 25 30 35
N
M
i
n
i
m
u
m

D
i
s
t
r
i
b
u
t
i
o
n

T
i
m
e
P2P
Client-Server
Servidor-cliente vs. P2P: ejemplo
Velocidad de subida en el cliente = u, F/u = 1 hour, u
s
= 10u, d
min
u
s
Skype
Inherentemente P2P:
comunicacin entre pares
de usuarios.
Protocolo de capa de
aplicacin propietario
Tarea
Leer las secciones:
2.6.1 BitTorrent, 2.6.2 Tablas Hash distribuidas, 2.6.3 Skype, 2.7 Sockets
con TCP y 2.8 Sockets con UDP

La Capa de Aplicación

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

La Capa de Aplicación

Transféré par

Droits d'auteur :

Formats disponibles

Albeiro Corts Cabezas. Ph.D.

Grupo de Tratamiento de Seales y Telecomunicaciones - GTST

Vous aimerez peut-être aussi