3.3 Protocolos abiertos para M.I.
Habiendo seleccionado
una implementación cliente-servidor, estudiaremos los
protocolos de mensajería disponibles, se realizará
una breve reseña sobre protocolos propietarios y luego se
presentarán los protocolos SIMPLE, XMPP (antes Jabber) e IRC,
protocolos abiertos
Los sistemas de
mensajería basados en protocolos propietarios o cerrados,
tales como los que utilizan MSN
de Microsoft, AIM de AOL, ICQ de Mirabilis y Yahoo entre otros,
también son soluciones cliente-servidor pero el hecho de que
dichos protocolos sean propietarios, hace muy difícil la tarea
de implementación de servidores Open/Free que soporten los
mismos, generalmente se requiere de ingeniería reversa lo cual
puede resultar muy costoso sobre todo si el protocolo cambia seguido
para añadir nuevas funcionalidades (otro lei-motive por
parte de empresas comerciales acerca del cambio de sus protocolos es
justamente dificultar la tarea de ingeniería reversa para que
servidores que no sean implementados por la empresa propietaria
queden obsoletos)
A pesar de esta
característica, existen algunos
servidores (ICQ) para plataforma GNU/Linux. Los mismos han sido
desarrollados utilizando estas técnicas y al momento de la
investigación (07/2004) estaban discontinuados.
El siguiente paso lógico
de la investigación fue sobre el estudio de los protocolos
abiertos para mensajería instantánea.
3.3.1 Protocolos Abiertos
(SIMPLE, XMPP, JABBER, IRC)
A continuación presentamos cada
uno de los 4 protocolos abiertos más importantes en lo que
respecta a mensajería instantánea.
Nota: XMPP deriva del protocolo Jabber por lo cual se realizará
específicamente el análisis
de XMPP explicando su evolución
desde Jabber y sus principales diferencias.
3.3.2 IRC
IRC (RFC1459) o "Internet Relay Chat". Fue originalmente
escrito por Jarkko Oikarinen en 1988 y fue designado como un
reemplazo del arcaico programa “talk”.
IRC proporciona un medio de comunicación en tiempo real
basado en chatrooms o canales donde un usuario puede unirse a canales
para hablar con todas las personas presentes en dichos canales, o
también brinda la posibilidad de entablar una conversación
entre 2 personas de el mismo canal, existen redes de servidores IRC
públicas, la red más grande es Efnet (la red originaria
de IRC, muchas veces conteniendo más de 32.000 usuarios a la
vez), seguida por Undernet, IRCnet, DALnet y NewNet
IRC ganó fama internacional durante la Guerra del Golfo
Pérsico en 1991 donde usuarios de todo el mundo se reunían
en un canal donde se registraban los reportes en vivo de forma online
La arquitectura propuesta por el protocolo es cliente servidor
3.3.3 SIMPLE
Las Session Initation Protocol for Instant Messaging and Presence
Leveraging Extensions (SIMPLE ) son un conjunto de extensiones que le
permitan al Session Initation Protocol (SIP) brindar las
funcionalidades básicas para el manejo de presencia y de
mensajería instantánea, tal como su nombre lo indica.
Estas extensiones fueron desarrolladas por la IETF y están
siendo propuestas por el grupo de trabajo sobre SIMPLE de la Internet
Engineering Task Force (IETF). De todos los internet-drafts
propuestos (21), 3 fueron pasados a RFC :
El resto de las especificaciones continúan como Drafts
SIMPLE provee como primitivas las siguientes señales (notar
que el término “señal” lo hereda de su
origen en la telefonía):
|
INVITE
|
Es la encargada de marcar el comienzo de sesión.
|
|
BYE
|
Usada para finalizar la sesión.
|
|
Estas dos son heredadas de SIP.
|
|
MESSAGE
|
Se utiliza para enviar un mensaje de tipo disparo o llamado de
modo paginador (pager mode).
|
|
SUSCRIBE
|
Solicita información de presencia, la cual será
enviada al solicitante.
|
|
NOTIFY
|
Transporta la información de presencia.
|
Para las sesiones de M.I. normales, es
decir conversaciones, SIMPLE inicia
utilizando INVITE y luego pasa a utilizar el protocolo de transporte
llamado Message Session Relay Protocol (MSRP).
SIP (así también
como SIMPLE) es orientado end-to-end, lo que implica que toda la
lógica es manejada por los
dispositivos cliente (salvo el ruteo de las señales), no hay u
único punto de falla y las redes
pueden escalar de buena manera. el precio a pagar es mucho más
overhead de los mensajes (señales) y
mucho más proceso del lado de los clientes, que a su vez
tienen una parte de cliente servidor. La parte cliente (UAC - User
Agent Client) es la que manda requests y recibe responses de otros
servidores y la parte de servidor (UAS User Agent Server) recibe
requests externos y envía responses.
Como la comunicación entre 2 usuarios es de estilo
peer-to-peer, también agrega un poco más de complejidad
si se quiere implementar algún requerimiento específico
, por ejemplo : registro de conversaciones entre dos usuarios para
auditoría.
SIP está basado en el protocolo
HTTP , el cual hereda el formato de cabezales de los mensajes del
RFC822. SIP también hereda la codificación
de cabezales de mensajes del RFC822
Las entidades SIP se identifican utilizando
SIP URI's (Uniform Resourse Identifiers) la forma de una SIP URI es
sip:usuario@dominio, en un
estilo de dirección de e-mail .
|
|
Envío de Mensajes
Los clientes de M.I. envían el tráfico real a sus
pares directamente o a través de
Servidores Proxy SIP o Servidores de
Redireccionamiento SIP.
Los servidores proxy SIP reenvían
los pedidos entre elementos del sistema SIP tales como teléfonos
SIP, mientras que los servidores de redireccionamiento
son usados para comunicarle a los
clientes acerca de los movimientos de los participantes.
Un cliente M.I. usa MIME para enviar pedidos de multimedia.
M.I. multiparte y salas de chat son soportados, ya que SIP fue
diseñado para rutear señales tanto a más de
un punto final como a uno solo.
La relación de M.I./presencia con SIP es análoga
a la de SMS con la telefonía celular. SMS utiliza
piggybacking sobre la red de tecnología celular y
M.I./presencia lo hace sobre SIP, el cuál es el la forma de
señalización telefónica de Internet con mas
momentum en la actualidad.
Al utilizar SIMPLE, M.I./presencia automáticamente gana
los beneficios de SIP, los cuales combinan multimedia,
funcionalidades de multiparte y groupware, así como la
ventaja de soportar estas mismas funcionalidades para usuarios
“móviles” (PDAs, celulares, etc.)
|
|
Figura
1 : Todo el contenido con copyright 1995-2003 Network World, Inc.
http://www.nwfusion.com.
Este texto corresponde a
una traducción realizada de la sección Spreading
Messages de [8].
|
3.3.4 XMPP y Jabber
En enero del año 1998 Jeremie Miller, hace de público
conocimiento la especificación un protocolo de mensajería
instantánea abierto basado en XML , bautizado como Jabber (que
significa algo así como “Parloteo”). El origen de
Jabber se da gracias a que Miller tenía que utilizar varios
clientes de M.I. para mantener todos sus contactos lo cual le
resultaba problemático.
La solución obvia podría ser construir un cliente
único que soportara todos los protocolos de sistemas de M.I. ,
pero Miller encontró los siguientes problemas:
La naturaleza de los protocolos propietarios hacían
difícil la implementación para un soporte completo en
el cliente y lo hacia demasiado complicado.
Cada vez que se hiciera cambio de protocolos (algo que estaba
fuera de su control) o se implementara un nuevo protocolo, el
cliente debería ser modificado y reinstalado , una tarea
no muy práctica en sitios con muchos usuarios
Se suma que la programación de interfaces
gráficas no es el fuerte de todos los programadores, como el
caso de Miller, entonces prefirió concentrar esfuerzos en
problemas más específicos y dejar a otros la
construcción de Interfaces Gráficas
Miller entonces decidió crear una solución con las
siguientes características:
Llamó a esta solución Jabber. Una parte fundamental
de la arquitectura propuesta por Miller fue
que el servicio sería descentralizado, tal vez porque no se
consideró a priori para grandes organizaciones, donde
cualquiera podría tener su propio servidor con su propio
dominio, muy similar a servidores SMTP, esta desisión de
Miller (tal vez casual), tiene un efecto colateral muy beneficioso en
cuanto a la capacidad de implementar la solución en cualquier
tipo de red de una forma tan distribuida
como se quiera (una empresa puede tener un servidor con domino propio
por sección, por departamento, por sucursal)
En agosto de 1999 Miller pide a la comunidad de Jabber en Internet
soporte para que Jabber sea contemplado por la IETF. Una año y
medio después en Junio del 2000, Miller y otros miembros del
proyecto Jabber enviaron un 'Internet draft' al grupo de trabajo de
la IETF encargado de protocolos de Mensajería instantánea
y Presencia (IMPP – Instant Messaging and Presence Protocol),
dicho borrador (draft) documentaba el protocolo Jabber, el primer
intento fue infructuoso ya que el draft expiró sin ninguna
contribución por parte del grupo de trabajo.
A principios de 2002, la comunidad de Jabber decidió una
vez más enviar el protocolo Jabber a la IETF y esta vez hubo
éxito pues la IETF formó un grupo de trabajo llamado
XMPP (eXtensible Messaging and Presence Protocol).
El grupo de trabajo XMPP produjo cuatro Internet drafts, que
recientemente (Octubre de 2004) pasaron a ser RFC's (cuya categoría
actual es la de estándar Track)
Los cuatro documentos corresponden a :
Antes draft-ietf-xmpp-core-22, actualmente RFC3920,
especifica el núcleo del protocolo,
a saber, como el protocolo utiliza flujos de datos en XML para
intercambio de información estructurada en tiempo real entre
dos puntos dentro de una red informática.
Antes draft-ietf-xmpp-im-21, actualmente RFC3921,
especifica como extender el núcleo
del protocolo (XMMP:core) para proveer funcionalidad básica de
mensajería instantánea y de información de
presencia de acuerdo con el RFC2779
(Instant Messaging / Presence Protocols Requirements)
Antes draft-ietf-xmpp-cpim-04 ,
actualmente RFC3922, especifica el mapeo entre XMPP y la
especificación CPIM (Common Profile Instant Messaging),
principalmente para poder implementar gateways intermedios para
comunicación entre servicios XMPP y servicios no-XMPP
Antes draft-ietf-xmpp-e2e-07,
actualmente RFC3923, define los métodos
para habilitar a un usuario a firmar y/o encriptar un mensaje enviado
a un recipiente específico.
En el Apéndice 8.11 se presenta
un análisis mas detallado de dicho protocolo.
3.3.5 Conclusión
Luego de el análisis realizado
en el apéndice 8.11 acerca de el protocolo XMPP, encontramos
que el mismo es muy elegante, sencillo, entendible, potente y
extensible. XMPP cuenta con todas las características para
volverse estándar de la IETF y si bien la mayoría de
implementaciones de servidores de mensajería están
basados en el protocolo Jabber, es de esperar que en siguientes
versiones de los productos todos tienda a ser compatibles con la
versión 1.0 de XML propuesta.
La arquitectura cliente-servidor
propuesta por XMPP también es muy elegante y sencilla,
pudiendo obtener sistemas distribuidos inclusive con componentes de
los servidores distribuidos, escalabilidad horizontal, clusters de
servidores, implementación sencilla para failover y control
total sobre el flujo de la información.
Notamos que XMPP brinda todas las
herramientas y especificaciones para extender el protocolo y para
poder lograr interoperabilidad con (y entre) aplicaciones
empresariales como correo, groupware, sistemas de ERP, CRM, etc.
Estudio del Open/Free (GNU/Linux) como plataforma de servicios de red en entornos empresariales
Daniel Caraballo - Mario Madera - Marcelo Odin
Tutor: Ariel Sabiguero Yawelak
2004 - 2005.