El Miércoles 17 Sep 2008 13:00, Herr Groucho escribió: > Hola. > > Los envíos de archivos sobre XMPP pueden realizarse de 2 maneras: en banda > y fuera de banda. En banda significa encapsularlos en el flujo XML de un > cliente al servidor y del servidor al otro cliente. Es así [por ejemplo > como se reciben las imágenes que la gente pone en su perfil. "Fuera de > banda" significa que los clientes se comunican directamente entre sí, para > lo cual tienen que mandarse "en banda" la información pertinente para > lograrse conectar directamente (dirección IP y puerto). Por razones > obvias, la transferencia de archivos genérica ofrecida por los clientes de > XMPP para IM es fuera de banda. > > El problema que quiero plantearles empieza cuando los clientes están > detrás de un router que haga NAT o de un proxy, situación en la que en > general van a ser incapaces de comunicarse información correcta para > conectarse directamente. > > Qué se puede hacer? La solución obvia es redireccionar puertos del router > a puertos de los hosts en donde están corriendo los clientes IM. Pero como > todo el mundo tiene notebook, significa que cuando alguien va a visitarme > a mi casa antes de que pueda utilizar esa función de su cliente de IM > tiene que pedirme que le redireccione un puerto, y me tiene que decir qué > dirección IP le asignó mi servidor DHCP a la notebook del visitante y me > tengo que acordar de limpiar esa redirección cuando se vaya, y crea la > tradicional sensación de que "todas esas cosas raras" que usamos los geeks > son deficientes y difíciles de usar. O en una red de una oficina, > significa que le rompan las bolas al encargado de la red cada vez que > alguien quiera empezar a usar esa función de su cliente de IM. > > Otra semi-solución es usar un "proxy de trasnferencia de archivos": un > host que reciba el archivo por mí y de donde yo después lo chupe por algún > medio que puede no tener nada que ver con XMPP. Pero como se advierte, eso > sólo sirve para que externamente los demás no noten que en realidad a uno > no le funciona recibir archivos en el cliente de IM. > > Lo que quiero saber es por qué los windowsos con sus programas > propietarios de IM, sus redes cerradas y sus protocolos secretos pueden > transferirse archivos sin que nadie tenga que configurar nada en ningún > lugar. Nosotros deberíamos hacerlo mejor que ellos! > En particular, cómo es que un windowso NATeado en mi red y sin que yo > configure nada puede enviar y recibir archivos con su cliente de MSN > messenger. Entiendo que pueda ser que pueda si ambos clientes de IM están > en la red local, pero no cuando uno está en la red local y el otro en > Internet, o incluso detrás de otro router que haga NAT. Consideremos > hostil mi red: nada de uPNP por ejemplo para perforar mi router/firewall. > > Qué mierda hacen? > Y eso que hacen, podría hacerse con XMPP? > Y si se pudiera hacer hacer con XMPP, lo podría hacer un transporte de MSN > messenger a XMPP como el del LUGMen? > > Desde ya, gracias por las respuestas pertinentes, o por las respuestas > impertinentes pero no ofensivas.
A ver, el problema no es fácil. Establecer un procolo sencillo de intercambio de archivos a través de Jabber no ha sido un problema sencillo de resolver. Pensa en todos los casos que se pueden dar: firewalls, NAT, etc... Debido a ésto, se ha tardado bastante en ponerse de acuerdo a la hora de establecer cuál debía ser el protocolo. La transferencia de archivos solía funcionar sin problemas entre los mismos clientes e incluso entre ellos ([Exodus] y [Tkabber], por ejemplo). La [Jabber Software Foundation] acaba de aprobar los JEPs de Stream Initiation y File Transfer Stream Initiation Profile. Pronto, la mayoría de clientes lo tendrán implementado y tendremos un buen sistema de transferencia de archivos. Exodus, en los dailies, ya soporta el nuevo estándar y puede que Jarl también (al menos Net::Jabber sí). El nuevo sistema de transferencia necesita un componente en el servidor, que es el Proxy65. salu2 -- JuAN EdUArDo ViTaLe Id Jabber: [EMAIL PROTECTED] KFP = 789F AFB9 63CA 56AE F789 B72A 34FE FCBF D2E1 39A6 Public_key = gpg --keyserver pks.lugmen.org.ar --recv-keys D2E139A6
