Introduccin a los protocolos.

Csar Llamas Bello

Octubre, 2011. Sistemas Distribuidos, Grado en Informtica
1
Indice
ndice
1. Nociones bsicas sobre protocolos 1
1.1. Descripcin de protocolos . . . . . . . . . . . . . . . . . . . . . . . 1
1.2. Caractersticas del diseo de un protocolo . . . . . . . . . . . . . . . 3
1.3. Servicio y suposiciones sobre el entorno . . . . . . . . . . . . . . . . 3
1.4. Vocabulario y formato de mensajes de un protocolo . . . . . . . . . . 5
1.5. Reglas de procedimiento de un protocolo . . . . . . . . . . . . . . . 6
1.6. Ejemplo de diagramas de tipo de proceso (ujo) . . . . . . . . . . . . 9
1.7. Propiedades deseables en un protocolo . . . . . . . . . . . . . . . . . 10
2. Los protocolos de Internet 11
2.1. Sociedades de Internet . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2. RFC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3. Ejemplo de RFC: El RFC 2821 (SMTP) . . . . . . . . . . . . . . . . 12
3. Resumen de la unidad 22
1. Nociones bsicas sobre protocolos
Qu es un protocolo?
Acuerdo de comunicacin que afecta al intercambio de informacin en el sis-
tema.
Se considera una norma a seguir para integrar entidades activas en la aplicacin:
usuarios,
objetos activos,
sistemas, ?
Los protocolos son una especie de algoritmos distribuidos.
Un protocolo implementa una funcin de comunicacin donde se dene un ser-
vicio.
1.1. Descripcin de protocolos
El protocolo como un lenguaje
La denicin de un protocolo se asemeja mucho a la denicin de un lenguaje:
Se dene un formato preciso para los mensajes vlidos (SINTAXIS);
Se denen reglas de procedimiento para el intercambio de datos
(pasos a seguir en el intercambio de mensajes) (ALGORITMO/COORDINACION)
Grado en Informtica - SD (2011) - Protocolos 2
Denen un vocabulario de mensajes vlidos junto a su signicado (SEMANTI-
CA)
Elementos de un protocolo
La especicacin completa de un protocolo contiene:
El servicio proporcionado por el protocolo.
Los supuestos sobre el entorno en el que se ejecuta el protocolo.
El vocabulario de los mensajes empleados en la implementacin del protocolo.
El formato (codicacin) de cada mensaje del vocabulario.
Las reglas de procedimiento que mantienen la consistencia de los intercambios
de mensajes.
Ciclo de vida
Versin inicial de la norma
(formal o semiestructurada)
Versin detallada de la norma
(formal o semiestructurada)
conjunto
de
pruebas
banco
de
pruebas
Verificacin y validacin
+ anlisis de prestaciones
+ prototipado.
Diseo de pruebas
Reelaboracin
Reelaboracin
Diseando un protocolo
Principio de diseo:
Todo protocolo debera ser considerado incorrecto a menos que se pruebe lo
contrario.
En primer lugar hay que enumerar el vocabulario de primitivas.
Ej.: conecta, envia, error, ack, desconecta
Grado en Informtica - SD (2011) - Protocolos 3
En segundo lugar, el formato de cada primitiva.
Ejemplos:
conecta(identidad).
enva(destinatario, mensaje).
error(mensaje).
1.2. Caractersticas del diseo de un protocolo
Diseando un protocolo
En tercer lugar, las reglas por las que se rigen las secuencias de mensajes. Hay
diversas posibilidades de realizar la descripcin:
Hacerlo informalmente en texto, o
Hacerlo formalmente mediante:
Diagramas de secuencia de tiempo.
Diagramas de tipo de proceso en SDL (System Design Language).
Diagramas de estado y/o actividad en UML 2.0.
Lenguajes especiales (Promela, etc.).
Reglas de procedimiento
Las reglas del procedimiento dicen qu secuencias de mensajes son admisibles
en el protocolo.
Suelen expresarse como autmatas: guiados por eventos (que disparan tran-
siciones).
Los eventos se almacenan en colas de entrada a las acciones.
En SDL se utiliza algo parecido a diagramas de ujo con estados.
1.3. Servicio y suposiciones sobre el entorno
Ejemplo - Protocolo de Lynch
Especicacin del servicio
Transferir archivos como secuencia de caracteres por la lnea telefnica evitando
errores de transmisin, suponiendo que pueden detectarse todos los errores.
Es una transferencia de archivos full-duplex.
Se envan reconocimientos positivos y negativos para el trco de Aa Bmediante
la lnea de B a A (y viceversa).
Cada mensaje tiene dos partes, una de mensaje, y otra de control que se aplica al
trco en el canal contrario.
Grado en Informtica - SD (2011) - Protocolos 4
Ejemplo - Protocolo de Lynch (ii)
Suposiciones sobre el entorno
El entorno consta de dos usuarios del servicio y un canal de transmisin.
Cada usuario pide un archivo y espera la vuelta.
Se supone que el canal distorsiona arbitrariamente el mensaje, pero no pierde,
inserta, duplica, ni reordena los mensajes.
Se parte de la existencia de un mdulo de nivel inferior que atrapa las distorsiones
y reparte mensajes no distorsionados de tipo err.
Servicio y suposiciones sobre el entorno
Cada protocolo se compone de operaciones bsicas proporcionadas por el entorno.
As, la realizacin concreta de un servicio depende de las suposiciones sobre el
entorno en que se ejecuta el protocolo.
El sentido comn dice que si un problema es demasiado grande ha de partirse en
subproblemas, y as se hace en las capas de protocolos.
P
1
P
2
Nivel base
'
P
2
P
1
''
P
2
''
'
P
1
Nivel '
Nivel ''
Servicio y suposiciones sobre el entorno
Las ventajas de un sistema estraticado son:
Ayuda a determinar los protocolos separando tareas de nivel superior de los
detalles del nivel inferior.
Resulta ms fcil remplazar un mdulo que reescribir el protocolo en caso
de extensin o cambio.
Capas/Niveles el esquema ISO:
Fsico: transmisin de bits sobre circuito.
Enlace de datos: Deteccin de errores y recuperacin.
Red: Transferencia y rutado transparente de los datos.
Transporte: Transferencia de alto nivel entre procesos.
Sesin: Coordinacin de interacciones en sesiones.
Presentacin: Interpretacin de sintaxis de datos a nivel de proceso (ej:
encriptacin, compresin?)
Aplicacin: Punto de entrada para procesos de usuario nal.
Grado en Informtica - SD (2011) - Protocolos 5
1.4. Vocabulario y formato de mensajes de un protocolo
Ejemplo - Protocolo de Lynch (iii)
Vocabulario del protocolo
V = {ack, err, nak}
ack: un mensaje combinado con un reconocimiento positivo
nak: un mensaje combinado con un reconocimiento negativo.
err: un mensaje con un error de transmisin.
Ejemplo - Protocolo de Lynch (iv)
Formato de los mensajes
Cada mensaje consta de un cdigo de control que identica el tipo de mensaje
y un campo de datos con el cdigo del carcter. (suponemos que ambos son de
tamao jo.
<etiqueta de control (ack, err, nak) + datos>
Ejemplo en C
enum control { ack, nak, err };
struct message {
enum control etiqueta;
unsigned char datos;
};
Vocabulario y formato
Los mensajes respetan ciertas estructuras que codican el vocabulario del proto-
colo.
Los tres mtodos de formato usuales son:
Orientado a bit.
Orientado a caracteres.
Orientado a ujos de bytes.
Adems (sobre todo en ujos de bytes) estructuralmente pueden organizarse los
mensajes en bloques del tipo:
formato={header, data, trailer}
header = {type, destination, sequence number, count}
trailer = {checksum, return address}
Grado en Informtica - SD (2011) - Protocolos 6
Volcabulario y formato (ii)
Bit oriented.
01111110 011100011101110 01111110
bit stuffing
delimiter user data delimiter
Character oriented.
STX byte,byte,DLE,STX,byte... ETX
delimiter user data delimiter
escape char
Byte count oriented.
STX ETX
delimiter user data delimiter header trailer
... ... ...
type;dest;seqn;count
checksum;return-address
1.5. Reglas de procedimiento de un protocolo
Ejemplo - Protocolo de Lynch (v)
Reglas de procedimiento
1. Si la recepcin anterior no tena errores, el prximo mensaje en el canal contrario
llevar un reconocimiento positivo;
si la recepcin tuvo errores, llevar un reconocimiento negativo.
2. Si la recepcin previa llevaba un reconocimiento negativo, o la recepcin anterior
fue errnea, se retransmite el mensaje anterior;
de otro modo, se consigue otro mensaje para una nueva transmisin.
Grado en Informtica - SD (2011) - Protocolos 7
Lenguaje de descripcin de ujo
Este es un subconjunto del SDL (CCITT-1988)
Cada diagrama de ujo dene un proceso que se ejecuta, en principio, concur-
rentemente con el resto de procesos.
Cada diagrama tiene un punto de entrada etiquetado con un nombre de proceso
o start.
Los elementos grcos se conectan mediante arcos dirigidos que van de un ele-
mento a otro, o un conector:
Elementos del lenguaje de descripcin de ujo (i)
Sentencia
con asignaciones u operaciones varias.
Test
con expresiones booleanas para bifurcar el ujo del proceso.
Espera
donde se detiene el proceso hasta que se produce cierta entrada o condicin de
continuacin.
Interno
con eventos internos que permiten la continuacin del proceso, como timeouts y
temporizadores.
Entrada
indica que se ha producido cierta entrada.
Salida
emite un mensaje de salida desde el proceso.
Elementos del lenguaje de descripcin de ujo (i)
Las expresiones booleanas se evalan sin demora alguna, al contrario que las
condiciones de espera, sirven para modelar la sincronizacin de los procesos.
Los arcos de estos diagramas expresan la direccin del ujo de ejecucin, y slo
pueden converger en los conectores ;
Aunque pueden diverger en las esperas
Espera
y en los test
Test
.
Las salidas
Salida
, las sentencias
Sentencia
, los internos
Interno
, y los test
Test
,
pueden aparecer en cualquier lugar.
Las entradas
Entrada
slo pueden aparecer a continuacin de un smbolo de espera
recibe
recibe
.
Grado en Informtica - SD (2011) - Protocolos 8
Condicin de espera de recepcin
Una condicin de espera recibe demora la ejecucin hasta que la cola de men-
sajes implcita contiene en su primer parte un mensaje del tipo indicado en una de las
entradas que siguen al smbolo.
Si el mensaje es de otro tipo, es un error.
Si a la espera le sigue un timeout, se aborta dicha espera cuando expira dicho
timeout.
Las esperas internas tambin admiten expresiones booleanas. En este caso el
proceso se demora hasta que se cumple la expresin.
recibe
timeout ack
Condicin de espera de recepcin
Hay dos acciones internas para modelar el acceso a archivos: next (recupera) y
accept (almacena).
Example 1.
next: a, b
msg: a, b accept: a, b
msg: a, b
timeout
Ejemplo - Protocolo de Lynch (vi)
Diagrama de tipo de proceso
Grado en Informtica - SD (2011) - Protocolos 9
start
next: out
recibe
nak: inp ack: inp err: inp
next: out
ack: out ack: out nack: out
Estado bsico del sistema,
donde se espera la entrada.
Mensaje
reconocido
Mensaje
enviado
Accin
interna
1.6. Ejemplo de diagramas de tipo de proceso (ujo)
Ejemplo - Protocolo de Lynch (vii)
Diagrama de secuencia de tiempo
A B
err
nak 'z'
ack: 'a' ... err
nak: 'z' ... err
nak 'a'
ack 'z'
Enva letras
de la 'a' a la 'z'
Enva letras
de la 'z' a la 'a'
next: out
next: out
acepta 'z'
acepta 'a'
acepta 'z'
next: out
ack 'b'
sin distorsin
con distorsin
Ejemplo - Protocolo de Lynch (viii)
Carencias del diseo
Grado en Informtica - SD (2011) - Protocolos 10
El envo/recepcin debe ocurrir simultneamente.
El protocolo debe comenzar en puntos diferentes en cada uno de los dos proce-
sos, para que estn en fase.
Puede comenzarse con un mesaje err.
Se ha omitido: el receptor debe ser capaz de decidir si un dato recibido correcta-
mente (almacenado temporalmente en inp"), ha de ser almacenado.
El protocolo, en resumen, contiene escenarios errneos.
Ejemplo - Protocolo de bit alternante con timeouts
Diagramas de tipo de proceso (protocolo asimtrico)
start
next: o
msg: o,s
recibe
ack: r
r == s a == e
s 1s
timeout
start
accept: i
ack: a
recibe
msg:i,a
e 1e
true true
false false
1.7. Propiedades deseables en un protocolo
Propiedades de un buen protocolo
Simplicidad: El caso de los protocolos de peso ligero.
Modularidad: Una jerarqua de funciones.
Protocolo bien formado (aunque no sobre-especicado) (completo y slido).
Robustez frente a situaciones no consideradas.
Consistencia. Posibles fallos son:
Grado en Informtica - SD (2011) - Protocolos 11
Interbloqueos (no hay ejecuciones posibles).
Bloqueos vivos (sin progreso efectivo de los procesos).
Terminaciones inadecuadas (sin satisfacer los requisitos).
2. Los protocolos de Internet
Estandarizacin de protocolos de Internet
Central domain
database
root server
accredited
registrars
ISOC
Society
IAB
Architecture
Board
IETF
Engineering
Task Force
IRTF
Research
Task Force
ICANN
corporation
for assigned
names & numbers
CCNSO
Country code
names support
organization
IANA
assigned numbers
authority
GNSO
Generic
names Support
organization
2.1. Sociedades de Internet
Sociedades de Internet
Internet Society (ISOC-www.isoc.org): gua el futuro de Internet supervisando
los estndares, poltica pblica, educacin y entrenamiento. Lo forman corpora-
ciones, organizaciones gubernamentales internacionales e individuos.
Internet Corporation for Assigned Names and Numbers (ICANN-www.icann.org)
Internet Activities Board (IAB-www.iab.org): dene la arquitectura de Inter-
net, y supervisa los protocolos de Internet.
Internet Engineering Task Force (IETF-www.ietf.org): Con ms de 70 sub-
comits informales corre con el da a da de Internet.
Grado en Informtica - SD (2011) - Protocolos 12
Otras sociedades de estandarizacin
Institute of Electrical and Electronics Engineers (IEEE-eye-triple-e): dispone de
estndares hardware como los de LAN (802, con cable, wireless, . . . ).
World Wide Web Consortium (W3C-w-c-3): establece los estndares relaciona-
dos con la Web (html, SOAP, XML, . . . )
International Organization for Standarization (ISO-eye-so).
International Telecommunication Union (antiguamente CCITT), dependiente de
la ONU.
Free Software Foundation (FSF): proporciona herramientas gratuitas que muchas
veces derivan en estandarizaciones (GNU-guh-new).
2.2. RFC
Estndares de Internet
Los estndares de Internet estn bajo la forma de RFCs (request for comments-
www.ietf.org/rfc.html).
Las categoras de RFCs son muy diversas, las ms conocidas son:
Standard Track (STD): Estndar tcnico aprobado.
Draft standard: Camino de aprobacin.
Proposed standard: Camino de aprobacin como draft standard.
Best current practices (BCP): Guas y recomendaciones (ej: 4107 sobre gestin
de claves).
Experimental (EXP): Investigacin o desarrollo (ej.: 5335 sobre internacional-
izacin de cabeceras de correo).
Historic: RFCs obsoletos que se conservan como recuerdo.
Informational (FYI-for-your-information): tiles y tutoriales (ej.: 4677 el Tao
de IETF- una gua bla bla bla)
Tambin los hay de broma (ej.: 1149) (ver en la Wikipedia April Fools Day
RFC).
2.3. Ejemplo de RFC: El RFC 2821 (SMTP)
Ejemplo de RFC: SMTP
Cabecera
Grado en Informtica - SD (2011) - Protocolos 13
Network Working Group J. Klensin, Editor
Request for Comments: 2821 AT&T Laboratories
Obsoletes: 821, 974, 1869 April 2001
Updates: 1123
Category: Standards Track
Simple Mail Transfer Protocol
Status of this Memo
This document specifies an Internet standards track protocol
for the Internet community, and requests discussion and
suggestions for improvements. Please refer to the current
edition of the "Internet Official Protocol Standards" (STD
1) for the standardization state and status of this
protocol. Distribution of this memo is unlimited.
...
Ejemplo de RFC: SMTP (ii)
Cabecera (ii)
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract
This document is a self-contained specification of the basic
protocol for the Internet electronic mail transport. It
consolidates, updates and clarifies, but doesnt add new or
change existing functionality of the following:
- the original SMTP (Simple Mail Transfer Protocol)
specification of RFC 821 [30],
- domain name system requirements and implications for mail
transport from RFC 1035 [22] and RFC 974 [27],
- the clarifications and applicability statements in RFC 1123
[2], and
- ... bla bla bla hasta hasta el fin del abstract
Ejemplo de RFC: SMTP (iii)
Tabla de contenidos
Table of Contents
1. Introduction .................................................. 4
Grado en Informtica - SD (2011) - Protocolos 14
2. The SMTP Model ................................................ 5
2.1 Basic Structure .............................................. 5
2.2 The Extension Model ..(supera al RFC821)..................... 7
2.2.1 Background ................................................. 7
2.2.2 Definition and Registration of Extensions .................. 8
2.3 Terminology ..(denicin del vocabulario).................... 9
2.3.1 Mail Objects ............................................... 10
2.3.2 Senders and Receivers ...................................... 10
2.3.3 Mail Agents and Message Stores ............................. 10
2.3.4 Host ....................................................... 11
2.3.5 Domain ..................................................... 11
2.3.6 Buffer and State Table ..................................... 11
2.3.7 Lines ...................................................... 12
2.3.8 Originator, Delivery, Relay, and Gateway Systems ........... 12
2.3.9 Message Content and Mail Data .............................. 13
2.3.10 Mailbox and Address ....................................... 13
2.3.11 Reply ..................................................... 13
Ejemplo de RFC: SMTP (iv)
Estructura bsica
2.1 Basic Structure
The SMTP design can be pictured as:
+----------+ +----------+
+------+ | | | |
| User |<-->| | SMTP | |
+------+ | Client- |Commands/Replies| Server- |
+------+ | SMTP |<-------------->| SMTP | +------+
| File |<-->| | and Mail | |<-->| File |
|System| | | | | |System|
+------+ +----------+ +----------+ +------+
SMTP client SMTP server
When an SMTP client has a message to transmit, it establishes a two-
way transmission channel to an SMTP server. The responsibility of an
SMTP client is to transfer mail messages to one or more SMTP servers,
or report its failure to do so.
The means by which a mail message is presented to an SMTP client, and
Ejemplo de RFC: SMTP (v)
Modelo de Extensin
Grado en Informtica - SD (2011) - Protocolos 15
2.2 The Extension Model
2.2.1 Background
In an effort that started in 1990, approximately a decade after RFC
821 was completed, the protocol was modified with a "service
extensions" model that permits the client and server to agree to
utilize shared functionality beyond the original SMTP requirements.
The SMTP extension mechanism defines a means whereby an extended SMTP
client and server may recognize each other, and the server can inform
the client as to the service extensions that it supports.
Contemporary SMTP implementations MUST support the basic extension
mechanisms. For instance, servers MUST support the EHLO command even
if they do not implement any specific extensions and clients SHOULD
preferentially utilize EHLO rather than HELO. (However, for
compatibility with older conforming implementations, SMTP clients and
servers MUST support the original HELO mechanisms as a fallback.)
Unless the different characteristics of HELO must be identified for
interoperability purposes, this document discusses only EHLO... ...
Ejemplo de RFC: SMTP (vi)
Tabla de contenidos (ii)
2.4 General Syntax Principles and Transaction Model .............. 13
3. The SMTP Procedures: An Overview .(desc. precisa pero informal) 15
3.1 Session Initiation ........................................... 15
3.2 Client Initiation ............................................ 16
3.3 Mail Transactions ............................................ 16
3.4 Forwarding for Address Correction or Updating ................ 19
3.5 Commands for Debugging Addresses ............................. 20
3.5.1 Overview ................................................... 20
3.5.2 VRFY Normal Response ....................................... 22
3.5.3 Meaning of VRFY or EXPN Success Response ................... 22
3.5.4 Semantics and Applications of EXPN ......................... 23
3.6 Domains ...................................................... 23
3.7 Relaying ..................................................... 24
3.8 Mail Gatewaying .............................................. 25
3.8.1 Header Fields in Gatewaying ................................ 26
3.8.2 Received Lines in Gatewaying ............................... 26
3.8.3 Addresses in Gatewaying .................................... 26
3.8.4 Other Header Fields in Gatewaying .......................... 27
3.8.5 Envelopes in Gatewaying .................................... 27
3.9 Terminating Sessions and Connections ......................... 27
Grado en Informtica - SD (2011) - Protocolos 16
Ejemplo de RFC: SMTP (vii)
Terminologa
2.3 Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described below.
(Esto aparece en casi todos los RFCs)
1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that
the definition is an absolute requirement of the specification.
2. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the
definition is an absolute prohibition of the specification.
3. SHOULD This word, or the adjective "RECOMMENDED", mean that
there may exist valid reasons in particular circumstances to
ignore a particular item, but the full implications must be
understood and carefully weighed before choosing a different
course.
...
Ejemplo de RFC: SMTP (viii)
Terminologa (ii)
2.3.2 Senders and Receivers
In RFC 821, the two hosts participating in an SMTP transaction were
described as the "SMTP-sender" and "SMTP-receiver". This document
has been changed to reflect current industry terminology and hence
refers to them as the "SMTP client" (or sometimes just "the client")
and "SMTP server" (or just "the server"), respectively. Since a
given host may act both as server and client in a relay situation,
"receiver" and "sender" terminology is still used where needed for
clarity.
2.3.3 Mail Agents and Message Stores
Cambio terminolgico de cliente-servidor a MTA
(mail transfer agent) y MUA (mail user agent).
Additional mail system terminology became common after RFC 821 was
published and, where convenient, is used in this specification. In
particular, SMTP servers and clients provide a mail transport service
and therefore act as "Mail Transfer Agents" (MTAs). "Mail User
Grado en Informtica - SD (2011) - Protocolos 17
...
Ejemplo de RFC: SMTP (xix)
Tabla de contenidos (iii)
3.10 Mailing Lists and Aliases ................................... 28
3.10.1 Alias ..................................................... 28
3.10.2 List ...................................................... 28
4. The SMTP Specications ..(primitivas del protocolo sint/sem).. 29
4.1 SMTP Commands ................................................ 29
4.1.1 Command Semantics and Syntax ............................... 29
4.1.1.1 Extended HELLO (EHLO) or HELLO (HELO) .................... 29
4.1.1.2 MAIL (MAIL) .............................................. 31
4.1.1.3 RECIPIENT (RCPT) ......................................... 31
4.1.1.4 DATA (DATA) .............................................. 33
4.1.1.5 RESET (RSET) ............................................. 34
4.1.1.6 VERIFY (VRFY) ............................................ 35
4.1.1.7 EXPAND (EXPN) ............................................ 35
4.1.1.8 HELP (HELP) .............................................. 35
4.1.1.9 NOOP (NOOP) .............................................. 35
4.1.1.10 QUIT (QUIT) ............................................. 36
4.1.2 Command Argument Syntax .................................... 36
4.1.3 Address Literals ........................................... 38
4.1.4 Order of Commands .......................................... 39
Ejemplo de RFC: SMTP (xx)
Formato de los mensajes
4. The SMTP Specifications
4.1 SMTP Commands
4.1.1 Command Semantics and Syntax
The SMTP commands define the mail transfer or the mail system
function requested by the user. SMTP commands are character strings
terminated by <CRLF>. The commands themselves are alphabetic
characters terminated by <SP> if parameters follow and <CRLF>
otherwise. (In the interest of improved interoperability, SMTP
receivers are encouraged to tolerate trailing white space before the
terminating <CRLF>.) The syntax of the local part of a mailbox must
conform to receiver site conventions and the syntax specified in
section 4.1.2. The SMTP commands are discussed below. The SMTP
replies are discussed in section 4.2.
Grado en Informtica - SD (2011) - Protocolos 18
A mail transaction involves several data objects which are
communicated as arguments to different commands...
Ejemplo de RFC: SMTP (xxi)
Formato de los mensajes (ii)
These commands, and a "250 OK" reply to one of them, confirm that
both the SMTP client and the SMTP server are in the initial state,
that is, there is no transaction in progress and all state tables and
buffers are cleared.
Syntax:
ehlo = "EHLO" SP Domain CRLF
helo = "HELO" SP Domain CRLF
Normally, the response to EHLO will be a multiline reply. Each line
of the response contains a keyword and, optionally, one or more
parameters. Following the normal syntax for multiline replies, these
keyworks follow the code (250) and a hyphen for all but the last
line, and the code and a space for the last line. The syntax for a
positive response, using the ABNF notation and terminal symbols of
[8], is:
ehlo-ok-rsp = ( "250" domain [ SP ehlo-greet ] CRLF )
/ ( "250-" domain [ SP ehlo-greet ] CRLF
*
( "250-" ehlo-line CRLF )
"250" SP ehlo-line CRLF )
Ejemplo de RFC: SMTP (xxii)
Primitivas devueltas por el servidor
4.2.2 Reply Codes by Function Groups
500 Syntax error, command unrecognized
(This may include errors such as command line too long)
501 Syntax error in parameters or arguments
502 Command not implemented (see section 4.2.4)
503 Bad sequence of commands
504 Command parameter not implemented
211 System status, or system help reply
214 Help message
(Information on how to use the receiver or the meaning of a
particular non-standard command; this reply is useful only
to the human user)
220 <domain> Service ready
221 <domain> Service closing transmission channel
Grado en Informtica - SD (2011) - Protocolos 19
421 <domain> Service not available, closing transmission channel
(This may be a reply to any command if the service knows it
must shut down)
Ejemplo de RFC: SMTP (xxiii)
Tabla de contenidos (iv)
4.1.5 Private-use Commands ....................................... 40
4.2 SMTP Replies ................................................ 40
4.2.1 Reply Code Severities and Theory ........................... 42
4.2.2 Reply Codes by Function Groups ............................. 44
4.2.3 Reply Codes in Numeric Order .............................. 45
4.2.4 Reply Code 502 ............................................. 46
4.2.5 Reply Codes After DATA and the Subsequent <CRLF>.<CRLF> .... 46
4.3 Sequencing of Commands and Replies ........................... 47
4.3.1 Sequencing Overview ..(secuenciacin de las primitivas)..... 47
4.3.2 Command-Reply Sequences .................................... 48
4.4 Trace Information ............................................ 49
4.5 Additional Implementation Issues ............................. 53
4.5.1 Minimum Implementation ..................................... 53
4.5.2 Transparency ............................................... 53
4.5.3 Sizes and Timeouts ......................................... 54
4.5.3.1 Size limits and minimums ................................. 54
4.5.3.2 Timeouts ................................................. 56
4.5.4 Retry Strategies ........................................... 57
4.5.4.1 Sending Strategy ......................................... 58
4.5.4.2 Receiving Strategy ....................................... 59
Ejemplo de RFC: SMTP (xxiv)
Ejemplo de secuenciacin
Specific sequences are:
CONNECTION ESTABLISHMENT
S: 220
E: 554
EHLO or HELO
S: 250
E: 504, 550
MAIL
S: 250
E: 552, 451, 452, 550, 553, 503
RCPT
S: 250, 251 (but see section 3.4 for discussion of 251 and 551)
E: 550, 551, 552, 553, 450, 451, 452, 503, 550
DATA
I: 354 -> data -> S: 250
E: 552, 554, 451, 452
Grado en Informtica - SD (2011) - Protocolos 20
E: 451, 554, 503
...
Ejemplo de RFC: SMTP (xxv)
Semntica de errores
Based on extensive experience with busy mail-relay hosts, the minimum
per-command timeout values SHOULD be as follows:
Initial 220 Message: 5 minutes
An SMTP client process needs to distinguish between a failed TCP
connection and a delay in receiving the initial 220 greeting
message. Many SMTP servers accept a TCP connection but delay
delivery of the 220 message until their system load permits more
mail to be processed.
MAIL Command: 5 minutes
RCPT Command: 5 minutes
A longer timeout is required if processing of mailing lists and
aliases is not deferred until after the message was accepted.
DATA Initiation: 2 minutes
This is while awaiting the "354 Start Input" reply to a DATA
command.
Ejemplo de RFC: SMTP (xxvi)
Tabla de contenidos (v)
4.5.5 Messages with a null reverse-path .......................... 59
5. Address Resolution and Mail Handling .......................... 60
6. Problem Detection and Handling ..(casi obligatorio)............ 62
6.1 Reliable Delivery and Replies by Email ....................... 62
6.2 Loop Detection ............................................... 63
6.3 Compensating for Irregularities .............................. 63
7. Security Considerations ..(casi obligatorio)................... 64
7.1 Mail Security and Spoofing ................................... 64
7.2 "Blind" Copies ............................................... 65
7.3 VRFY, EXPN, and Security ..................................... 65
7.4 Information Disclosure in Announcements ...................... 66
7.5 Information Disclosure in Trace Fields ....................... 66
7.6 Information Disclosure in Message Forwarding ................. 67
7.7 Scope of Operation of SMTP Servers ........................... 67
8. IANA Considerations ..(casi obligatorio)....................... 67
9. References ..(casi obligatorio)................................ 68
10. Editors Address ..(casi obligatorio)......................... 70
11. Acknowledgments ..(casi obligatorio).......................... 70
Grado en Informtica - SD (2011) - Protocolos 21
Ejemplo de RFC: SMTP (xxvii)
Tabla de contenidos (vi)
Appendices ....................................................... 71
A. TCP Transport Service ......................................... 71
B. Generating SMTP Commands from RFC 822 Headers ................. 71
C. Source Routes ..(ejemplos y material complementario)............ 72
D. Scenarios ..................................................... 73
E. Other Gateway Issues .......................................... 76
F. Deprecated Features of RFC 821 ..(casi obligatorio)............ 76
Full Copyright Statement ..(casi obligatorio)..................... 79
Ejemplo de RFC: SMTP (xxviii)
Detalles de los apndices
APPENDICES
A. TCP Transport Service
The TCP connection supports the transmission of 8-bit bytes. The
SMTP data is 7-bit ASCII characters. Each character is transmitted
as an 8-bit byte with the high-order bit cleared to zero. Service
extensions may modify this rule to permit transmission of full 8-bit
data bytes as part of the message body, but not in SMTP commands or
responses.
B. Generating SMTP Commands from RFC 822 Headers
Some systems use RFC 822 headers (only) in a mail submission
protocol, or otherwise generate SMTP commands from RFC 822 headers
when such a message is handed to an MTA from a UA. While the MTA-UA
protocol is a private matter, not covered by any Internet Standard,
Ejemplo de RFC: SMTP (xxix)
Detalles de los apndices
D.1 A Typical SMTP Transaction Scenario
This SMTP example shows mail sent by Smith at host bar.com, to Jones,
Green, and Brown at host foo.com. Here we assume that host bar.com
contacts host foo.com directly. The mail is accepted for Jones and
Brown. Green does not have a mailbox at host foo.com.
S: 220 foo.com Simple Mail Transfer Service Ready
C: EHLO bar.com
S: 250-foo.com greets bar.com
S: 250-8BITMIME
S: 250-SIZE
S: 250-DSN
Grado en Informtica - SD (2011) - Protocolos 22
S: 250 HELP
C: MAIL FROM:<Smith@bar.com>
S: 250 OK
C: RCPT TO:<Jones@foo.com>
S: 250 OK
C: RCPT TO:<Green@foo.com>
S: 550 No such user here
C: RCPT TO:<Brown@foo.com>
3. Resumen de la unidad
Resumen (i)
Los protocolos son necesarios para comuniciar procesos.
Son normativos.
Son de la misma naturaleza que los algoritmos distribuidos.
En ellos interviene la denicin de un lenguaje denido tanto en su sintaxis
como en su semntica.
Denimos un protocolo mediante:
Servicio.
Supuestos.
Vocabulario.
Formatos de los mensajes.
Reglas de procedimiento.
Resumen (ii)
El diseo de un protocolo real es complejo:
Tiene su ciclo de vida, como el software, pasa por la denicin de:
Vocabulario
Formato
Reglas de procedimiento
Para ello es recomendable utilizar notacin estructurada y formal, cuando
es posible.
La vericacin del protocolo juega un papel importante.
Grado en Informtica - SD (2011) - Protocolos 23
Resumen (iii)
Al especicar el servicio proporcionamos un modelo de funcionamiento.
Al concretar los supuestos del entorno, indicamos cuales son las restricciones
sobre las que constrimos el sistema.
El vocabulario del protocolo consta de primitivas y mensajes devueltos.
El formato de los mensajes debe expresarse mediante notacin formal (BNF?).
Resumen (iv)
Para describir las reglas de procedimiento es comn emplear:
diagramas de secuencia;
diagramas de estado, y sus derivados como los
diagramas de control de ujo.
Las propiedades deseables de un protocolo son:
Simplicidad.
Modularidad.
Buena formacin.
Robustez.
Consistencia.
Resumen (v)
En Internet existen diversas organizaciones que llevan la cuenta de su funcionamien-
to, extensin y estandarizacin.
ISOC-Internet Society { IAB- Internet Architecture Board { IETF- Internet
Engineering Task Force, IRTF - Internet Research Task Force}}
ICANN- Internet Corporation for Assigned Names & Numbers { IANA
- Internet Assigned Numbers Authority, CCNSO - Country Code Names
Support Organization, GNSO- Generic Names Support Organization { Cen-
tral Domain Database Root Server, Accredited Registrars}}
Resumen (vi)
Para estandarizar Internet se recurre a la emisin de documentos llamados RFC
(Request-for-comments)
Siguen una pista de estandarizacin. (Proposed Draft standard).
Los rfc estn normalizados,
Tienen una estructura estndar, y ciertas secciones normativas.
Existen RFC de muy diversa ndole.