tema iii: protocolos basados en paso de mensajes luis lópez fernández

Tema III:Protocolos basados en

paso de mensajes

Luis López Fernández

Tema III: Protocolos basados en pasode mensajes

Tema III: ContenidosTema III: Contenidos

3.1: Introducción

3.2: Especificación de los aspectos sintácticos de un protocolo

3.3: Especificación de los aspectos semánticos de un protocolo

3.4: Especificación del secuenciamiento de mensajes


Lección 3.1: IntroducciónLección 3.1: Introducción

3.1: Introducción




Aplicaciones y protocolos de nivel de aplicaciónAplicaciones y protocolos de nivel de aplicación

TCP/IPSistema operativo

Hardware

sockets

Protocolo de nivel de aplicación

Lógica dela aplicación

Presentaciónde la aplicación

•El desarrollo de una aplicación distribuida comprende•El uso de los servicios de red proporcionados por el sistema•La concepción e implementación de un protocolo de nivel de aplicación•La implementación de la lógica de la aplicación•La implementación de un mecanismo de presentación para hacerla usable


Lo proporciona el sistema

Tarea del desarrollador

Asignaturas de creación de GUIs

Asignaturas de programación

Esta asignatura

Asignaturas de redes

Protocolos de nivel de aplicaciónProtocolos de nivel de aplicación•La implementación de un protocolo de nivel de aplicación se basa

•En los servicios (paso de mensajes) que prestan capas inferiores

•En nuestro caso (y la mayoría del resto), en la API de sockets

•La implementación de un protocolo de nivel de aplicación requiere

•Especificar el protocolo de manera rigurosa (estandarizarlo)

•Implementarlo respetando su especificación

•La especificación del protocolo debe definir sin ambigüedad

•Los aspectos sintácticos

•Qué tipos de mensajes existen

•Qué formato tienen los mensajes

•Cómo se codifican de los mensajes

•Los aspectos semánticos

•Qué se debe hacer con cada mensaje

•El secuenciamiento de mensajes

•Cuál es la secuencia de intercambio de mensajes



Lección 3.2: Aspectos sintácticosLección 3.2: Aspectos sintácticos

3.1: Introducción




Especificación de protocolos: aspectos sintácticosEspecificación de protocolos: aspectos sintácticos

•Aspectos sintácticos = forma de los mensajes (continente más que contenido)

•Los aspectos sintácticos tienen que ver con

•Qué tipos de mensajes hay

•Cuál es su formato: hay que responder a preguntas como

•Cuantos campos tienen?

•Qué campo es un entero?

•Qué campo es un flotante?

•Qué campo es una cadena de caracteres?

•Cómo se codifican los mensajes: hay que responder a preguntas como

•Los enteros son de 4 o de 8 bits?

•Los bytes se ordenan con un esquema little-endian o big-endian?

•Utilizamos ascii, iso-8859-1 o UTF-8 para codificar caracteres?


Especificación de mensajes y su codificaciónEspecificación de mensajes y su codificación

•Especificación de los mensajes y de su formato•Consiste en definir qué mensajes necesitamos en el protocolo y qué contienen esos mensajes, ambas labores están muy relacionadas•Esta labor la realiza un ingeniero que comprenda los objetivos del protocolo

•Especificación de los mecanismos de codificación•Consiste en especificar cómo se representan los mensajes en binario•Hay que tener en cuenta que las redes de ordenadores son heterogéneas

•Diferente hardware•Diferentes sistemas operativos•Diferentes lenguajes de programación•Diferentes idiomas y caracteres

•Podemos definir nuestros propios formatos de representación y los mecanismos de conversión apropiados para cada sistema•Esta es una labor muy tediosa y propensa a errores•Es una problemática que existe en todos los protocolos•Se han estandarizado mecanismos para facilitar la tarea de codificación



Los mensajes desde diferentes puntos de vistaLos mensajes desde diferentes puntos de vista

•Desde el punto de vista de la red, el mensaje es una secuencia de bits•Desde el punto de vista del programador, es conveniente que el mensaje se represente como estructura de datos sobre el lenguaje informático correspondiente•Ejemplo: Aplicación de calculadora distribuida

OperandoI (int4)

OperandoD (int4)

Operación (ascii)

class Peticion {

public int operandoI;

public int operandoD;

public char operacion;

}

struct peticion{

int operando_i;

int operando_d;

char operacion;

};

Formato conceptual del mensaje

Posible representación Java Posible representación C

Java(int 4 bytes), C(int4 u 8 bytes)

Java(char 2 bytes), C(char1 byte)

…

Peticion p = new Peticion(1,2,‘+’);

enviar(p);

…

…

struct peticion p;

recibir(&p);

…

Programa Java que implementa el cliente Programa C que implementa el servidor

Qué hacen estos métodos?

•Definición de aplanamiento“proceso por el que una estructura de datos se transforma en una secuencia de bits siguiendo un conjunto de reglas de codificación predefinido”•Definición de desaplanamiento“proceso por el que una secuencia de bits se transforma en una estructura de datos siguiendo un conjunto de reglas de decodificación predefinido”

•Traducción de aplanamiento al inglés: marshalling•Traducción de desaplanamiento al inglés: unmarshalling

•Cuando desarrollamos aplicaciones distribuidas•Los mensajes se representan como estructuras de datos en el programa•El emisor aplana el mensaje antes de enviarlo por el socket•El receptor recibe los bytes por su socket y los desaplana•Para que el esquema funcione

•El emisor debe aplicar un conjunto de reglas de codificación para aplanar•El receptor debe aplicar el conjunto de reglas de decodificación inverso


Aplanamiento y desaplanamientoAplanamiento y desaplanamiento

Aplanamiento y desaplanamientoAplanamiento y desaplanamiento


…

Peticion p = new Peticion(1,2,‘+’);

enviar(p);

…

…

struct peticion p;

recibir(&p);

…

Programa Java que implementa el cliente Programa C que implementa el servidor

Qué hacen estos métodos?

void enviar(Peticion p){

byte[] binMsg = aplanar(p);

DataOutputStream dos = new DataOutputStream(socket.getOutputStream());

dos.write(binMsg, o, binMsg.length);

}

...

byte[] aplanar(Peticion p){

ByteArrayOutputStream baos =

new ByteArrayOutputStream();

DataOutputStream dos =

new DataOutputStream(baos);

//Java escribe en big-endian

dos.writeInt(p.operandoI);

dos.writeInt(p.operandoD);

String op = String.valueOf(p.operando);

dos.write(op.getBytes(“US-ASCII”,0,1);

return baos.toByteArray();

}

?

Reglas de aplanamiento:Codificación directa sin separadoresPaquetes de 9 bytes

Secuencia de campos- operandoI va en primer lugar- operandoD va en segundo lugar- operación va en tercer lugar

Reglas de codificiación-Los enteros se codifican con 4 bytescon es quema big-endian -Los caracteres se codifican con un byteen formato ascii

00 00 00 01 00 00 00 02 2B

Aplanamiento/desaplanamiento en el mundo realAplanamiento/desaplanamiento en el mundo real

En sistemas cerrados y controlados, se puede asumir homogeneidad•Ejemplo:

•Se desarrolla una aplicación cliente servidor que solo usa una empresa•Todos los clientes y todos los servidores están escritos en Java•Podemos usar la serialización de Java para aplanar/desaplanar

En sistemas abiertos, no se puede asumir homogeneidad•Puedo inventarme mi propio estándar y esperar que todos lo adopten

•Ejemplo: TCP/IP introduce su propio estándar de codificación•El formato del paquete define, al mismo tiempo, los campos y cómo éstos de codifican en bits (esencialmente tamaños de enteros con orden big-endian)

•Puedo utilizar estándares preexistentes que todo el mundo acepta y conoce•Estándares generales no asociados a ninguna tecnología:

•ASN.1, XDR, Formatos basados en representación textual, XML, etc.•Estándares diseñados para una tecnología o problemática concreta

•El propio mecanismo de serialización de Java•Los mecanismos de aplanamiento de CORBA


Abstract Syntax Notation OneAbstract Syntax Notation One

•ASN.1: Abstract Syntax Notation One•Es al mismo tiempo

•Una notación para especificar estructuras de datos (mensajes)•Un conjunto de reglas para la codificación de las citadas estructuras

•Las reglas de codificación/decodificación son no ambiguas e independientes de•Plataformas hardware, sistemas operativos, lenguajes de programación, etc.

•ASN.1 Fue creado de manera conjunta por el ISO y la ITU-T•Existen varias versiones de ASN.1 con pequeñas modificaciones:

•ASN1:1994, ASN.1:1997 y ASN.1:2002•ASN.1 es muy utilizado en el mundo de las telecomunicaciones

•Protocolo LDAP y servicio de directorio X.500 lo utilizan•Estándar de certificados digitales X.509 lo utiliza•El protocolo SSL lo utiliza•El mecanimso S/MIME de correo electrónico lo utiliza•El protocolo SET lo utiliza•Los sistemas 3G (UMTS) hacen uso extensivo de ASN.1•Múltiples sistemas industriales y aeronáuticos lo utilizan•H.323 lo utiliza (videoconferencia, etc.)•Etc.


Abstract Syntax Notation One Cont.Abstract Syntax Notation One Cont.

•ASN.1: Notación abstracta•ITU-T Recs. X.680, X681, X682 y X683•Se define una notación abstracta para representar estructuras de datos•Hay tipos de datos básicos predefinidos (INTEGER, BIT STRING, etc.)•Hay mecanismos para crear estructuras complejas•La representación de los mensajes se escribe en un fichero de texto usando esta notación•Ejemplo: Nuestra aplicación de calculadora


CalcProtocol DEFINITIONS ::= BEGIN

CalcPetition ::= SEQUENCE {

operandoI INTEGER,

operandoD INTEGER,

operación IA5String (SIZE(1))

}

CaclRespuesta ::= SEQUENCE {

resultado INTEGER,

codigo INTEGER,

descripcion IA5String

}

END


•ASN.1: Reglas de codificación•ITU-T Recs. X.690, X691, X693 y X694•Definen reglas de aplanamiento/desaplanamiento de los mensajes•Existen diferentes familias de reglas con diferentes característicasBasic Encoding Rules (BER)

oCada elemento de datos se codifica especificando tres parametros: un identificador, la longitud de los datos y los propios datosoEl decodificador va recuperando los datos “sobre la marcha” al recibirlosoSe usa en: SNMP, sistemas telefónicos, LDAP, etc.

Canonical Encoding Rules (CER)oEs un subconjunto de BER que restringe las opciones de codificación

Distinghished Encoding Rules (DER)oEs un subconjunto de VER muy usado en criptografía

XML Encoding Rules (XER)oLa codificación se produce usando XML (codificación textual)

Packet Encoding Rules (PER)oVariante de BER más compacta que permite mayor eficienciaoRequire que el decodificador conozca la estructura ASN.1 a priori

Generic String Decoding Rules (GSER – RFC 3641)oRepresenta los datos en formato legible por humanos (en desuso)



•ASN.1 en la práctica:•Se diseñan los mensajes usando la notación abstracta•Se elige el lenguaje informático que vamos a utilizar para el desarrollo•Se utiliza una herramienta que “compile” ASN.1 a ese lenguaje•Esta herramienta

•Genera estructuras de datos “usables” por el programador•Genera el código que realiza el aplanamiento•Genera el código que realiza el desaplanamiento

•Ejemplos de herramientas•asn1c: Compila de ASN.1 a c, c++, c# y Java (http://lionet.info/asn1c/)•pyasn1: Compila de ASN.1 a Python (http://pyasn1.sourceforge.net/)


eXternal Data Representation (XDR)eXternal Data Representation (XDR)

•Es un estándar del IETF definido en la RFC 1832•Fue concebido como base del “nivel de presentación” en Internet•No tuvo mucho éxito. Se usa, pero de manera muy restringida•La idea básica es similar a la de ASN.1

•Proporcionar un mecanismo para definir estructuras de datos•Proporcionar reglas de codificación de los datos

•Es mucho menos flexible que ASN.1, a cambio, es más sencillo de aprender•Veamos un ejemplo de definición tomado directamente del estándar


An XDR signed integer is a 32-bit datum that encodes an integer in

the range [-2147483648,2147483647]. The integer is represented in

two's complement notation. The most and least significant bytes are

0 and 3, respectively. Integers are declared as follows:

int identifier;

(MSB) (LSB)

+-------+-------+-------+-------+

|byte 0 |byte 1 |byte 2 |byte 3 | INTEGER

+-------+-------+-------+-------+

<------------32 bits------------>

Formatos basados en representación textualFormatos basados en representación textual

•Los ordenadores “entienden” de bits•Los humanos tenemos dificultades para interpretar las secuencias de bits•Los humanos tenemos facilidad para interpretar texto (secuencias de caracteres)•¿Por qué no representamos los mensajes como secuencias de caracteres?•Ejemplo:

•El número entero 33 como entero de 4 bytes en formato big-endian estilo XDR00000000 00000000 00000000 00100001El número entero 33 representado como la cadena de caracteres “33” en ascii00110011 00110011 (el código ascii del carácter ‘3’ es el 51)

•Ventajas:•Soluciona rápidamente el problema del aplanamiento/desaplanamiento

•Los mensajes son secuencias de texto que se transmiten siguiendo la secuencia de lectura “occidental” (de izquierda a derecha, de arriba abajo)•El aplanamiento/desaplanamiento queda resuelto en cuanto se elija el formato de codificación de caracteres que se desea usar

•Simplifica la especificación de los protocolos (tarea humana)•Simplifica el desarrollo y depuración de protocolos (tarea humana)

•Inconvenientes•Puede ser mucho menos eficiente en tiempo y en espacio de codificación


Formatos basados en representación textual Cont.Formatos basados en representación textual Cont.

•En la práctica, parece que las ventajas han pesado más que los inconvenientes, porque los protocolos de aplicación más importantes de Internet lo utilizan•Ejemplos: HTTP, FTP, SMTP, etc.•Usando este esquema, basta con definir el formato textual y el charset a utilizar•El formato textual se suele definir mediante la notación ABNF•Notación ABNF: Augmented Backus-Naur Form•Es una notación para la definición de gramáticas•Está estandarizada en la RFC 4234•Permite definir símbolos y reglas de derivación•Todos los estándares de protocolos del IETF (RFCs) basados en texto la usan•Ejemplo: Algunas reglas ABNF de HTTP 1.0 (RFC 1945)


Full-Request= Request-Line

*( General-Header ; * = Cero o más veces

| Request-Header

| Entity-Header ) ; () grupo al que aplica *

CRLF

[ Entity-Body ] ; [] = elemento opcional

Request-Line = Method SP Request-URI SP HTTP-Version CRLF

Method = “GET”|”HEAD|”POST” ; | = Alternativas, elegir una

Formatos basados en XMLFormatos basados en XML

•Formatos basados en representación textual•Gustan mucho a los desarrolladores y a la industria•La notación ABNF es tediosa si los datos son complejos•Es tedioso hacer el software que genera y recupera los datos (parser)

•Estaría bien definir un mecanismo de representación de datos•Potente y que permita definir estructuras de datos complejas•Que tenga una notación intuitiva para los seres humanos•Que tenga un parser universal

•El XML (Extensive Markup Language) •Nace con la vocación de ser este mecanismo•El XML es una recomendación del W3C (es decir, está defino por la gente que controla los estándares del WWW)•XML permite definir lenguajes de marcas específicos•Un lenguaje de marcas permite combinar texto y etiquetas

•El texto representa la información•Las etiquetas representan meta-información (estructura, representación...)

•XML proporciona un mecanismo para representar estructuras de datos en forma de árbol como un documento de texto•Ejemplo de lenguaje de marcas que puede ser generado: XHTML


Fundamentos de XMLFundamentos de XML•La unidad básica de un documento XML es el elemento•Un elemento consiste en

•Una etiqueta de comienzo•Un contenido•Una etiqueta de finalización

•La etiqueta de comienzo es un nombre contenido entre los símbolos ‘<‘ y ‘>’•La etiqueta de finalización es el mismo nombre rodeado por los símbolos ‘</’ y ‘>’•El contenido puede ser texto, uno o varios elementos, o la combinación de ambos•El contenido se encuentra delimitado por las etiquetas de comienzo y fin•El nombre del elemento no puede contener determinados caracteres incluyendo:

•‘<‘, ‘>’, ‘’’, ‘”’, ‘ ‘, ‘&’, etc.•Ejemplo de elemento XML•Existen caracteres especiales que deben ser “escapados” del texto

‘<‘→ < ‘>’→> ‘&’→& ‘’’→' ‘”’→"Ejemplos:

<alumno> Juan Nadie </alumno><inecuación> x &lt y + 4</inecuación><libro>

<autor>Mariano Sánchez</autor> <precio>32 Euros </precio>

</libro>


Fundamentos de XML Cont.Fundamentos de XML Cont.•Un elemento puede también tener atributos•El atributo es un par nombre-valor

•El nombre del atributo debe respectar las restricciones que hemos visto antes•El nombre del atributo y el valor se separan mediante el carácter ‘=‘•El valor del atributo debe presentarse entre comillas (dobles o simples)•El par nombre-valor está contendio entre el nombre del elemento y ‘>’•En un elemento dos atributos no pueden compartir el mismo nombre

•Cuando un elemento no tiene contenido puede representarse sin la etiqueta de finalización, pero haciendo que la etiqueta de comienzo esté comprendida entre los símbolos ‘<‘ y ‘/>’•Se pueden añadir comentarios entre los símbolos ‘’

Ejemplos:<alumno nombre=“Juan nadie”/><libro precio=“32” moneda=“EUR”>

<autor nacionalidad=“ES”>Mariano Sánchez</autor> <descripción>va de un alumno al que no le gustaba

estudiar </descripción><!– habría que mejorar la descripción -->

</libro>

Fundamentos de XML Cont.Fundamentos de XML Cont.•Un documento XML está compuesto por

•Una línea inicial opcional•Un elemento raíz (ni más ni menos)

•La línea inicial se denomina declaración XML y contiene•La versión de XML que se está utilizando (1.0 o 1.1)•La codificación de caracteres que se está utilizando en el documento

•Ejemplo de documento XML


<?xml version="1.0" encoding="UTF-8"?>

<recipe name="bread" prep_time="5 mins" cook_time="3 hours">

<title>Basic bread</title>

<ingredient amount="3" unit="cups">Flour</ingredient>

<ingredient amount="0.25" unit="ounce">Yeast</ingredient>

<ingredient amount="1.5" unit="cups" state="warm">Water</ingredient>

<ingredient amount="1" unit="teaspoon">Salt</ingredient>

<instructions>

<step>Mix all ingredients together, and knead thoroughly.</step>

<step>Cover with a cloth, and leave for one hour in warm room.</step>

<step>Knead again, place in a tin, and then bake in the oven.</step>

</instructions>

</recipe>

Documentos XML CorrectosDocumentos XML Correctos

•Un documento XML se dice que es correcto cuando•Está bien formado•Es válido

•Un documento está bien formado cuando•Respeta todas las reglas sintácticas del XML entre otras:

•Tiene un solo elemento raíz•Todo elemento no vacío que tiene etiqueta de comienzo tiene otra de fin•Las etiquetas pueden anidarse, pero no superponerse

•Por ejemplo, un documento con este elemento no estará bien formado<padre> <hijo> </padre> <hijo>Los documentos no bien formados no pueden analizarse con un parser

Un documento será válido cuando •Sea conforme a un conjunto de reglas definidas para el documento•Estas reglas especifican qué contenidos tienen los elementos y atributos•Estas reglas se especifican con lenguajes especiales•Por ejemplo si el atributo edad del elemento persona debe ser un entero, el siguiente elemento no sería válido<persona edad=“doce”/>


DTD y XML SchemaDTD y XML Schema

•DTD: Document Type Definition•Es un mecanismo para especificar las reglas de validez de un documento•Existe desde los orígenes de XML•Es relativamente sencillo de utilizar•No es muy potente•Utiliza una semántica no-XML, derivada del SGML

•XML Schema•Es un mecanismo más novedoso para especificar las reglas de validez•Es mucho más potente que DTD•Dispone un sistema de tipado muy completo•Se basa en una sintaxis XML•Es bastante difícil de entender y de utilizar


<xs:schema

xmlns:xs="http://www.w3.org/2001/XMLSchema">

<xs:element name="country" type="Country"/>

<xs:complexType name="Country">

<xs:sequence>

<xs:element name="name" type="xs:string"/>

<xs:element name="population" type="xs:decimal"/>

</xs:sequence>

</xs:complexType>

</xs:schema>

Ejemplo de esquema XMLusando XML Schema

Procesando documentos XMLProcesando documentos XML

•Una de las grandes ventajas de XML es que existen multitud de procesadores (parsers) eficientes que pueden ser usados en cualquier documento bien formado

•SAX: Simple Access to XML•Trata el documento XML como un stream de caracteres que se van analizando•Consume pocos recursos de memoria•Se basa en un modelo de programación orientado a eventos•A medida que se va procesando el documento se realizan llamadas de callback sobre un objeto manejador. En esas llamadas el programador puede añadir su código de proceso u obtención de datos

•DOM: Document Object Model•Es una API orientada a objetos para el procesamiento de documentos XML•Analiza el documento completo y crea una estructura de datos en memoria que lo representa: el árbol DOM•Una vez que el árbol DOM ha sido creado, se puede navegar por él y obtener las partes de información que sean relevantes•Puede llegar a consumir mucha memoria en documentos grandes



Lección 3.3: Aspectos semánticosLección 3.3: Aspectos semánticos

3.1: Introducción




Aspectos semánticos de un protocoloAspectos semánticos de un protocolo

•Ya conocemos los aspectos sintácticos (formatos y codificaciones) de un protocolo•Para poder especificar el protocolo por completo, también hay que especificar las semántica de los mensajes•Especificar la semántica de un mensaje significa responder a la pregunta:¿Qué debe hacer el programa al recibir este paquete?•La semántica de un protocolo depende del objetivo para el que ha sido diseñado•Diferentes aplicaciones pueden requerir diferentes semánticas•Ejemplo: Semántica de un mensaje GET en HTTP 1.0 (RFC 1945)


8.1 GET The GET method means retrieve whatever information (in the form of an entity) is identified by the Request-URI. If the Request-URI refers to a data-producing process, it is the produced data which shall be returned as the entity in the response and not the source text of the process, unless that text happens to be the output of the process.

The semantics of the GET method changes to a "conditional GET" if the request message includes an If-Modified-Since header field. A conditional GET method requests that the identified resource be transferred only if it has been modified since the date given by the If-Modified-Since header, as described in Section 10.9. The conditional GET method is intended to reduce network usage by allowing cached entities to be refreshed without requiring multiple requests or transferring unnecessary data.


Lección 3.4: Secuenciamiento de mensajesLección 3.4: Secuenciamiento de mensajes

3.1: Introducción




Secuenciamiento de mensajesSecuenciamiento de mensajes

•Para que la definición de un protocolo sea completa hay que especificar qué secuencias de mensajes están permitidas en el protocolo•Para representar las secuencias de mensajes permitidas se suelen usar máquinas de estados en las que es necesario definir

•Estados•Transiciones

•El estado es la información pasada que debe tener un proceso para poder ejecutar la semántica de un mensaje que acaba de recibir•El estado viene representado por el valor de una o varias variables (de estado)•Las transiciones indican bajo qué circunstancias se transita de un estado a otro•En cada transición los procesos pueden realizar una o varias acciones


Estado inicial Estado final

Eventos que producen la transiciónAcciones que se ejecutan en la transición

Diagrama de estados de protocolosDiagrama de estados de protocolos

•Diagrama de estados del protocolo HTTP•Lo único que el protocolo necesita para procesar un mensaje es el propio mensaje•No hay estados (no se requiere información sobre mensajes pasados)


Protocolo

Inactivo

Protocolo

Inactivo

Protocolo

Activo

Usuario inicia conexión

Se inicia conexión TCP

Ser

vid

or

cier

ra c

on

exió

n

Se

cier

ra c

on

exió

n T

CP

Cliente envía petición

Cliente recibe respuesta

Protocolo

Activo

Cliente origina conexión

----

Servidor recibe petición

Servidor envía respuesta

Se

han

ser

vid

o t

od

os

los

recu

rso

s

Ser

vid

or

cier

ra c

on

exió

n

CLIENTE SERVIDOR

Diagrama de estados de protocolos Cont.Diagrama de estados de protocolos Cont.

•Diagrama de estados del protocolo SMTP•El servicio se presta en una sesión que requiere el intercambio de varios mensajes•Es necesario que el protocolo “recuerde” el contenido de mensajes pasados•El protocolo tiene estado


unix% telnet mail-server-1 25 Trying 137.195.13.6 ... Connected to izanami. Escape character is '^]'. 220 izanami.macs.hw.ac.uk ESMTP Exim

1.92 #3 Tue, 28 Jan 2003 12:14:16 HELO macs.hw.ac.uk 250 izanami.macs.hw.ac.uk Hello at

linux23.macs.hw.ac.uk [137.195.15.23]

MAIL FROM:<[email protected]> 250 <[email protected]> is syntactically

correct RCPT TO:<[email protected]> 250 <[email protected]> is syntactically

correct DATA 354 Enter message, ending with "." on

a line by itself Subject: blackmail The game is up. I know your secret. . 250 OK id=105qM4-00037n-00 QUIT

Idle

Connected

HELO Rec

FROM Rec

TO Rec

DATA

. Rec

Error or

Quit command

Mail sent

Connection

Established

Tema III: Comentarios y referenciasTema III: Comentarios y referencias•Comentarios y reflexiones

•¿Qué aspectos de la especificación e implementación de un protocolo se pueden automatizar con mayor facilidad?•¿Por qué decimos que TCP/IP sigue un esquema big-endian?•Prueba a definir un formato de paquete en ASN.1 que transporte la misma información que un paquete de petición HTTP•Utiliza un compilador de ASN.1 y escribe un protocolo de nivel de aplicación en Java basado en ese paquete y en uno de respuesta similar•Prueba a utilizar la API DOM de Java para parsear un fichero XML, ¿qué ventajas te ofrece definir el formato con una DTD o en XML Schema?

•Referencias•Redes de Computadores. Andrew S. Tanenbaum. Prentice Hall, Cuarta Edición, 2003•Redes de Computadores, un enfoque descendente basado en Internet. James F. Kurose y Keith W. Ross. Addison Wesley, Segunda Edición, 2003•Nunca desprecies el poder de Google•Nunca desprecies el poder de Wikipedia


Tema III: ResumenTema III: Resumen

•Contenidos•Protocolos en el nivel de aplicación

•La labor del programador•Ingredientes para poder implementar un protocolo

•Aspectos sintácticos•Formatos y codificación•Aplanamiento/desaplanamiento•Soluciones específicas •ASN.1•XDR•ABNF•XML

•Aspectos semánticos•Secuenciaminento de mensajes

•Protocolos sin estados•Protocolos con estados


tema iii: protocolos basados en paso de mensajes luis lópez fernández

Documents