Protocolos de comunicación

Es conocido que Flex ofrece diversas formas para la comunicación con el servidor: HttpService, WebServices, RemoteObject, Image, FileReference, Mensajería… pero cuáles son los protocolos que se emplean por detrás? Cuántos protocolos se pueden utilizar en Flex? Cuál es la diferencia entre AMF, HTTP y RTMP? Este post pretende aclarar estas y otras cuestiones sobre los protocolos de comunicación utilizados por Flex.

Protocolos soportados por Flex

Flex soporta sólo dos protocolos de comunicaciÛn: HTTP y RTMP. Realmente, utilizando Sockets puede llegar a soportar cualquier protocolo, pero fuera de HTTP y RTMP (con sus sucedáneos:HTTPS, etc.), toda la implementación del protocolo la tiene que hacer el usuario.

HTTP (Hypertext Transfer Protocol)

Es el protocolo de Internet por excelencia. Su puerto por defecto es el 80. Los datos que se transmiten van en formato plano. La gran ventaja sobre RTMP, es que ofrece la seguridad de que ningún firewall de ninguna empresa va a ser obstáculo.

La desventaja que tiene es que es un protocolo unidireccional. No permite el data-push por parte del servidor al cliente. Se puede intentar emular esta capacidad con la técnica conocidad como polling, que no es más que hacer que el cliente le pregunte cada cierto tiempo al servidor si hay alguna novedad o no. Esta técnica puede incrementar de forma considerable el tráfico en la red.

Estos son los componentes que utilizan el protocolo HTTP: HTTPService (métodos GET, POST, HEAD, OPTIONS, PUT, TRACE, y DELETE), WebService (SOAP encapsulado en HTTP), FileReference (método POST para subir y bajar ficheros, tambiÈn GET para el paso de parámetros) e Image.

También se utiliza HTTP en los distintos servicios del Adobe LifeCycle Data Services (LCDS en adelante), dependiendo del canal escogido (ver apartado AMF).

HTTPS (Hypertext Transfer Protocol over Secure Socket Layer, la versión segura de HTTP), es otra de las opciones a la hora de intercambiar datos con el servidor. Su puerto por defecto es el 443.

RTMP (Real Time Messaging Protocol)

Protocolo propietario de Adobe. Puerto por defecto: 1935

Ofrece dos grandes ventajas:

  • Permite data-push desde el servidor al cliente.
  • Permite el streaming de audio, video y datos en Internet (con LifeCycle Data Services sólo datos, con Flash Media Server audio, video y datos, con WebORB.NET también audio y video.
  • Su gran desventaja radica en que los firewalls de algunas empresas, por cuestiones de seguridad, pueden tener capado el puerto 1935 o directamente el protocolo.

    Para solventar este problema sin perder la funcionalidad se desarrolló RTMPT (Real Time Messaging Protocol Tunneled). Este protocolo encapsula los datos RTMP en peticiones válidas HTTP, y por lo tanto, la comunicación se hace a través del puerto 80, superando el bloqueo de los firewalls. Lógicamente, requiere algo más de ancho de banda que el RTMP, por las cabeceras HTTP y puede ser algo más lento, sobretodo en el establecimiento de la conexión. Tanto LCDS como WebORB.NET soportan RTMPT. FluorineFx lo hará en la siguiente versión.

    También existe la versión segura de RTMP (RTMP sobre Tranport Layer Security), llamada RTMPS, que tiene al mismo problema con los firewalls que su versión no segura. Por ello, se pueden encapsular los datos RTMP en HTTPS. A esto se le llama RTMPS tunneled.

    El protocolo RTMP lo emplea el bus de mensajería de LCDS, si el usuario escoge un canal RTMP.

    AMF (Action Message Format)

    Protocolo binario de Adobe que va por la versión AMF3 (han publicado recientemente su especificación). Aunque por el nombre de la versión pueda parecer que existan 3 cabe destacar que sólo existen dos: AMF0 y AMF3. Una de las mayores diferencias o mejoras que aporta AMF3 es que soporta datos binarios (ByteArray) y int, datos no soportados por AMF0 debido a que en la época que apareció el formato, Flash Player no soportaba estos tipos de datos.

    AMF3 no es un protocolo para transferir información (como sÃŒ lo son HTTP y RTMP), sino que representa el formato en el que se transmite la información, en este caso un formato binario. El AMFGateway que se encuentra en LCDS (y sucedáneos) serializan y deserializan automáticamente los objetos debidamente serializados desde FlashPlayer.

    Utilizando LCDS (o similares), todos los mensajes/llamadas, con RemoteObject, FlexMessaging y DataManagementeServices van en formato AMF. Puede ser AMF sobre HTTP o AMF sobre RTMP. Es decir, en los ficheros XML de configuración de estos servicios (remoting-config.xml, mesagging-config.xml, etc.), cuando se definen canales, el usuario escoge entre HTTP y RTMP, aunque el nombre de los canales disponibles sea:

    • mx.messaging.channels.AMFChannel : AMF3 sobre HTTP
    • mx.messaging.channels.RTMPChannel : AMF3 sobre RTMP
    • mx.messaging.channels.SecureAMFChannel : AMF3 sobre HTTPS.
    • mx.messaging.channels.SecureRTMPChannel : AMF3 sobre RTMPs
    • mx.messaging.channels.SecureHTTPChannel : Datos en formato texto sobre HTTPS.

    Sockets

    Los socket permiten al usuario crear cualquier conexión con cualquier protocolo (que el servidor pueda atender, claro). Eso sí, implementándolo de forma manual. Se puede crear una aplicación Flex que sea un cliente FTP, o que se conecte a servicios como POP3, IMAP y SMTP. Pero lo dicho, es el usuario quién tiene que gestionar todo y cumplir lo que establezca el protocolo.

    Bueno, pues hasta aquí con los protocolos en Flex. Espero haber aclarado un poco este tema. Y seguro que podemos ir completando la información con los comentarios.

11 Comentarios

  1. Xavi Beumala

    Enhorabuena Aritz, la verdad que es una tema que suele liar mucho por la cantidad de posibilidades y siglas que tiene. Pero lo has explicado super claro! Thx

  2. David Serrano

    Muy buena explicación Aritz, la verdad es que con tantos protocolos de comunicación que acepta Flex, a veces es dificil elegir, aunque sin ser excluyentes, también depende del tipo de aplicación que se va a desarrollar.

  3. Aritz Oruesagasti

    @ David, Alberto, Rainer: Gracias por vuestros comentarios!

    @ Rainer: El enlace a ese benchmark viene muy bien como complemento del artículo (creo que en su día ya se publicó en MIF). Es apabullante la diferencia de velocidad entre utilizar AMF3 y los demás métodos.

  4. javi

    La verdad es que el articulo practicamente no explica las diferencias entre los distintos protocolos, cuales son recomendables utilizar en cada caso ni cosas como rendimiento… AMF3 no es un protocolo para transferir informacion? Pues vaya… Y con tantisimas soluciones open source en AMF es necesario hablar de LCDS? Ya que hablas de WebOrb antes pes seria al menos interesante mencionarlo.
    Por lo tanto me parece un articulo poco riguroso y que quiza pueda aportar mas confusion que claridad. Recomiendo pasarse mejor por la documentacion oficial de Adobe si alguien quiere saber mas de estos temas.

  5. Aritz Oruesagasti

    Vayamos por partes:
    “La verdad es que el articulo practicamente no explica las diferencias entre los distintos protocolos”
    Explica algunas, evidentemente las más generales, está claro que siempre se podrá completar más. Hubiera estado bien que tú las hubieras puesto en tu comentario.

    “AMF3 no es un protocolo para transferir informacion?”
    No quiero entrar en ninguna guerra semántica de cuál sería el término exacto. Simplemente quería señalar que AMF3 no es un protocolo alternativo de HTTP y RTMP. Siempre va encapsulado en uno de estos protocolos. Es el formato binario de AS3 (igual que AMF0 era el formato binario de AS1 y AS2).

    “con tantisimas soluciones open source en AMF es necesario hablar de LCDS”
    Poner todas las alternativas a LCDS, me dio la impresión que quedaba fuera de la temática de este post. Es verdad que menciono en algún momento puntual WebORB.NET y FluorineFX (por que los utilizo), pero en lo que de verdad importa del post utilizo expresiones como “LCDS (y similares)” queriéndome referir a LCDS y todas las demás alternativas existentes. Este tema de las alternativas da para otro post entero, explicando qué características tiene cada una de ellas.

    “quizá pueda aportar más confusión que claridad”
    ¿ Qué es lo que te ha creado confusión ?

    “Recomiendo pasarse mejor por la documentacion oficial de Adobe si alguien quiere saber mas de estos temas.”
    Yo también lo recomiendo!, es que no puede ser de otra forma…. nunca he pretendido sustituir a la documentación de Adobe. 😉

  6. Rainer Ramirez

    Estimado Javi, lo que yo opino es que este tipo de posts están dirigidos a personas con conocimientos mínimos de las tecnologías citadas en ellos. Por lo tanto se supone que hemos tenido algún mínimo contacto con LCDS, Blazeds, WebORB, etc. O por lo menos sabemos de su existencia y para que sirven. Este tipo de posts son mas una manera de ampliar esa información que ya tenemos y clarificar algunos puntos que quisas en la documentación oficial de adobe es difícil de encontrar. Por ejemplo en mi caso, gracias a este post me entero de que AMF3 no es un protocolo alternativo de HTTP y RTMP, y que mas bien va encapsulado en alguno de estos dos protocolos. Aun mas útil fue el comentario de la desventaja de RTMP como protocolo por salir por el puerto 1935 ya que los que hemos trabajado en ambientes de servidores sabemos que los firewall si bien son un mal necesario aveces originan errores fantasma que son muy difíciles de detallar y gracias a este comentario puedo estar seguro de que puerto debo abrir.

  7. Diego Baselica

    Hola, hace un tiempo trabajamos con Flex y .NET mediante WebServices
    Pero recien ahora estamos interiorizandonos en remoting ya que en principio necesitamos integrar una mensajeria a nuestra aplicacion.
    De alli que comenzamos a ver que existe y encontramso WebOrb (pago) y Ffluorinefx (free)
    Pero tambien surge en el medio LCDS y alli es donde nos surge la duda, como digo debido a que somos nuevos en esta area.
    Nuestra intension es utilizar RTMP pero al parecer con Fluorine siempre necesito a LCDS en el servidor y es algo que por los costos no esta a nuestro alcance.
    me podrian decir si estamos bien rumbeados o no.
    Gracias..

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Acerca de Made In Flex

Made In Flex es una comunidad de desarrolladores de Apache Flex creada en 2006.

Apache Flex, anteriormente conocido como Adobe Flex, es un SDK (kit de desarrollo de software) para crear aplicaciones enriquecidas - multiplataforma basadas en Adobe Flash donado por Adobe a la fundación Apache in 2011 y promocionado a proyecto de primer nivel en Diciembre de 2012.

Actualmente estamos cambiando muchos aspectos del sitio web para ofrecer un sitio útil para toda la comunidad que tenga en cuenta las necesidades actuales.

Últimas Fotos

Instalador de Apache Flex

Entrar o Registrase