Tema III: Protocolos basados en paso de mensajes Luis López Fernández.

Presentación del tema: "Tema III: Protocolos basados en paso de mensajes Luis López Fernández."— Transcripción de la presentación:

1 Tema III: Protocolos basados en paso de mensajes Luis López Fernández

2 Tema III: Protocolos basados en paso de mensajes Tema 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

3 Tema III: Protocolos basados en paso de mensajes Lección 3.1: Introducción 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

4 Aplicaciones y protocolos de nivel de aplicación TCP/IP Sistema operativo Hardware sockets Protocolo de nivel de aplicación Lógica de la aplicación Presentación de 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 Tema III: Protocolos basados en paso de mensajes Lo proporciona el sistema Tarea del desarrollador Asignaturas de creación de GUIs Asignaturas de programación Esta asignatura Asignaturas de redes

5 Protocolos 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 Tema III: Protocolos basados en paso de mensajes

6 Tema III: Protocolos basados en paso de mensajes Lección 3.2: Aspectos sintácticos 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

7 Especificació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? Tema III: Protocolos basados en paso de mensajes

8 Especificació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 Tema III: Protocolos basados en paso de mensajes

9 Tema III: Protocolos basados en paso de mensajes Los 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(int  4 u 8 bytes) Java(char  2 bytes), C(char  1 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?

10 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 Tema III: Protocolos basados en paso de mensajes Aplanamiento y desaplanamiento

11 Tema III: Protocolos basados en paso de mensajes … 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 separadores Paquetes 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 bytes con es quema big-endian -Los caracteres se codifican con un byte en formato ascii 00 00 00 01 00 00 00 02 2B

12 Aplanamiento/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 Tema III: Protocolos basados en paso de mensajes

13 Abstract 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. Tema III: Protocolos basados en paso de mensajes

14 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 Tema III: Protocolos basados en paso de mensajes CalcProtocol DEFINITIONS ::= BEGIN CalcPetition ::= SEQUENCE { operandoI INTEGER, operandoD INTEGER, operación IA5String (SIZE(1)) } CaclRespuesta ::= SEQUENCE { resultado INTEGER, codigo INTEGER, descripcion IA5String } END

15 Abstract Syntax Notation One Cont. 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ísticas  Basic Encoding Rules (BER) oCada elemento de datos se codifica especificando tres parametros: un identificador, la longitud de los datos y los propios datos oEl decodificador va recuperando los datos “sobre la marcha” al recibirlos oSe 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 eficiencia oRequire 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) Tema III: Protocolos basados en paso de mensajes

16 Abstract Syntax Notation One Cont. 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/) Tema III: Protocolos basados en paso de mensajes

17 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 Tema III: Protocolos basados en paso de mensajes 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 +-------+-------+-------+-------+

18 Formatos 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 XDR 00000000 00000000 00000000 00100001 El número entero 33 representado como la cadena de caracteres “33” en ascii 00110011 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 Tema III: Protocolos basados en paso de mensajes

19 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) Tema III: Protocolos basados en paso de mensajes 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

20 Formatos 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 Tema III: Protocolos basados en paso de mensajes

21 Fundamentos 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 ‘ ’ La etiqueta de finalización es el mismo nombre rodeado por los símbolos ‘ ’ 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: Juan Nadie x &lt y + 4 Mariano Sánchez 32 Euros Tema III: Protocolos basados en paso de mensajes

22 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 ‘ ’ Se pueden añadir comentarios entre los símbolos ‘ ’ Ejemplos: Mariano Sánchez va de un alumno al que no le gustaba estudiar Tema III: Protocolos basados en paso de mensajes

23 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 Tema III: Protocolos basados en paso de mensajes Basic bread Flour Yeast Water Salt Mix all ingredients together, and knead thoroughly. Cover with a cloth, and leave for one hour in warm room. Knead again, place in a tin, and then bake in the oven.

24 Documentos 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 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 Tema III: Protocolos basados en paso de mensajes

25 DTD 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 Tema III: Protocolos basados en paso de mensajes <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"> Ejemplo de esquema XML usando XML Schema

26 Procesando 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 Tema III: Protocolos basados en paso de mensajes

27 Tema III: Protocolos basados en paso de mensajes Lección 3.3: Aspectos semánticos 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

28 Aspectos 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) Tema III: Protocolos basados en paso de mensajes 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.

29 Tema III: Protocolos basados en paso de mensajes Lección 3.4: Secuenciamiento de mensajes 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

30 Secuenciamiento 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 Tema III: Protocolos basados en paso de mensajes Estado inicial Estado final Eventos que producen la transición Acciones que se ejecutan en la transición

31 Diagrama 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) Tema III: Protocolos basados en paso de mensajes Protocolo Inactivo Protocolo Inactivo Protocolo Activo Usuario inicia conexión Se inicia conexión TCP Servidor cierra conexión Se cierra conexión TCP Cliente envía petición Cliente recibe respuesta Protocolo Activo Cliente origina conexión ---- Servidor recibe petición Servidor envía respuesta Se han servido todos los recursos Servidor cierra conexión CLIENTESERVIDOR

32 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 Tema III: Protocolos basados en paso de mensajes 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: 250 is syntactically correct RCPT TO: 250 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

33 Tema 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: Protocolos basados en paso de mensajes

34 Tema 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