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.