Diseño de Protocolos
Prof. Wilmer Pereira
1
Protocolo

Protocolo:
– Es un conjunto de normas y reglas, convenidas de
mutuo acuerdo entre todos los participantes en
una comunicación, estas reglas deben estar
organizadas y no tener ambigüedad.

Su misión es:
– Hacer que la comunicación entre computadoras
de una red sea posible.
2
Elementos Claves de un Protocolo

Para que dos entidades se comuniquen
con éxito, se requiere que hablen el
mismo idioma.
 Las entidades deben seguir una serie de
convenciones mutuamente aceptadas a
fin de saber:
– Qué se comunican
– Cómo se comunican
– Cuándo se comunican
3
Elementos Claves de un Protocolo
Los puntos claves que definen o
caracterizan a un protocolo son:

Conjunto de mensajes válidos

Características de cada tipo mensaje:
– Aspectos Sintácticos
(campos que contiene + formato) y
– Aspectos Semánticos (significado de los
campos + acciones asociadas)
4
Elementos Claves al Diseñar un
Protocolo de Comunicación
1)
2)
3)
4)
5)
6)
7)
8)
Identificar los actores y los roles que juegan.
Identificar los servicios que cada actor va a
ofrecer.
¿cómo “direccionar” cada actor?
Definir los mensajes que usará el protocolo
Definir el formato de las tramas de los
mensajes
Definir el significado o la interpretación de
los campos de los mensajes
Definir el intercambio de mensajes
Definir como manejar los casos de error
5
¿Qué aspectos se deben considerar al
diseñar un Protocolo de
comunicación a nivel de Aplicación?

¿Cuales son las necesidades de información de la aplicación?.

¿Cómo es el esquema de comunicación que debe ocurrir entre
los actores?:
– ¿Quien habla primero, quien escucha, quien habla luego?
– ¿Hay sólo una pregunta y una respuesta?, ¿la interacción incluye
una secuencia de requerimientos y respuestas encadenados?, ¿se
pide una confirmación de cada mensaje? o ¿se pide solamente
una confirmación global?.
– ¿Cuál o cuáles son las secuencias correctas de comunicación?
– ¿Qué hacer cuando se rompe una secuencia correcta de
comunicación?
– ¿Qué debe ocurrir en el caso de que se interrumpa una
comunicación?
– ¿Qué debe ocurrir en el caso que una comunicación no pueda
establecerse?
6
Principios de diseño para protocolos
Los principios pueden resumirse en:
1) Asegurarse que la comunicación funciona
Hacer prototipos para probar conceptos, no publicar el estándar y
luego probarlo
2.) Mantener el protocolo simple
Si hay duda, usar la solución mas simple. Evitar funcionalidades
innecesarias.
3) Tomar decisiones claras
Evitar múltiples formas de hacer una misma cosa. (En especial cuando
los resultados pueden no ser los mismos)
4) Usar modularidad
Esto lleva al diseño de protocolos en pilas
5) Esperar heterogeneidad
En una red grande habrán diferentes tipos de hardware, medios, etc.
Por esto el diseño debe ser simple, general y flexible.
7
Principios de diseño para protocolos
de Red
6) Evitar opciones y parámetros estáticos
Si hay parámetros inevitables (e.g., tamaño de paquete), no dejarlos
fijos, que los extremos negocien para llegar a un acuerdo.
7) Tener un buen diseño, sin necesariamente buscar que sea perfecto
A veces es mejor no contemplar ciertas condiciones para mantener un
diseño limpio y simple; las excepciones que se manejen aparte
8) Ser estrictos al enviar y tolerantes al recibir
Enviar paquetes que se apeguen completamente a los estándares,
pero ser capaces de recibir y manejar los que no lo hagan
9) Pensar en la escalabilidad del sistema
Si se van a tener millones de nodos, no se puede pensar en bases de
datos centralizadas y la carga deber distribuirse lo más posible
10) Considerar desempeño y costo
Si una red o un aplicación tiene pobre desempeño o resulta muy cara,
nadie la usará
8
Comportamiento de las entidades en
el protocolo
Cada una de las entidades que emplean el protocolo debe:



Aceptar todas las secuencias correctas de mensajes
Detectar cualquier secuencia incorrecta de mensajes
Recuperarse a partir de algún error que el protocolo detecte
La automatización se puede describir mediante una máquinas o
autómata de estados finitos.


Definir el conjunto de las sentencias de entrada y salida
Definir el conjunto de estados y las transiciones entre ellos
9
Bases del Modelo de capas

Cada capa del modelo tiene sus
funciones

Se definen protocolos para cada capa
de manera que la capa C de una
máquina pueda comunicarse con la
capa C de otra máquina
10
Capas
Aplicación
HTTP, FTP, DNS
Transporte
TCP, UDP, RTP, SCTP
Internet
Para redes TCP/IP es el IP
Enlace
Ethernet, Token Ring, PPP, HDLC,
Frame Relay, RDSI, ATM, IEEE
802.11, FDDI
medio físico, y técnicas de
codificación
Físico
11
Características
Ejemplo de un protocolo
Orientado a bit y con
tamaño fijo
12
Capa de red: Datagrama IP
13
Protocolos de
aplicación
Ejemplo de un protocolo
Orientado a byte con
tamaños de trama
variables
14
Protocolo de aplicación

Protocolos de Aplicación comunes son:
– HTTP: es el Protocolo de Transferencia de Hipertexto (en
inglés HyperText Transfer Protocol).
– FTP: es el Protocolo de Transferencia de Archivos(en inglés
File Transfer Protocol).
– SMTP: es el Protocolo de Transferencia de Correo (en
inglés Simple Mail Transfer Protocol).
– IRC: es el Chat Basado en Internet (en inglés Internet Relay
Chat).
15
Protocolos de Aplicación
Facilitan la comunicación entre una
aplicación y un servidor.
 Tienden a consistir en estos tres
puntos:

– Abrir la conexión.
– Hacer y satisfacer peticiones de servicio.
– Manejar e informar de errores.
– Cerrar la conexión
16
Protocolo de aplicación (HTTP)
Cliente
Servidor
Establecimiento de la conexión
GET http:// www.ldc.usb.ve/redes1/material.html HTTP/1.0<CR><LF>
User-agent Mozilla/6.0<CR><LF>
Accept: text/html, image/gif, image/jpg<CR><LF>
Accept-languaje:es<CR><LF>
<CR><LF><CR><LF>
HTTP/1.0 200 OK
Date: Thu, 23 Nov 2008 12:00:15 GMT
Server: Apache/2.0 (Unix)
Last-Modified: Mon, 10 Sept 2007
Content-Length:6821
Content-Type: text/html
<html> <body> Esta es la pagina de Respuesta</body>
<body> Esta es la pagina de Respuesta</body>
</html>
17
Ejemplo 1 … sencillo …

Se requiere un servidor que sume
varios números enteros y retorne el
resultado.

Ideas?
18
Consideraciones …






Identificar los actores participantes en la comunicación.
¿Quién tiene y quién requiere la información del sistema?
Identificar cuál es el rol de cada uno de los actores participantes
( cliente, servidor, cliente/servidor, pares o peer-to-peer).
¿Como se van a identificar o diferenciar estos actores?
(direccionamiento)
¿Cuáles son las necesidades de información de la aplicación?
¿Cómo es el esquema de comunicación que debe ocurrir entre los
actores?:
– ¿Quien habla primero, quien escucha, quien habla luego?
– ¿Hay sólo una pregunta y una respuesta, la interacción incluye una secuencia
de requerimiento y respuestas encadenados, se pide confirmación de cada
mensaje ?
– ¿Cuál o cuales son las secuencias correctas de comunicación ?
– ¿Qué hacer cuando se rompe una secuencia correcta de comunicación?
– ¿Qué debe ocurrir en el caso que se interrumpa una comunicación ?
– ¿Qué debe ocurrir en el caso que una comunicación no pueda establecerse ?
19
Posible solución …

Debemos definir los tipos de mensajes:
– Request
– Responses
– Errors

Se podría tomar un delimitador o
conjunto de delimitadores para marcar
inicio y fin de los elementos de cada
mensaje
20
Posible solución …

Request
– Formato: numOperan%operand1%operand2%...operanN%
– Ejemplo: 4%1%2%3%4%

Response
– Formato: result%
– Ejemplo: 10%

Error: con literales o códigos de error
– Ejemplo: “Overflow %”
– Ejemplo: “Unknow format %”
21
Ejemplo 2

Se requiere un servidor que tome los
datos de una persona (nombre, cedula,
edad, sexo, dirección, teléfono) y
realice una inscripción en un curso y
responda con la información sobre el
curso: horarios, lugar.

Ideas?
22
Soluciones?
¿Nos puede servir la solución anterior?
 ¿Que pasa con el delimitador?
 ¿Podríamos colocar tamaño fijo a los
campos de datos?
 ¿Que pasa con datos de tamaño
variable?

23
Soluciones

Este tipo de datos requieren un formato
más sofisticado

Y algunas veces de herramientas que
permitan definir estas especificaciones

Por ejemplo: usar un lenguaje de
marcado como XML
24
Lenguajes de
marcado
XML
25
Xml (eXtensible Markup
Language)






XML es un metalenguaje que define la sintaxis
utilizada para definir otros lenguajes de etiquetas
estructurados.
Xml define la estructura del documento, en un
lenguaje de descripción de datos.
Es mucho mas estricto que HTML. No sustituye al
HTML.
Legible por usuarios humanos y aplicaciones
informáticas.
Permite la intercomunicación entre aplicaciones.
Contiene metainformación (metadatos)
26
XML: Lo bueno.

Es multiplataforma.

Tiene curva de aprendizaje muy plana.

Puede ser barato (muchos editores,
visores, verificadores, etc., gratuitos y
comerciales).
27
Formato

Todo elemento esta delimitado
< />

Un elemento puede ser sencillo
<elemento/>

Tener un atributo
<elemento campo=“valor entre comillas”/>

Puede tener sub elementos
<elemento>
<sub …/>
</elemento>
28
XML
Ejemplo
29
Estructura lógica
courses
course
codc
student
“cs100”
course
student codc
student
“cs225”
...
id
name grade
“123” “Pepe” “3”
id
name grade
“124” “Luís” “4
30
Estructura del XML
<courses>
<course>
<codc>cs100</codc>
<student>
<id>123</id>
<name>Pepe<name/>
<grade>3<grade/>
</student>
<student>
<id>124</id>
<name>Luis<name/>
<grade>5<grade/>
</student>
</course>
...
...
<course>
<codc>cs225</codc>
<student>
<id>124</id>
<name>Luis<name/>
<grade>4<grade/>
</student>
<student>
<id>125</id>
<name>Ana<name/>
<grade>4<grade/>
</student>
...
</course>
...
</courses>
31
Ahora... otro ejemplo.

Lo que importa es el delimitado de xml

Los espacios, los LF, CR, líneas en
blanco no importan
32
Otro ejemplo diferente
<Courses>
<Course [email protected]>
<student ID=“123”>
<grade=“3”/>
<name=“Pepe”/>
</estudent>
<student ID=“124”>
<grade=“2”/>
<name=“Paco”/>
</student>
...
</Course>
...
</Courses>
33
El Otro ejemplo diferente
<Courses>
<Course [email protected]>
<student ID=“123”>
<grade=“3”/>
<name=“Pepe”/>
</student>
<student ID=“124”>
<grade=“2”/>
<name=“Paco”/>
</student>
...
</Course>
...
</Courses>
34
Recapitulemos: Ejemplo

Se requiere un servidor que tome los
datos de una persona (curso,nombre,
cedula, edad, sexo, dirección, teléfono)
y realice una inscripción en un curso y
responda con la información sobre el
curso, horarios, lugar.
35
Request: Format
<inscripcion>
<Curso ID= “”/>
<estudiante ID=“”>
<ci val=“”/>
<nombre val=“”/>
<telefono val=“”/>
<direccion val=“”/>
...
</estudiante>
...
</inscripcion>
36
Request: Especificaciones
Para cursos:
ID es un valor entero
Para Estudiante:
...
...
37
Request: Ejemplo
<inscripcion>
<Curso ID= “123”/>
<estudiante ID=“123”>
<ci val=“11”/>
<nombre val=“Pepe”/>
<telefono val=“99”/>
<direccion val=“por ahi”/>
...
</estudiante>
...
</inscripcion>
38
Response: Format
<inscripcionOK>
<Curso ID= “”>
<lugar>
</lugar>
<horario>
<dia ID=“” hora=“”/>
<dia ID=“” hora=“” />
</horario>
</Curso>
</inscripcionOK>
39
Response: Especificaciones
Para cursos:
ID es un valor entero
...
...
40
Response: Ejemplo
<inscripcionOK>
<Curso ID= “123”>
<lugar>
En la esquina de X con Y, edificio
ZZ, piso 666, etc
</lugar>
<horario>
<dia ID=“lun” hora=“5pm-7pm”/>
<dia ID=“vie” hora=“5pm-7pm” />
</horario>
</Curso>
</inscripcionOK>
41
Response mas detallado (dos formas
diferentes de anotar la misma información)
<horario>
<dia ID=“lun” hora=“5pm-7pm”/>
<dia ID=“vie” hora=“5pm-7pm”/>
</horario>
<horario>
<dia d=“lun”>
<hora inc=“5pm” fin=“7pm”/>
</dia>
<dia ID=“vie”>
<hora inc=“5pm” fin=“7pm”/>
</dia>
42
</horario>
El procesador XML (parser).

Software que reconoce e interpreta las reglas
del XML.
– También se le llama analizador o intérprete
XML.
 Con XML bien formado:
– Revisa que el documento siga las reglas
del XML para considerarse bien formado.
43
Protocolos y
Herramientas para describir
los protocolos
Diagrama de secuencia
Diagrama de estados
(autómata de estado finitos)
44
Diagramas de secuencia

Diagrama que muestra las interacciones
entre los objetos organizadas en una
secuencia temporal.
 En particular muestra los objetos
participantes en la interacción y la secuencia
de mensajes intercambiados.
 Se usa para indicar cuál es el intercambio de
mensajes que debe ocurrir entre los
componentes involucrados
45
46
47
Diagrama de estados de una cafetera
48
Cliente
Servidor
Diagrama de estados
Login+clave
Inicio
fallo
Diagrama de secuencia
Espera
autenticación
autenticado
quit
Recibe
comandos
quit
respuesta
comando
Espera
respuesta
49
HTTP
Prof. Ricardo
Gonzalez
Redes de Computadores Tema 4
50
Web y HTTP
Algunos términos
● Una página Web consta de objetos
● Los objetos pueden ser un archivo HTML, una imagen JPEG,
un applet Java, un archivo de audio,…
● Una página Web consta de un archivo HTML base que incluye
diversos objetos referenciados
● Cada objeto se direcciona con un URL
● Ejemplo de un URL:
http:// www.algunsitio.edu:80/algunaFacultad/pic.gif
Protocolo
Prof. Ricardo
Gonzalez
Nombre del host
Nombre del path
Redes de Computadores
51
Panorámica de HTTP
HTTP: Protocolo de
Transferencia de
HiperTexto
● Es el protocolo de la
capa de aplicación para
el Web
● Usa el modelo
cliente/servidor
● Cliente: browser o
navegador que solicita,
recibe y muestra los
objetos Web
● Servidor: Servidor www
que envía objetos en
respuesta a las
solicitudes del browser
● HTTP 1.0: RFC 1945
● HTTP 1.1: RFC 2068
Prof. Ricardo
Gonzalez
PC ejecutando
IE Explorer
Servidor
ejecutando
El servidor Web
Apache
Mac ejecutando
Netscape Navigator
Redes de Computadores Tema 4
52
Funcionamiento de HTTP
Funcionamiento
1. El cliente realiza una petición o apertura activa
(request) al servidor (puerto 80, por defecto)
2. Solicita la transacción (request) con HTTP: GET,
POST, HEAD, PUT, …
3. El servidor envía la respuesta (response) en HTML
4. Se cierra la conexión (en HTTP/1.0)
Prof. Ricardo
Gonzalez
Redes de Computadores
53
Mensajes HTTP
•
Dos tipos de mensajes usando ASCII (texto plano):
• Request (Solicitud)
• Response (Respuesta)
•
Solicitudes HTTP/1.0
Prof. Ricardo
Gonzalez
Redes de Computadores
54
Mensajes HTTP
Respuestas HTTP/1.0
Prof. Ricardo
Gonzalez
Redes de Computadores Tema 4
55
Mensajes HTTP
Ejemplo real de mensajes HTTP
Prof. Ricardo
Gonzalez
Redes de Computadores Tema 4
56
Modelamiento del tiempo de respuesta
Definición de RTT: tiempo para
enviar un pequeño paquete
y que este viaje desde el
cliente hasta el servidor y
que regrese.
Tiempo de respuesta:
•
Un RTT para iniciar la
conexión TCP
•
Un RTT para la solicitud
HTTP y para que los
primeros bytes de la
respuesta HTTP regresen
•
Tiempo de transmisión del
archivo
Inicia Conexión
TCP
total = 2RTT+tiempo de transmisión
Prof. Ricardo
Gonzalez
RTT
solicita
archivo
tiempo para
transmitir
archivo
RTT
archivo
recibido
tiempo
Redes de Computadores Tema 4
tiempo
57
Mensaje de solicitud HTTP: formato general
Prof. Ricardo
Gonzalez
Redes de Computadores Tema 4
58
Mensaje de respuesta de HTTP
Línea de estado
(código de
estado del
Protocolo,
frase de estado)
Líneas
de encabezado
datos, es decir,
archivo HTML
solicitado
Prof. Ricardo
Gonzalez
HTTP/1.1 200 OK
Connection close
Date: Thu, 06 Aug 1998 12:00:15 GMT
Server: Apache/1.3.0 (Unix)
Last-Modified: Mon, 22 Jun 1998 …...
Content-Length: 6821
Content-Type: text/html
datos datos datos datos datos ...
Redes de Computadores Tema 4
59
eMail
Prof. Ricardo
Gonzalez
Redes de Computadores Tema 4
60
email
•
•
•
•
•
Arquitectura de un sistema de correo
electrónico
SMTP
POP3
IMAP
RFC 822
Prof. Ricardo
Gonzalez
Redes de Computadores Tema 4
61
Arquitectura del sistema de correo
• Funciones (o servicios) del sistema de correo:
• edición de mensajes
• Transferencia de mensajes
• generación de informes
• Subsistemas
• de distribución
Agentes de transferencia
(demonios)
(SMTP, ESMTP)
• de entrega final
(POP3, IMAP)
Prof. Ricardo
Gonzalez
Redes de Computadores Tema 4
62
Protocolos de entrega final de usuario
Solución: un buzón en el servidor
conexión NO
permanente
conexión permanente
Internet
PC emisor
Agente de
transferencia
(SMTP)
POP3
Servidor
Agente de
usuario
PC receptor
(con buzón)
Problema: obtener correo del buzón
Solución: POP3
Prof. Ricardo
Gonzalez
Redes de Computadores Tema 4
63
Agentes de transferencia de distribución (SMTP)
El SMTP
• protocolo sencillo cliente/servidor
• formato ASCII
• Establecer comunicación TCP al puerto 25
Prof. Ricardo
Gonzalez
Redes de Computadores Tema 4
64
Correo electrónico
Tres componentes
principales:
•
•
•
Agentes de usuario
Servidores de correo
Protocolo simple de
transferencia de correo:
SMTP
Agente de usuario
•
•
•
•
Conocido como “lector de
correo”
Permite elaborar, editar y leer
mensajes de correo.
Ejemplos: Eudora, Outlook,
elm, Netscape Messanger
Recupera los mensajes
colocados en el servidor
Prof. Ricardo
Gonzalez
Agente de
usuario
servidor de
correo
Agente de
usuario
SMTP
SMTP
servidor de
correo
Agente de
usuario
SMTP
Agente de
usuario
servidor de
correo
Agente de
usuario
Agente de
usuario
Redes de Computadores Tema 4
Cola de
mensajes salientes
Buzón del
usuario
65
Correo electrónico: SMTP [RFC 2821]
•
•
•
•
•
Utiliza TCP para transferir confiablemente mensajes de correo
desde el cliente al servidor, utiliza el puerto 25
Transferencia directa: entre el servidor que envía y el servidor
que recibe
La transferencia tiene tres fases
• handshaking (saludo)
• Transferencia de los mensajes
• cierre
Interacción comando/respuesta
• Comandos: texto ASCII
• Respuesta: códigos de estado y frase
Los mensajes deben estar en ASCII de 7 bits
–
Prof. Ricardo
Gonzalez
Redes de Computadores Tema 4
66
Agentes de transferencia de
distribución (SMTP) : protocolo
El servidor comienza por enviar una línea de texto que
proporciona su identidad e indica si está preparado
o no para recibir correo:
a.- Si no lo está, el cliente libera la conexión y lo intenta después.
b.- Si está dispuesto a aceptar correo electrónico, el cliente anuncia
de quién viene el mensaje, y a quién está dirigido. Si existe tal
destinatario en el destino, el servidor da al cliente permiso para
enviar el mensaje. Entonces el cliente envía el mensaje y el
servidor genera un acuse de recibo. Si existe más correo
electrónico también se envía ahora. Una vez que todo el correo
ha sido intercambiado en ambas direcciones, se libera la
conexión.
Prof. Ricardo
Gonzalez
Redes de Computadores Tema 4
67
Comandos SMTP: cliente
Comando
HELO
MAIL FROM:
RCPT TO:
DATA
RSET
NOOP
QUIT
VRFY
EXPN
HELP
TURN
SOML
SAML
SEND
Prof. Ricardo
Gonzalez
Descripción
Identifica el remitente al destinatario.
Identifica una transacción de correo e identifica al emisor.
identificar un destinatario individual
Se utiliza para
. Si se necesita
identificar múltiples destinatarios
es necesario repetir el comando.
Permite enviar una serie de líneas de texto. El tamaño máximo de una línea es
de 1.000 caracteres. Cada línea va seguida de un retorno de carro y avance de
La última línea debe llevar únicamente el carácter punto “.”
línea <CR><LF>.
seguido de <CR><LF>.
Aborta la transacción de correo actual.
Indica al extremo que envíe una respuesta positiva
No operación.
.
Keepalives
Pide al otro extremo que envíe una respuesta positiva y cierre la conexión.
Pide al receptor que confirme que un nombre identifica a un destinatario válido
confirmación de una lista de correo
Pide al receptor la
y que devuelva los
nombres de los usuarios de dicha lista.
Pide al otro extremo información sobre los comandos disponibles
inviertan los papeles , para poder actuar como receptor.
El emisor pide que se
El receptor puede negarse a dicha petición.
Si el destinatario está conectado, entrega el mensaje directamente al terminal,
en caso contrario lo entrega como correo convencional.
Entrega del mensaje en el buzón del destinatario. En caso de estar conectado
también lo hace al terminal.
Si el destinatario está conectado, entrega el mensaje directamente al terminal.
Redes de Computadores Tema 4
68
Códigos de respuesta SMTP: servidor
C ód igo
211
214
220
221
250
251
354
421
450
451
452
500
501
502
503
504
550
551
552
553
554
D escrip ción
E stado del sistem a.
M ensaje de ayuda.
S ervicio prep arad o.
S ervicio cerran d o el can al d e transm isión .
S olicitu d com p letad a con éxito.
U suario no local, se enviará a < dirección de reenvío>
In trod u zca el texto, fin alice con < C R > < L F > .< C R > < L F > .
S ervicio no disponible.
S olicitud de correo no ejecutada, servicio no disponible (buzón ocupado).
A cción no ejecutada, error local de procesam iento.
A cción no ejecutada, insuficiente espacio de alm acenam iento en el sistem a.
E rror de sintaxis, com ando no reconocido.
E rror de sintaxis. P .ej con testación d e SM T P a E S M T P
C om ando no im plem entado.
S ecuencia de com andos errónea.
P arám etro no im plem entado.
S olicitud no ejecutada, buzó n no disponible.
U suario no local, pruebe < dirección de reenvío> . Si n o se tien e cu enta
A cción de correo solicitada abortada.
S olicitud no realizada (error de sintaxis).
F allo en la transacción.
Prof. Ricardo
Gonzalez
Redes de Computadores Tema 4
69
Ejemplo del uso de comandos SMTP
Prof. Ricardo
Gonzalez
Redes de Computadores Tema 4
70
Ejemplo de la interacción SMTP
S:
C:
S:
C:
S:
C:
S:
C:
S:
C:
C:
C:
S:
C:
S:
220 hamburger.edu
HELO crepes.fr
250 Hello crepes.fr, pleased to meet you
MAIL FROM: <[email protected]>
250 [email protected].. Sender ok
RCPT TO: <[email protected]>
250 [email protected] ... Recipient ok
DATA
354 Enter mail, end with "." on a line by itself
¿Te gusta la salsa de tomate?
¿y los pepinillos?
.
250 Message accepted for delivery
QUIT
221 hamburger.edu closing connection
Prof. Ricardo
Gonzalez
Redes de Computadores Tema 4
C
C
C
C
C
C
C
C
C
C
->
<->
<->
<->
<->
<-
S
S
S
S
S
S
S
S
S
S
C
C
C
C
->
<->
<-
S
S
S
S
71
Interacción SMTP hecha “a mano” :
•
telnet nombre_servidor 25
•
Se observa el código 220 como respuesta del
servidor
Se digitan los comandos HELO, MAIL FROM, RCPT
TO, DATA, QUIT
•
Lo anterior le permite enviar un mensaje de correo
electrónico sin utilizar el cliente de correo
Prof. Ricardo
Gonzalez
Redes de Computadores Tema 4
72
Links

Algunos protocolos de capa aplicación
–
–
–
–

HTML 1.0 1.1
FTP
SSH
SMTP
Tutoriales XML
– Introducción al lenguaje XML
– Documentos XML bien formados
– Algunos ejemplos!!!
73
Fuentes

Protocolos en Internet.
http://fcqi.tij.uabc.mx/docentes/lpalafox/curso
s/redes/protInternet.pdf
 Clase de Diseño de Protocolos del Prof.
Eduardo Blanco.
 Xinu. Protocol Design.
http://www.tml.tkk.fi/Opinnot/T110.300/2003/Luennot/145-management.pdf
74
Descargar

ClaseProtocolos2 - Laboratorio Docente de Computación