C’est en 1999 que Jeremie Miller crée Jabberd, serveur open source de messagerie instantanée et de présence. Il appelle le protocole (de fait) sous-jacent « Jabber », terme traduisible directement de l’anglais au français comme un « bavardage ». Puis, le petit protocole au nom sans prétention commença à en avoir. Voulant jouer dans la cour des grands, il fut en effet proposé comme standard auprès de l’IETF avec l’objectif de fournir une véritable interopérabilité dans le monde de la communication instantanée, encore jeune, mais déjà quasi-entièrement sous le contrôle de divers réseaux privés, propriétaires et sans aucune transparence de fonctionnement.
Mais l’Internet est sans pitié pour les jeunes présomptueux, et il fallut plusieurs groupes de travail IETF, brouillons, stabilisation du protocole, la création d’une fondation (Jabber Software Foundation)… pour que finalement, début 2004, 5 ans après la création du protocole, ce dernier soit enfin un standard reconnu. On lui accorda des numéros pour faire le fier comme James Bond : RFC 3920 (le cœur) et RFC 3921 (Messagerie Instantanée et Présence). Petit protocole devenu grand décida alors de changer de nom pour paraître plus sérieux lors d’entretiens d’embauche. Il se fit donc appeler XMPP, pour e*Xtensible **Messaging and **Presence **P*rotocol.
À partir de là, la JSF prit plus d’importance, s’organisa davantage et changea à son tour son nom en 2007 pour XSF, XMPP Standards Foundation. Notons l’évolution sémantique : on est passé d’une entité de code (Software) à une autre gérant désormais clairement des Standards. Les rôles sont répartis entre l’IETF et la XSF. L’IETF s’occupe essentiellement du centre névralgique du protocole, ce qui en fait un protocole Internet interopérable. De son côté, la XSF gère en plus les extensions : les XEP (XMPP Extension Protocols). En effet, XMPP a été créé comme un protocole extensible. Par design, il est un triple protocole — comme son nom l’indique : un protocole de Présence (qui de ses contacts est présent ?), un protocole de Messagerie (non forcément lié à la présence : on peut envoyer des messages à des entités dont nous ne connaissons pas la présence, comme pour les e-mails), et enfin, un protocole e*X*tensible, qui permet donc de créer des sous-protocoles de communication, pour tout usage. XMPP fut défini comme un protocole applicatif extrêmement générique, non limité à la messagerie instantanée.
La XSF s’occupe donc en particulier de cette dernière caractéristique (extensibilité), et travaille en collaboration avec l’IETF sur les deux autres.
Néanmoins, cela fait maintenant 7 années que le cœur de notre petit protocole n’avait pas été soigné, bien que souvent ausculté puisqu’il se faisait vieux. C’est pourquoi, après toutes ces années de traitement, le voilà comme un nouveau né avec ses nouveaux numéros d’identité.
En effet, pour fêter le printemps, le 21 mars 2011 est à noter comme le jour où les RFC de XMPP seront mises à jour : les RFC 3920 et 3921 sont désormais obsolètes et remplacées respectivement par les RFC 6120 et 6121. Enfin, une troisième RFC voit le jour, standardisant séparément le format des adresses XMPP (ce qui était auparavant intégré à la RFC 3920) : la RFC 6122.
Sommaire
Vous prendrez bien un petit rafraîchissement ?
Il est à noter qu’il ne s’agit pas d’un nouveau protocole. Ce n’est pas non plus XMPP 2.0 ou un quelconque autre terme commercialement sexy. Non, il s’agit simplement d’un rafraîchissement de protocole qui fait suite aux années d’expériences et aux centaines d’implémentations (clients, serveurs, modules…).
Un cœur sain pour un protocole sain
XMPP est un protocole à la pointe des dernières innovations informatiques, notamment en terme de sécurité. Parmi les nombreux changements dans la RFC 6120, nous pouvons ainsi relever divers renforcements sécuritaires, en particulier :
- l’usage de TLS a été consolidé avec le passage de TLS 1.0 (RFC 4346) à TLS 1.2 (RFC 5346), ainsi que l’interdiction d’utiliser SSL 2.0 à cause des failles de sécurité désormais connues de cette version du protocole SSL (voir RFC 6176) ;
- le mécanisme SASL préféré est désormais passé du simpliste DIGEST-MD5 au très récent et élaboré SCRAM-SHA1-PLUS, lequel fournit des fonctionnalités repérant des attaques d’« homme du milieu » (channel binding), ainsi que la protection du mot de passe (en particulier, si la communication est interceptée, l’attaquant ne peut reproduire pour autant la moindre identification ; si les données stockées sur l’ordinateur client sont volées, l’attaquant n’a pas accès au mot de passe, ne peut se connecter que sur le serveur spécifique pour lequel ces données étaient stockées et ne peut les réutiliser ailleurs, et ce, même si l’utilisateur réutilise ce mot de passe sur d’autres services ; et enfin, si les données sont volées sur le serveur, l’attaquant ne peut se connecter nulle part, pas même sur le serveur lui-même) ;
- le système historique et extrêmement faillible d’identification des entités en S2S (server to server), Server Dialback Protocol, est rétrogradé au rang de d’extension XEP, gardant ainsi la compatibilité avec les systèmes anciens, tout en mettant l’accent sur TLS et SASL external (qui devient une technologie obligatoire à implémenter en S2S).
Comme on peut le voir, l’accent a été mis sur la sécurité et la clarification d’usage des mécanismes au cœur du protocole, faisant de XMPP une des technologies les plus avancées de l’Internet.
D’autres évolutions que nous regardons de près concernent les récentes extensions de sécurité sur le protocole DNS (DNSSEC), l’une des bases et pourtant l’un des maillons les plus faibles de l’Internet (le DNS actuel a un niveau de sécurité quasi-nul, d’où le fameux « homme du milieu », ce qui n’implique pas forcément un espion de l’empire du Milieu !). Plusieurs brouillons de RFC ont été proposés afin d’apporter des améliorations de la sécurité des connexions XMPP par DNSSEC, bien qu’encore aucun consensus ne soit acquis.
Un Internet global
Alors que de nombreux protocoles et systèmes s’embourbent dans les problèmes de localisation, XMPP avait, dès l’origine, fait le choix de ne supporter que le codage UTF-8 pour forcer une interopérabilité entre tous au niveau du protocole. Toujours dans cet esprit de globalisation, les problématiques de localisation sont un des sujets les plus en vogues, et en particulier l’internationalisation des adresses XMPP est le thème du moment.
Cela a conduit à la séparation de la RFC 3920 en deux RFC distinctes. En effet, donner aux adresses XMPP leur propre RFC 6122 permettra de plus facilement en changer la définition, sans pour autant devoir retoucher l’ensemble du cœur du protocole, alors même que nous réfléchissons au moyen le plus fluide de migrer de l’ancienne technologie d’internationalisation des adresses (IDNA 2003) à la nouvelle (IDNA 2008) qui est basée sur des procédés très différents et incompatibles à plusieurs égards tant technologiques, que vis‐à‐vis des combinaisons de caractères permises.
Un autre travail important qui a eté mis en avant dernièrement, bien qu’il y ait clairement une forte latence ici, est le travail d’interopérabilité qui doit se faire avec SIP/SIMPLE, l’autre protocole standardisé de messagerie et de VoIP.
Évolution des usages et démocratisation
L’évolution des usages conduit aussi à une évolution des protocoles. Alors que les ancêtres comme HTTP et ceux qui l’implémentent refusent encore de s’approcher des nouvelles technologies très utiles, comme les services DNS (SRV records), XMPP a deux services largement utilisés enregistrés par l’IANA (un pour le client, un pour le serveur) depuis déjà la RFC 3920 !
De nombreuses discussions sont en cours pour davantage simplifier, tout en sécurisant, les usages d’hébergement massif de domaines XMPP chez des fournisseurs de services tiers (ce que, par exemple, Google, avec ses fameux Google Apps, contribue à démocratiser de plus en plus) avec des propositions se basant soit sur de nouveaux enregistrements de services DNS, soit sur DNSSEC, ou les deux à la fois. Là encore, aucun consensus n’est encore acquis.
T’es là ?
Enfin, la messagerie instantanée et la présence ne sont pas en reste. Parmi les nombreuses évolutions de la RFC 6121, la plus notable est probablement le versionnement de liste de contact qui est passé du statut de XEP à celui de protocole IETF, par son intégration dans la RFC 6121. Il permet d’éviter le téléchargement d’une liste de contacts à chaque connexion si elle n’a pas changé, ou de ne charger qu’un différentiel, évitant ainsi du trafic inutile, en particulier pour les gens possédant des milliers de contacts.
De même, la gestion des erreurs pour réparer les problèmes de synchronisation de liste de contacts que les utilisateurs ont pu connaître au fil des années, ainsi que le routage des messages, ont été améliorés.
Un autre ajout intéressant est la nouvelle notion de « parentée » des fils de discussions permettant de créer, là encore, une expérience de dialogue améliorée sur les clients adaptant leur interface.
Ces diverses améliorations et quelques autres devraient grandement améliorer l’expérience utilisateur.
Retour vers le présent
De nombreuses autres innovations sont présentes dans ces mises à jour d’un des protocoles majeurs de l’Internet, mais je ne peux évidemment pas résumer plusieurs centaines de pages de RFC en quelques lignes.
Mais surtout : et le présent ? Et les « vraies fonctionnalités », celles que vous voulez tous : la vidéo, le son, le travail collaboratif, le jeu ? C’est pour quand ?
Les extensions
Vous avez probablement trouvé les paragraphes précédents rébartatifs. Si, si, ne niez pas ! La sécurité ? Pfff, tout le monde s’en fiche ! On veut juste échanger des LOL avec des images qui bougent et discuter de vive voix avec Mère-Grand, nous !
C’est vrai, l’IETF ne s’occupe pas de ça pour l’instant. Par contre, la XSF, si (si vous avez suivi la répartition des rôles des deux entités, vous le savez déjà). Alors j’avoue, les divers clients ne sont pas encore parfaits, la VVoIP (Video and Voice over IP) laisse encore parfois à désirer, mais les implémentations principales ont déjà presque toutes le support. Ce n’est qu’une question de temps avant que ces implémentations soient vraiment fiables.
La feuille de route indiquant les priorités de la XSF liste ainsi toutes ces extensions dont vous rêvez : de la vidéoconférence de groupe, des salons de discussion distribués, des tableaux blancs partagés et de l’édition de document en collaboration, et même le combat contre le courrier indésirable, avant même qu’il n’apparaisse…
Et si vous en voulez plus, n’hésitez pas à jeter un œil à la liste actuelle des extensions XMPP.
Participez !
Quoi, ce n’est pas assez ? Sachez que vous êtes libres de venir nous rejoindre pour discuter du cœur du protocole et l’améliorer, des extensions, de l’opération de services XMPP sur vos serveurs auto-hébergés (la grande mode sur LinuxFr !), de vos implémentations, ou même en tant qu’utilisateur sur les divers salons et listes de discussions de la XSF et de la IETF.
Si vous êtes vraiment intéressé, je rappelle aussi que le statut de membre XSF est gratuit et n’est pas restreint à une élite technique. Nous acceptons toute personne intéressée, que ce soit techniquement, pour améliorer le fonctionnement interne de la fondation, faire tourner son infrastructure ou communiquer et promouvoir le protocole et son écosystème. N’hésitez pas à postuler !
Enfin, si vous êtes étudiant, vous êtes fortement invité à vous rapprocher d’une équipe XMPP pour ensuite proposer sous notre houlette un projet de Google Summer of Code où la XSF participe, comme chaque année.
XMPP est le grand théâtre de la messagerie instantanée
La XSF n’est pas connue pour ses qualités de communications et d’auto-publicité, c’est certain (c’est aussi pourquoi nous avons besoin de vous !). Nous passons assez inaperçu. Et pourtant… le protocole que nous développons, lui aussi discret, est bien loin d’être un figurant.
Citons une liste absolument non‐exhaustive d’acteurs du Net ou d’en dehors qui ont un rôle sur la scène XMPP (pour être clair, ce ne sont pas forcément les vrais techniciens de l’ombre, ceux qui font avancer le protocole). Cette liste n’a pour seul but que de citer quelques noms connus, voire incongrus, pour montrer que XMPP n’est plus un protocole de geek et qu’il est désormais la référence dans le monde la messagerie instantanée. Si je devais citer toutes les entités réellement derrière le protocole, je n’en finirais plus) :
- BBC radio ;
- Cisco ;
- Le système de discussion dans et hors du jeu EveOnline ;
- Facebook Chat ;
- Google Talk ;
- LiveJournal Chat ;
- la plate-forme de jeu Quake Live ;
- Wordpress Firefose.
Et si vous étiez la prochaine star de XMPP ?
# Bravo
Posté par Altor . Évalué à 2.
Très belle dépêche, très bien écrite, très intéressante …
Continuez comme ça!
[^] # Re: Bravo
Posté par dyno partouzeur de drouate . Évalué à -2.
+10 pour un commentaire de lèche ?
A quand les "me too" à +10 aussi ? Et après on pourra rajouter le bouton [J'aime] pour être complets.
Monde de merde...
[^] # Re: Bravo
Posté par djano . Évalué à 1.
Oui, il vaut mieux pertinenter la dépêche elle même.
Qu'est ce qu'il se passe dyno, tu as une VDM aujourd'hui?
[^] # Re: Bravo
Posté par Gniarf . Évalué à -1.
non, lui c'est tous les jours...
# Réseau social autour de XMPP
Posté par Olivier Faurax (site web personnel) . Évalué à 9.
Parmi les bonnes choses permises par XMPP, on peut noter Jappix, un réseau social structuré autour du protocole (c'était un client web au départ).
Ils proposent d'ailleurs un truc sympa : Jappix Mini
Ça permet d'ajouter sur un site une petite fenêtre de discussion (style du chat Facebook), idéal pour un site communautaire.
Et c'est libre et décentralisé...
# Il y a XMPP et XMPP par la réalité
Posté par devnewton 🍺 (site web personnel) . Évalué à 10.
Sur le papier, XMPP c'est génial et ça devrait révolutionner nos communications mais dans les faits, on a:
Au final, on se retrouve avec un protocole très complexe pour faire du chat texte tout simple, car c'est la seule chose qui marche bien avec tous les clients/serveurs.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Il y a XMPP et XMPP par la réalité
Posté par Larry Cow . Évalué à 6.
Dans les avatars de Jingle, il y a aussi Jingle Nodes : la toute récente extension de Jingle permettant un fonctionnement "à la Skype" (i.e. en utilisant certains clients comme relais pour les clients coincés derrière le mauvais type de NAT).
C'est d'ores-et-déjà fonctionnel sur SIP Communicator/Jitsi (client multiprocole en Java) et OneTeam (client purement XMPP, multiplateforme et basé sur les technos Mozilla).
J'avais proposé - et suis toujours intéressé par - une vague de tests à grande échelle.
[^] # Re: Il y a XMPP et XMPP par la réalité
Posté par Nÿco (site web personnel) . Évalué à 3.
Quand tu veux, sur OneTeam Desktop on a déjà Jingle et Jingle Nodes sur ICE et bientôt Raw-UDP. Nos tests d'interop sommaires montrent un fonctionnement direct sans déboggage, avec Gajim, Empathy et le client du N900. On peut continuer avec des clients Jingle sur ICE, et sur Raw-UDP quand ce sera prêt.
[^] # Re: Il y a XMPP et XMPP par la réalité
Posté par Larry Cow . Évalué à 3.
Et entre deux OneTeam Desktop, ça marche à tous les coups? En tous cas, c'est chouette et ça a l'air d'avancer vite. Bravo les gars.
(au passage, il y a encore un lien vers les builds instables? je n'arrive plus à le retrouver)
[^] # Re: Il y a XMPP et XMPP par la réalité
Posté par Nÿco (site web personnel) . Évalué à 2.
On a changé de système de build suite au cramage d'une carte mère de serveur. Mais tu peux toujours chopper le code source dans le git : https://git.process-one.net/oneteam
[^] # Re: Il y a XMPP et XMPP par la réalité
Posté par Jehan (site web personnel, Mastodon) . Évalué à 10.
Salut,
je vais répondre aux divers points:
1/ le nom: je suis d'accord, le choix du nom n'est pas terrible pour le grand public, c'est sûr. Mais c'est uniquement un choix "technique" de nom pour un protocole. Cela n'implique pas qu'on souhaite que les utilisateurs se mettent à l'utiliser (pas moi en tous cas).
Les utilisateurs disent-ils "je vais regarder sur le web" ou bien "je vais consulter des pages html par http"? Disent-ils "tiens je t'ai envoyé un email!" ou bien "Je t'ai envoyé un message par smtp, l'as-tu reçu par pop/imap?". Etc.
De manière général, il faut différencier le nom d'un protocole et son utilisation. C'est juste un nom technique (de même que je suis sûr que les voitures ont un nom technique et ridicule avant d'avoir un nom sexy pour passer en publicité, de même pour la plupart des projets!), faut arrêter de se focaliser dessus. Jabber est toujours un très bon nom, utilisable et le nom du serveur publique géré par la XSF s'appelle toujours jabber.org et personne ne parle de changer ce nom.
Pour ma part, je préfèrerais qu'on utilise le nom générique de "messagerie instantanée" et qu'on oublie un instant le nom des protocoles. Avec le travail d'intéropérabilité avec SIP, ça sera d'ailleurs d'autant plus vrai. Qu'importe le protocole derrière, on a une adresse qui permet de discuter, on s'en fiche du reste.
2/ Je suis triste aussi que Facebook ait décidé de ne pas ouvrir ses serveurs, mais ça ne m'étonne pas plus que cela de cette entreprise. Ils ont aussi fermé leur réseau web, tu sais. On ne peut pas regarder les pages Facebook sans compte (moi j'ai jamais pu en tous cas). Ben ils font pareil avec Jabber qu'ils ont fait pour le web. Est-ce que tu vas te plaindre aussi que le web c'est nul parce qu'y a des serveurs fermés comme Facebook?
3/ Les extensions, ce sont comme des RFC, sauf que c'est au niveau de la XSF au lieu de la IETF. Donc on a aussi un protocole de standardisation. Ainsi les extensions commencent avec des statuts expérimentals, elles sont testées, implémentées, modifiées. Et parfois elles passent au stade de standards XSF. Parfois elles sont abandonnées. Parfois certains font leurs extensions dans leur coin pour une utilisation privée (réseau d'entreprise, ou autre) sans intention de standardiser donc de proposer une XEP. Y a de tout.
Encore une fois, va voir combien de brouillons de RFC sont proposés à la IETF, le nombre de brouillons que cela a impliqué (on a 23 brouillons entre la RFC 3920 et 6120, et 21 pour 6121!), et combien passent en standard quand la plupart passent aux oubliettes. Vas-tu dire que la IETF pue parce qu'ils permettent tant de versions expérimentales?
4/ Il n'y a qu'un standard Jingle. Le fameux "Jingle by Google" n'existe pas. Ils ne se sont simplement pas mis à jour encore avec la version standardisée, c'est tout. Mais ils y viendront, comme tout le monde qui veut implémenter la VOIP par XMPP. Ils n'ont aucun intérêt à ne pas le faire.
Je rappelle que c'est Google qui a fait la proposition de Jingle, ils ont donc la plus vieille implémentation expérimentale du protocole. C'est sûr, c'est plus facile quand le protocole existe déjà. Eux, il n'existait pas. Ils ont expérimenté, ont proposé un standard, ça a été étudié, discuté, et on l'a standardisé.
C'est ce que je disais dans l'article: pour l'instant tout le monde a une version de base, plus ou moins complète, basée sur une version plus ou moins expérimentale du protocole selon quand ils ont commencé à implémenter (avant que le protocole soit fixé ou après). On attend donc juste que tout ça se tasse et que les diverses versions se mettent à jour. Ça prend le temps qu'il faut mais ça viendra.
Mais sinon, non: il n'y a qu'un Jingle.
Pour SIP, c'est différent. Y a eu tentative de standardisation de deux protocoles qui à l'origine était finalement assez différents: l'un était vraiment orienté texte (XMPP), l'autre voix (SIP). Au final, avec le temps et les évolutions, les fonctions ont commencé à se recouper puis de plus en plus. Mais c'était trop tard, les deux protocoles étaient déjà standardisés et avaient chacun une grosse masse utilisateur. C'est pas comme si quelqu'un va se mettre à vouloir dire "ok ben finalement on révoque un des deux protocoles". Donc on fait avec et maintenant seul le temps peut nous dire si l'un des deux protocoles va prévaloir ou si les deux vont coexister ainsi pendant encore longtemps.
Et donc faire avec, c'est ce qu'on fait avec les discussions sur l'intéropérabilité entre les deux réseaux (voir la liste de discussion SIXPAC (SIP Interworking with XMPP in Presence Aware Clients) de l'IETF).
Note au final qu'il y a encore un autre cas où plein de technologies très différentes intéropère. Et c'est aussi dans les télécoms, on appelle ça le téléphone! Entre le RTC, d'autres variantes numériques fixes, et une foultitude de protocoles différents pour le mobile (GSM, GPRS, 3D, etc. En veux-tu en voilà)… Ben personne se plaint des téléphones et des protocoles derrière!
Bon bah nous c'est pareil. On arrive pas à rendre les protocoles intéropérables aussi vite que les consortium (ou je ne sais quel type d'organisme) de téléphonie, mais on n'a pas le même argent non plus. Aussi surtout on ne vous demande pas des sommes mirobolantes pour améliorer le système. Mais je trouve qu'on se débrouille quand même bien avec les moyens du bord.
Tu aurais préféré qu'Internet soit un système tout fermé avec des protocoles qu'on paye à prix d'or et géré uniquement par des grosses sociétés?
Voilà pour les divers points.
XMPP n'est pas le protocole parfait. Il a beaucoup de problèmes et il n'y a aucun doute que si les divers acteurs du protocole devait repartir de zéro maintenant, on ferait pas mal de choses différemment. Mais c'est ça le travail de standardisation. On se bat pour faire un système qui convient à tous pour être une norme ouverte, non couverte par des centaines de brevets, et libre d'utilisation pour tous.
Ensuite libre à toi si tu trouves que c'est de la merde et si tu préfères utiliser un réseau fermé qui a sûrement un nom très sexy, des serveurs très ouverts entre eux-même, aucune extension et une technologie son et vidéo intéropérable avec elle-même.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Il y a XMPP et XMPP par la réalité
Posté par devnewton 🍺 (site web personnel) . Évalué à 7.
Tu aurais préféré qu'Internet soit un système tout fermé avec des protocoles qu'on paye à prix d'or et géré uniquement par des grosses sociétés?
Pas du tout, tu remarqueras que jamais je n'ai défendu les protocoles fermés. J'ai fait simplement le bilan objectif de la situation de XMPP pour les différents utilisateurs.
Je ne dis pas non plus qu'il faut tout jeter et recommencer, mais pour moi il est inacceptable en 2011:
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Il y a XMPP et XMPP par la réalité
Posté par Zenitram (site web personnel) . Évalué à 4.
C'est à tous les coups une machination pour faire passer les gens à IPv6 ;-).
Plus sérieusement, aléatoire ou pas, j'ai du mal à comprendre ce que ça change, vu que 99% de la population ne va pas toucher au routeur, il ne fera pas de port forwarding en dur sur le routeur si ça ne marche pas (et comment faire pour deux personnes sur le même accès?), juste remplacera par Skype "qui marche". Quel avantage y a-t-il à avoir des ports non aléatoires hormis pour les quelques rares geeks à aimer configurer un routeur (ce qui pour du grand public comme la messagerie instantanée, n'est clairement pas "vendable")? De mon point de vue, les logiciels doivent toujours trouver un node qui n'a pas de NAT ou utiliser STUN, que le port soit aléatoire ou pas, donc je vois pas trop le gain du port non aléatoire.
[^] # Re: Il y a XMPP et XMPP par la réalité
Posté par devnewton 🍺 (site web personnel) . Évalué à 1.
Quel avantage y a-t-il à avoir des ports non aléatoires hormis pour les quelques rares geeks à aimer configurer un routeur (ce qui pour du grand public comme la messagerie instantanée, n'est clairement pas "vendable")?
Le grand public est tout à fait capable d'ouvrir des ports. Ou alors les joueurs en ligne sont tous des experts en réseau?
De mon point de vue, les logiciels doivent toujours trouver un node qui n'a pas de NAT
Pas terrible pour les perfs audio/video...
utiliser STUN, que le port soit aléatoire ou pas, donc je vois pas trop le gain du port non aléatoire.
C'est michu compliant STUN? Comment ça marche?
donc je vois pas trop le gain du port non aléatoire
Comme presque tout le monde, je suis derrière un routeur. Comment je fais avec des ports aléatoires? J'ouvre tout?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Il y a XMPP et XMPP par la réalité
Posté par Zenitram (site web personnel) . Évalué à 7.
Non. Une partie de geeks fans oui, mais ça n'en fait pas la majorité. La majorité ne sait même pas que leur box est accessible pour la configurer, ils branchent, ça marche, c'est tout ce qu'ils voient.
Skype est très réputé pour sa qualité audio/vidéo (et Steam a même repris la technologie!), et pourtant, tu branche, ça marche, point. Pas d'argot technique comme ce que tu proposes.
Je ne sais pas quels jeux tu joues, ceux que je connais sont click click click pour installer le logiciel (ou Steam), et ça marche. SAns ouvrir de ports du tout.
en:STUN C'est Michu compliant, vu que c'est le logiciel qui fait.
Comment tu fais avec des ports non aléatoires? Tu ne m'a toujours pas donné de réponse, à part un truc pas du tout faisable.
Bref, j'ai posé une question, et la seule réponse que tu me donnes c'est de l'argot technique genre bidouille de routeur, alors que j'ai clairement dit que ce n'était pas une solution acceptable du fait des compétences techniques nécessaire que peu de monde a envie d'apprendre (vu qu'avec d'autres systèmes, certes proprio, ils n'ont pas besoin. Preuve que c'est faisable sans, donc le truc bidule proposé qui marche pas, ben poubelle). Hum.
Je recommence : ça change quoi à part pour quelques gus sachant configurer un routeur (ils sont rares dans la vraie vie. Faut sortir un peu, les gens ne s’embêtent pas à ça quand MSN/Skype/Steam/TeamSpeak et j'en passe y arrivent sans que l'utilisateur doivent apprendre des choses) que ce soit aléatoire ou pas?
[^] # Re: Il y a XMPP et XMPP par la réalité
Posté par devnewton 🍺 (site web personnel) . Évalué à -4.
C'est Michu compliant, vu que c'est le logiciel qui fait
Comment ça marche? C'est en standard dans mon routeur Je dois installer un truc? Demander l'aide du bon dieu?
Comment tu fais avec des ports non aléatoires? Tu ne m'a toujours pas donné de réponse, à part un truc pas du tout faisable
Je choisis un port et je configure mon routeur. Avec des ports aléatoires, je ne sais pas faire.
Faut sortir un peu, les gens ne s’embêtent pas à ça quand MSN/Skype/Steam/TeamSpeak et j'en passe y arrivent sans que l'utilisateur doivent apprendre des choses) que ce soit aléatoire ou pas?
Des logiciels privateurs ont trouvé des feintes de sioux qui marchouille (jamais réussit à faire fonctionner Skype au boulot, on doit avoir un vrai NAT et pas une merde facile à puncher), ça me réjouit. Et sinon je fais comment pour mon XMPP/Jingle?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Il y a XMPP et XMPP par la réalité
Posté par Larry Cow . Évalué à 6.
Comment ça marche? C'est en standard dans mon routeur Je dois installer un truc? Demander l'aide du bon dieu?
Soit ton type de NAT est compatible, et STUN marche "tout seul" (modulo le fait de devoir configurer un serveur STUN, ce dont Jingle Nodes t'exonère), soit ça ne marchera pas du tout. Donc en substance, tu n'as rien à faire.
Et si ça ne te suffit pas comme réponse, tu vas lire (et comprendre)
http://en.wikipedia.org/wiki/Session_Traversal_Utilities_for_NAT
Je choisis un port et je configure mon routeur. Avec des ports aléatoires, je ne sais pas faire.
Avec des ports aléatoires - ou pas - tu n'as pas nécessairement à configurer ton routeur.
Des logiciels privateurs ont trouvé des feintes de sioux qui marchouille (jamais réussit à faire fonctionner Skype au boulot, on doit avoir un vrai NAT et pas une merde facile à puncher), ça me réjouit.
Ce n'est pas limité aux logiciels privateurs. Cf. des solutions comme Teredo (ou son implémentation libre Miredo) ou N2N, qui arrivent très bien à traverser les NATs. Sans parler de Skype, qui n'a jamais demandé à personne d'ouvrir son NAT.
Ceci étant, ta vision est assez typique du flou qui entoure généralement le NAT. Un NAT ne bloque rien. Il effectue une traduction d'adresse qui rend - en pratique - les machines internes relativement inaccessibles. Mais ce n'est pas nécessairement un firewall. La preuve, sans (vrai) firewall, Skype arrive toujours très bien à sortir - y compris dans des cas où je n'ai toujours pas compris par où il était passé.
Et sinon je fais comment pour mon XMPP/Jingle?
Tu choisis un logiciel compatible Jingle (et éventuellement compatibles Jingle Nodes), et tu essayes. Pour de vrai. Parce que pour Mme Michu, si ça marche seulement en ouvrant son routeur, c'est exactement comme si ça ne marchait pas.
Donc soit ça fonctionne "tout seul" (j'ai eu de bons résultats avec PSI, mais l'interface d'appel est assez rebutante), soit tu peux commencer à râler/inspecter ton réseau et celui de ton correspondant et/ou chier sur Jingle.
[^] # Re: Il y a XMPP et XMPP par la réalité
Posté par devnewton 🍺 (site web personnel) . Évalué à -3.
In many application scenarios it is common that both endpoints are located behind a NAT. This double-NAT problem is often not easily overcome even with STUN and sometimes an intermediate application proxy server is required.
Super, STUN ne marche pas dans le cas commun.
Tu choisis un logiciel compatible Jingle (et éventuellement compatibles Jingle Nodes), et tu essayes
J'ai essayé, ça ne marche pas.
Donc soit ça fonctionne "tout seul" (j'ai eu de bons résultats avec PSI, mais l'interface d'appel est assez rebutante), soit tu peux commencer à râler/inspecter ton réseau et celui de ton correspondant et/ou chier sur Jingle
Donc ta solution "michu compliant plus facile que l'ouverture de port", c'est d'inspecter mon réseau??? Et je cherche quoi sur mon réseau?
Avec un port fixe, je pourrais faire un test simple sur ma machine et conseiller mon correspondant. BREF J'AURAIS UNE SOLUTION.
Avec des ports aléatoires, je ne sais pas quoi faire.
Vraiment.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Il y a XMPP et XMPP par la réalité
Posté par Zenitram (site web personnel) . Évalué à 1.
L'idée d'un port fixe ne marche pas dans le cas commun non plus. Ex-aequo.
Ah bon? Tu es sûr que ton correspondant comprendra la langue dans laquelle tu essayes du lui parler à coup de routeur, port etc??? Tu pourras t'aider toi sur tes équipement, tu ne pourras rien faire pour l'autre, à moins que tu connaisses les interfaces utilisateur de tous les routeurs sur terre...
[^] # Re: Il y a XMPP et XMPP par la réalité
Posté par devnewton 🍺 (site web personnel) . Évalué à -1.
L'idée d'un port fixe ne marche pas dans le cas commun non plus. Ex-aequo
Si, ça marche. Il suffit de configurer. C'est chiant, mais ça offre une possibilité.
Tu es sûr que ton correspondant comprendra la langue dans laquelle tu essayes du lui parler à coup de routeur, port etc???
Oui, je peux lui expliquer ou venir faire le réglage. Bref j'ai un moyen, pénible certes, de m'en sortir.
Entre "ça ne marche pas du tout" et "c'est compliqué", pourquoi choisir le premier?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Il y a XMPP et XMPP par la réalité
Posté par Zenitram (site web personnel) . Évalué à 3.
Parce qu'en face, chez la concurrence, "ça marche et c'est simple (c'est transparent en fait, rien à faire)", donc développer comme tu demandes un truc juste pour passer de "ça marche pas" à "c'est compliqué", je trouve (mais effectivement, c'est qu'un avis perso) que c'est une étape qui n'est qu'une perte de temps pour les développeurs. Autant que les développeurs passent à l'étape suivante directement.
La, de toutes façons ça ne marche pas (pas de ports non aléatoire), donc ta solution ne marche pas, et tu demandes aux autres de développer pour résoudre un problème qui ne concerne que toi ou presque, ça me fait juste un peu bizarre. Surtout qu'il y a ici une tonne de monde bien compétant à priori qui essaye de voir pourquoi la solution "simple" ne marche pas, ça me parait plus constructif à long terme.
Faudrait donc penser à oublier la partie "changez votre protocole et les logiciels pour mes besoins uniquement" pour voir pourquoi la partie plus générique ne marche pas chez toi.
[^] # Re: Il y a XMPP et XMPP par la réalité
Posté par devnewton 🍺 (site web personnel) . Évalué à 0.
Depuis le début, tu supposes que rediriger un port, c'est la chose la plus complexe du monde. Cette affirmation est FAUSSE. Des joueurs du monde entier savent le faire. Soit parce que les jeux le demandent (et le permettent au lieu d'attendre 10 ans la super techno de LAN traversal qui tue), soit pour un usage proche: installer un serveur TeamSpeak par exemple.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Il y a XMPP et XMPP par la réalité
Posté par Maclag . Évalué à 10.
Non, il ne te dit pas que c'est la chose la plus compliquée du monde, il essaie de te dire que pour 99% des gens, ce n'est pas simple!
Relis-toi et explique-moi ce qui aura le plus de succès parmi les 3:
J'explique à mes parents comment télécharger le logiciel client, "configurer" le "routeur" (à ce stade, ils ont raccroché et veulent me rappeler parce qu'il y a certainement des fritures sur la ligne, ils ne comprennent pas ce que je dis du tout)
Sinon c'est pas grave, je n'ai qu'à aller chez mes parents pour aller le faire moi-même. J'habite en Chine et eux en France, ça fera 3 jours et 2000€ d'aller-retour la configuration...
Je pourrais aussi demander à quelqu'un d'autre d'y aller, mais vu que je n'évolue pas dans un monde d'informaticien, je ne connais PERSONNE capable d'aider mes parents dans leur région, et même si j'avais de vagues connaissances capables de le faire, ça me semblerait aberrant de leur demander une intervention technique sur place pour faire de la VOIP en 2011!
Je leur envoie un e-mail avec un lien vers "Télécharger Skype". Le jour même nous nous parlons avec la caméra branchée et ils peuvent voir leur petite-fille pour la première fois en vidéo.
Maintenant, réfléchis un peu: - population capable de configurer un routeur? (on rappelle que la population française branchée sur Internet n'est pas faite que d'informaticien, gros joueur ou même "vachement intéressé" par l'informatique - population capable de cliquer sur Suivant-Suivant-Suivant-OK?
Si on prend en compte que la population capable de configurer un routeur devrait également être capable de cliquer sur Suivant plusieurs fois, ce que te dit Zenitram, c'est qu'au lieu de se torturer les méninges au sujet des ports non-aléatoires, les dévs feraient bien mieux de se torturer les méninges pour que l'utilisateur n'entende jamais parler de "port" ni de "routeur", et le moins possible de "configuration".
[^] # Re: Il y a XMPP et XMPP par la réalité
Posté par Zenitram (site web personnel) . Évalué à 4.
Merci. Des fois sur LinuxFr j'ai l'impression d'être dans un monde parallèle, avec des gens qui n'ont jamais vu autre chose qu'un passionné (ou amateur) d'informatique dans leur vie. On comprend alors largement pourquoi Skype a bien plus de succès que Jabber dans la vraie vie...
[^] # Re: Il y a XMPP et XMPP par la réalité
Posté par zebra3 . Évalué à 7.
Pas d'accord.
Ma mère fait de l'informatique depuis avant ma naissance, elle a débuté sous DOS, elle se débrouille avec Ubuntu qu'elle a installé elle-même. Et pourtant elle ne saurait pas faire d'elle-même ce que tu proposes, parce qu'elle a beau connaître les bases de l'informatique, elle n'y connait rien en réseau.
Alors je n'ose pas imaginer le reste du grand public.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Il y a XMPP et XMPP par la réalité
Posté par Zenitram (site web personnel) . Évalué à 2.
https://linuxfr.org/nodes/85429/comments/1221577
Tu peux aussi lire le lien que j'ai fourni précédemment.
Fail. Tu parles pour toi, qui sait ce qu'est un routeur, un port, du port forwarding. Sors juste en bas de chez toi, demande aux passant si ils connaissent, et conclue sur la faisabilité de la chose.
Donc sans port aléatoire, la majorité de la population ne sait pas faire non plus, merci j'ai la confirmation de ce que j'imaginais : ça résout des problèmes pour une minorité de geeks, pour le reste ça ne résout rien, donc pas d'urgence, il y a bien plus urgent que de faire plaisir à quelques geeks.
On ne s’intéresse pas à la même chose : ce qui m’intéresse, c'est d'avoir un protocole "vendable" à plein de monde, tu t’intéresses à des problèmes pour un très petite partie de la population, dans ton coin. Alors forcément ta solution de fixer les ports ne m'est d'aucune utilité, elle ne sert qu'à toi, c'est tout, elle ne sert pas aux gens de manière générale. Pourquoi changer une chose pour que ça serve à que quelques personnes? Pourquoi ne pas trouver une solution qui marche partout à la place? Ta solution "port fixe" n'est pas une solution acceptable pour un protocole destiné à être utilisé par les gens, de manière générale (genre un logiciel de messagerie instantanée)
[^] # Re: Il y a XMPP et XMPP par la réalité
Posté par devnewton 🍺 (site web personnel) . Évalué à -1.
Fail. Tu parles pour toi, qui sait ce qu'est un routeur, un port, du port forwarding. Sors juste en bas de chez toi, demande aux passant si ils connaissent, et conclue sur la faisabilité de la chose.
Ta solution "port fixe" n'est pas une solution acceptable pour un protocole destiné à être utilisé par les gens, de manière générale (genre un logiciel de messagerie instantanée)
Je suis d'accord, ce n'est pas le mieux, mais au moins je sais quoi faire. Là je me retrouve devant XMPP/Jingle qui ne marche pas.
Et personne ici ne propose une solution.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Il y a XMPP et XMPP par la réalité
Posté par Larry Cow . Évalué à 4.
Et personne ici ne propose une solution.
Ok, tu veux une solution? Pour de vrai, pas juste pour troller?
Bah utilises SIP, au moins les ports sont fixes. De rien, bisous.
[^] # Re: Il y a XMPP et XMPP par la réalité
Posté par devnewton 🍺 (site web personnel) . Évalué à -3.
Je ne suis pas en train de troller! Je cherche vraiment une solution pour utiliser ma webcam sans avoir à recourir à un logiciel privateur. J'essayerai SIP, j'espère que ça va marcher, même si je regrette de devoir abandonner XMPP dans ce cas...
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Il y a XMPP et XMPP par la réalité
Posté par Larry Cow . Évalué à 2.
Non, tu ne regrettes pas vraiment de devoir abandonner XMPP : tu nous expliques depuis hier que leurs choix technologiques en termes de VV sont mauvais, voire abérants. De toute évidence, il te tient à coeur de nous expliquer combien les gens derrière XMPP sont des ahuris... ne va pas nous faire croire que c'est à ton corps défendant.
[^] # Re: Il y a XMPP et XMPP par la réalité
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Qui aime bien, châtie bien!
Il ne faut pas prendre pour une attaque personnelle ce qui n'est qu'un simple état des lieux.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Il y a XMPP et XMPP par la réalité
Posté par Larry Cow . Évalué à 2.
L'état des lieux, ça consiste à regarder ce qui existe. Pas à refuser de regarder ce qu'on ne comprend pas (encore).
[^] # Re: Il y a XMPP et XMPP par la réalité
Posté par devnewton 🍺 (site web personnel) . Évalué à -2.
Je ne refuse pas les stuns et compagnie, je dis juste que si je pouvais fixer les ports, j'aurais une solution autre que "teste plusieurs logiciels et plusieurs configurations".
Bien sûr les développeurs de XMPP sont libres de ne pas prendre en compte ce genre de suggestion et d'attendre des lendemains qui chantent où on courra tous à poil dans l'herbe en IPV6 sans NAT, mais je trouve ça dommage.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Il y a XMPP et XMPP par la réalité
Posté par Nonolapéro . Évalué à 2.
Un serveur STUN c'est une case à remplir dans la configuration du logiciel c'est tout de même plus simple que d'aller trifouiller les ports d'un routeur.
[^] # Re: Il y a XMPP et XMPP par la réalité
Posté par Zenitram (site web personnel) . Évalué à 3.
Si c'est bien fait, cette case est pré-remplie, encore plus simple (rien à faire)
[^] # Re: Il y a XMPP et XMPP par la réalité
Posté par Zenitram (site web personnel) . Évalué à 1.
Je te cite :
C'est tout à fait acceptable (ou plutôt, que ce soit fait comme tu le demandes ne change rien donc pourquoi changer? Juste pour toi parce que tu demandes?), vu qu'utiliser des ports non aléatoires ne résout absolument rien, ou du moins tu ne m'a toujours pas dit en quoi ça résoudrait quelque chose à part pour quelques rares exceptions, qui je l'avoue ne sont pas ce qui m’intéresse pour un déploiement à grande échelle d'une technologie.
On ne se comprend pas, sûrement parce que je m’intéresse à un possible déploiement à grande échelle et posais la question pour savoir ce que ça aiderait à grande échelle, alors que tu regardes ta problématique uniquement.
[^] # Re: Il y a XMPP et XMPP par la réalité
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
Non. Passer par des relais, c'est ce que fait Skype, et il suffit pour que ça marche d'avoir un relais qui a déjà transpercé son NAT éventuel.
[^] # Re: Il y a XMPP et XMPP par la réalité
Posté par devnewton 🍺 (site web personnel) . Évalué à 5.
Passer par des relais, ça implique une grosse perte de perf, non?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Il y a XMPP et XMPP par la réalité
Posté par claudex . Évalué à 3.
Pas si tu distribue et/ou utilise des relais avec beaucoup de débit.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Il y a XMPP et XMPP par la réalité
Posté par devnewton 🍺 (site web personnel) . Évalué à 0.
Donc seule une grand entreprise peut gérer ça...
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Il y a XMPP et XMPP par la réalité
Posté par Nÿco (site web personnel) . Évalué à 2.
D'où l'intérêt des supernodes Skype, et des mega-supernodes dans le cas ou tout un pan du réseau de supernodes se vautre misérablement comme ce fût le cas en décembre 2010.
[^] # Re: Il y a XMPP et XMPP par la réalité
Posté par Larry Cow . Évalué à 3.
Pas nécessairement, on parle de voix là. Bien compressée, avec un relais pas trop "loin", ça ne se sent pas trop. D'autant que ça reste théoriquement un cas extrême (les deux bouts de la communication sont tous deux derrière des NATs incompatibles).
[^] # Re: Il y a XMPP et XMPP par la réalité
Posté par Nÿco (site web personnel) . Évalué à 3.
Quand les deux peers sont derrière des NAT (la plupart des cas), tu es juste obligé de passer par un relai public. Si le débit disponible de bout en bout ne te permet pas de faire de la voix/vidéo bah tu vas t'en rendre compte.
[^] # Re: Il y a XMPP et XMPP par la réalité
Posté par Batchyx . Évalué à 3.
Bien sûr qu'il y a une grosse perte de perf. Chez mes parents les coms skype sont super moche avec plein de coupures/déconnexions si je ne configure pas le routeur et skype. Alors parler de logiciel qui marche en cliquant sur suivant/suivant c'est de la grosse blague, on fini bien souvent les appels avec un téléphone classique.
Faudra pas me dire que le traversal de nat non-coopératif n'est pas un mode dégradé.
[^] # Re: Il y a XMPP et XMPP par la réalité
Posté par Nÿco (site web personnel) . Évalué à 2.
STUN, puis TURN, en résumé ICE.
[^] # Re: Il y a XMPP et XMPP par la réalité
Posté par barmic . Évalué à 1.
C'est une situation transitoire.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Il y a XMPP et XMPP par la réalité
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
C'est une situation transitoire
Qui va durer 10 ans?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Il y a XMPP et XMPP par la réalité
Posté par Nÿco (site web personnel) . Évalué à 1.
Jingle utilise le port standard 5222 par défaut.
C'est sans doute le standard ouvert RTP - celui également utilisé par SIP - que tu souhaites critiquer ?
[^] # Re: Il y a XMPP et XMPP par la réalité
Posté par devnewton 🍺 (site web personnel) . Évalué à 0.
Tu as un lien vers une doc là dessus? Ca m'intéresse vraiment de savoir!
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Il y a XMPP et XMPP par la réalité
Posté par Nÿco (site web personnel) . Évalué à 1.
[^] # Re: Il y a XMPP et XMPP par la réalité
Posté par devnewton 🍺 (site web personnel) . Évalué à 0.
Heu c'est où la référence au port 5222?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Il y a XMPP et XMPP par la réalité
Posté par Nÿco (site web personnel) . Évalué à 1.
Les ports et IANA, toussa... Sinon tu as le droit de lire les liens de la news.
[^] # Re: Il y a XMPP et XMPP par la réalité
Posté par Misc (site web personnel) . Évalué à 4.
Ceci dit, c'est un des paradoxes de l'ouverture. Personne ( à part les ingénieurs en charge ) ne sait que les téléphones, c'est si compliqué, donc personne ne fait de remarque. Alors qu'avec un systéme ouvert, tout le monde peut voir ce qu'il est et tout le monde peut donner son opinion.
[^] # Re: Il y a XMPP et XMPP par la réalité
Posté par Zenitram (site web personnel) . Évalué à 1.
Mais est-ce vraiment utile tout ce bruit?
Je m'explique : les téléphones, "personne" ne sait comment ça marche, mais... Ca marche! à la place de discuter, on développe, et l'utilisateur peut utiliser, et ne se pose pas de questions, ça marche, c'est déployé avec des taux de pénétration parfois supérieur à 100%.
XMPP, cool on peut voir et donner son opinion, mais bon, au final ça ne marche pas, ça ne se déploie pas tant que ça par rapport à la concurrence (certes c'est utilisé par Facebook, mais bon, c'est en circuit fermé, ça peut être XMPP aujourd'hui, autre chose demain. Ailleurs, mouais, ça doit taper dans les 1% du marché de la messagerie instantanée, même GTalk n'est pas très utilisé alors que c'est poussé par Google). Et l'audio/vidéo, n'est parlons pas, Skype écrase tout.
Perso, j'aime les trucs qui marchent, en tant qu'utilisateur je préfère les normes GSM, GPRS, UMTS etc... Il y a un sacré problème entre les besoins des utilisateurs et les normes, bon ça fait plaisir de voir que ça évolue (gestion des NAT etc...), mais c'est lent, et l'utilisateur a tout le temps pour s'habituer à Skype...
# TLS external
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
Je n'ai pas trouvé de description de ce « TLS external ». De quoi s'agit-il au juste ? À la lecture de cette dépêche j'ai l'impression que c'est la le changement le plus important, et de très loin.
[^] # Re: TLS external
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 7.
Bon, renseignements pris, TLS external ça n'existe pas, il s'agit de TLS + SASL EXTERNAL.
S2S dialback est un mécanisme permettant à un serveur recevant une connexion de la part d'un autre de vérifier que celui-ci est joignable au nom de domaine qu'il prétend représenter :
example.com;example.com— qui est normalement le serveur 1, ou en relation avec lui dans le cas d'un service rendu par plusieurs serveurs en lien — et y envoie un identifiant secret ;Ce système est inspiré d'une précaution qu'on peut prendre au téléphone, quand on reçoit un appel d'un inconnu :
SASL EXTERNAL maintenant, c'est un pseudo-mécanisme d'identification, qui indique que l'identification a en fait déjà été faite par un autre moyen, ici TLS. En gros ça doit donner quelque chose comme :
Donc ça n'a strictement rien à voir avec S2S dialback, puisque ça ne répond pas au même problème. S2S dialback, ça fait implicitement confiance au réseau et ça permet de vérifier la responsabilité d'un nom de domaine : quelqu'un me contacte en se présentant comme
example.com, est-ce qu'il est vraiment joignable à ce nom-là ou est-ce que c'est un sale spammeur qui ne prend pas la responsabilité de ce qu'il envoie ? SASL EXTERNAL, ça ne sert à rien en tant que tel, ça délègue tout à TLS qui permet de vérifier l'identité d'un nom de domaine, pas sa responsabilité : quelqu'un me contacte en se présentant commeexample.com, est-ce que c'est vraimentexample.com— qui pourra tout à fait être malgré tout un spammeur irresponsable ?Soit dit en passant, je ne comprends pas l'intérêt de SASL EXTERNAL. TLS, ok, ça sert, mais à quoi cela peut-il bien servir pour un serveur d'exiger que son correspondant fasse semblant de s'identifier avec un mécanisme qui indique juste que c'est déjà fait ? Comme la session TLS est déjà établie, si ça ne lui convient pas il a déjà eu l'occasion de la refuser…
[^] # Re: TLS external
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
Dans la vraie vie, TLS + SASL EXTERNAL ça donnerait quelque chose comme ça :
Les trois dernières étapes ont l'air parfaitement surréalistes et inutiles… :-)
[^] # Re: TLS external
Posté par Misc (site web personnel) . Évalué à 2.
En pratique, c'est deja utilisé par ldap. En utilisant ça, tu peux dire "si ça vient de la socket dans /var:lib, alors tu donnes tel droit". Charge à l'admin de configurer correctement la socket en question ( via par exemple des permissions unix ). C'est vrai, c'est pas trés sécurisé quand tu te branches sur un réseau no sécurisé.
Mais je vois plein d'avantages comme permettre de faire des tests plus facilement, faire des comptes limités ( exemple, un compte qui sert juste à envoyer des alertes nagios ), ou permettre d'echanger des messages entre X noeuds d'un cluster. Pour de la messagerie classique sur internet, oui ç'est limité, mais ça ouvre des portes pour le reste.
[^] # Re: TLS external
Posté par Jehan (site web personnel, Mastodon) . Évalué à 1.
Salut,
désolé, j'avais commencé à répondre, puis j'ai fait autre chose à côté et quand je suis revenu sur ma réponse et l'ai publiée, je vois que tu t'es auto-répondu!
Donc voilà, c'est une question de définition. Avoir des automatismes permet de rendre l'implémentation plus facile. Si on se met à dire « ah oui mais "ceci" sert à X, mais parfois à Y en même temps, et des fois — mais c'est rare! — ça sert juste à Y mais pas à X », ça rend les choses compliqué. Donc nous, on a un automatisme: on identifie les diverses entités du réseau avec SASL. À partir de là, il nous faut choisir un mécanisme SASL pour identifier deux serveurs. Bah ça tombe bien, y a external fait justement pour ce genre de cas!
C'est un peu comme les fonctionnalités à négocier lors de la création d'une connexion. Avant dans la RFC3920, c'était un gros bordel. C'était en gros "ben on peut un peu envoyer des nouvelles fonctionnalités à tout moment, et des fois, on peut ne pas les envoyer, c'est un peu comme on veut hein, ici c'est à la bonne franquette!". Quand j'ai commencé à implémenter ça, je me suis dit que c'était nul. Y avait aucune fiabilité dans cette logique, que des cas particuliers. J'ai donc relevé le problème, on en a discuté et on a maintenant un beau diagramme d'état avec des explications précises de ce qu'il faut envoyer, et quand. Et maintenant c'est facile à implémenter.
Ce genre de design ne peut impliquer sur le long terme que bug et incompatibilité entre systèmes poppant de temps en temps.
Ben là pour SASL EXTERNAL, je n'étais pas là quand ça a été décidé donc je ne peux assurer que c'est la raison exacte pour laquelle c'est là, mais dans mon esprit, c'est la même chose. Ça permet un système logique et fiable.
Et donc si au final, SASL external et Dialback ont tout à voir. Ils ont tous les deux pour but d'identifier des serveurs quand ils communiquent ensemble. Sauf que la vieille méthode le faisait avec un système à part basé sur le DNS et donc était totalement bancal. Le nouveau est un mécanisme SASL (qui encapsule certes le protocol TLS) permettant d'homogénéiser l'identification en S2S et C2S: tout SASL, quel que soit le type d'identité.
En fait faut voir SASL EXTERNAL comme une encapsulation de code qui rend le code plus haut niveau bien plus lisible et donc exempt de bug. Si tu es développeur, tu comprendras de quoi je parle.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: TLS external
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
Non. Avec TLS + SASL external, tu as une preuve que le serveur qui te contacte a bien le droit de porter le nom qu'il annonce, et c'est tout. Ça ne l'empêche pas d'envoyer du spam sans en prendre le responsabilité, c'est à dire sans permettre qu'on le contacte pour répondre.
Avec dialback, pour pouvoir émettre on doit être joignable dans l'autre sens.
[^] # Re: TLS external => SASL external
Posté par Jehan (site web personnel, Mastodon) . Évalué à 2.
Salut,
vraiment désolé, je me suis emmêlé les pinceaux, et pourtant j'ai pas mal relu! Il s'agit de SASL external (c'est le protocole SASL qui gère l'identification). C'est le seul mécanisme décrit dans la RFC de base de SASL. Si on pouvait corriger la dépêche sur ce point svp!
En fait le principe de ce mécanisme est très simple. Il s'agit de dire "on s'est déjà identifié précédemment, tu te rappelles pas?". Cela implique une décision au niveau du protocole applicatif d'un autre moyen de s'identifier (SASL external est le plus générique des mécanismes et n'a aucun sens sans contexte). Dans le cas de XMPP, en S2S, nous nous reposons sur l'identification TLS.
Pour ceux qui ne savent pas comment marche TLS, il y a une partie vérification de l'identité d'un correspondant, avec les fameux certificats. Mais comme les certificats, c'est un concept difficile pour le grand public (= chiant, ils veulent juste un mot de passe, et basta! C'est parti mon kiki!), seul l'identité du serveur est vérifiée. C'est ce que fait aussi http avec https, sauf que nous, on rend ça obligatoire (ça veut pas dire que tous le font réellement malheureusement, mais ça veut dire qu'on dit aux développeurs de serveurs: si vous le faites pas, vous n'êtes pas une implémentation complète).
Or en S2S, c'est deux serveurs, donc normalement chacun doit avoir un certificat. Donc on est capable de créer une liaison TLS vérifiée des deux côtés. À partir de ce moment là, quand arrive le moment de l'identification, on peut dire "ah bah on fait, on se connaît déjà".
En gros donc, SASL external, pour le S2S XMPP, ça signifie juste (parce que c'est la définition qu'on a donnée) utiliser 2 certificats en TLS.
Et ça c'est autrement plus sécurisé que le protocole originel (à vrai dire, c'est ce qu'il y a de plus sécurisé dans ce genre de communications. Je parle bien sûr de notre contexte précis avec deux serveurs qui se connaissent pas outre mesure et qui ont cependant besoin de s'identifier et de crypter les communications, et aussi on fait avec les limites de TLS que nous connaissons tous ici car on arrive pas encore à trouver un meilleur système, du moins pas sur lequel tout le monde est d'accord).
Pour rappel, le Dialback, le principe c'était juste qu'on identifiait le serveur qui nous appelait en créant une second connexion dans l'autre sens et où on dit "c'est bien toi qui m'a appelé à l'instant et qui m'a dit ça?", ce qui rend très facile de se faire passer pour un autre serveur avec du DNS poisoning ou d'autres méthodes similaires.
NOTE: le SASL external peut théoriquement aussi être utilisé en C2S avec une clé cliente. Mais je sais pas si beaucoup de serveurs utilisent un tel système (peut-être sur des réseaux d'entreprises où on veut se passer de mot de passe?).
Je crois que c'est aussi utilisé par Google en C2S lorsqu'on est dans l'interface web gmail. Dans ce cas là, le SASL external, c'est "on s'est identifié quand on s'est identifié à l'email, pas la peine de le refaire pour XMPP!". Comme je disais, tout est une question de définition par le protocole applicatif.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
# Salut à Toi
Posté par Goffi (site web personnel, Mastodon) . Évalué à 3.
Super dépêche, merci.
J'en profite pour laisser une note sur mon projet: Salut à Toi ( http://wiki.goffi.org/wiki/Salut_%C3%A0_Toi ), qui permet d'avoir plusieurs interface (desktop, console, ligne de commange, etc), et quelques trucs sympas comme utiliser son client courriel pour lire les messages ( http://www.goffi.org/post/2011/01/18/Recevez-et-envoyez-vos-messages-XMPP/Jabber-avec-votre-lecteur-de-courriel-gr%C3%A2ce-%C3%A0-Salut-%C3%A0-Toi-! ) .
J'ai une grosse version en préparation, et j'espère pouvoir publier une dépêche à ce sujet d'ici quelques jours/semaines :)
[^] # Re: Salut à Toi
Posté par Jehan (site web personnel, Mastodon) . Évalué à 1.
Salut à toi aussi! ;-)
Bien que n'ayant jamais testé ton projet, j'avais vu tes divers journaux que tu avais fait dessus, et en fait tu m'avais presque énervé, parce que t'as plein d'idées très similaires aux miennes. ;-)
Quoiqu'il en soit, si ton projet est suffisamment avancé pour être utilisable (parce qu'y a quand même une sélection, on ne peut laisser n'importe quel projet inexistant prendre la place de projet solides) et que tu souhaites aller encore plus loin, tu peux probablement proposer une idée (ou plusieurs même) de projet impliquant SaT, pour lesquels tu pourrais être mentor. Donc SaT pourrait participer au Google Summer of Code sous la tutelle de la XSF. Jette donc un œil au lien donné plus haut.
Bonne continuation!
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Salut à Toi
Posté par Goffi (site web personnel, Mastodon) . Évalué à 3.
Je pense que le projet est encore trop jeune et pas assez solide pour ça, l'année prochaine peut être, mais merci de la proposition :).
En clair, il n'est pas encore utilisable comme client principal, de nombreuses choses sont implémentées partiellement, et ça manque de test. Mais je travaille dessus, et la situation s'améliore de jour en jours. J'espère que la prochaine version amènera plus de retour et quelques devs...
[^] # Re: Salut à Toi
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
J'aime beaucoup l'idée de pouvoir gérer ses messages via un client mail, mais si j'ai bien compris "Salut à Toi" est un client XMPP. Est-ce que ça ne serait pas plus logique d'implémenter d'ajouter le support d'IMAP à un serveur XMPP existant?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Salut à Toi
Posté par Goffi (site web personnel, Mastodon) . Évalué à 2.
Oui et non, le problème peut être géré à différents endroits.
Un serveur imap est un serveur de plus à gérer, ce qui implique des complications au niveau sécurité, des ports à ouvrir, la gestion des utilisateurs, etc. Là c'est fait au niveau local, tu peux ne laisser ton serveur accessible qu'en local pour ton client courriel, c'est plus simple et sûr. D'autre part, ça n'implique pas de complication si tu as un accès restreint au net: du moment que XMPP passe, ça fonctionne.
J'utilise aussi SàT comme un terrain d'expérimentation pour les idées que j'ai en tête, et là j'ai pu implémenter ça rapidement, sans attendre la publication d'une XEP et l'implémentation dans un serveur. Rien n'empêche de faire de même côté serveur par la suite.
En fait j'avais déjà répondu à cette question dans mon blog (dont le lien donné plus haut), et j'y explique également pourquoi xmpp peut avantageusement remplacer le courriel.
[^] # Re: Salut à Toi
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Là c'est fait au niveau local, tu peux ne laisser ton serveur accessible qu'en local pour ton client courriel, c'est plus simple et sûr
Si j'installe mon propre serveur imap, pourquoi je ne ferais pas de même pour mon serveur XMPP?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Salut à Toi
Posté par Goffi (site web personnel, Mastodon) . Évalué à 2.
C'est SàT qui gère le serveur imap, c'est une extension, tu n'as rien à faire à part configurer ton client courriel.
# Juste pour s'échanger des commérages !
Posté par Salim . Évalué à 2.
Excellente dépêche en effet, j'ai tout lu, même les paragraphes "rébarbatifs" !
Heureux de tomber sur des experts Jabber, car là ou mon serveur OpenFire me permet de chatter sans encombres avec mes contacts, je n'ai toujours pas de solution voix.
J'ai essayé plusieurs trucs, mais de rien de satisfaisant..
Connaissez-vous une solution Jingle fiable ? Je veux simplement parler avec ma sœur, et pas gérer un parc d'utilisateurs pro ! Une solution minimaliste P2P existe-t-elle ?
Juste pour causer sans se prendre la tête, entre PCs NATtés.
Merci.
[^] # Re: Juste pour s'échanger des commérages !
Posté par Adrien . Évalué à 1.
idem, je suis très très preneur de solution… pour l'instant il n'y a que skype qui passent à peut près partout :-(
[^] # Re: Juste pour s'échanger des commérages !
Posté par Larry Cow . Évalué à 2.
Essayez OneTeam ou SIP Communicator, ils sont normalement faits pour se rire des NATs.
[^] # Re: Juste pour s'échanger des commérages !
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Comment font-ils?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Juste pour s'échanger des commérages !
Posté par Larry Cow . Évalué à 10.
Jingle, ça fonctionne déjà malgré les NATs, grâce à la technique du "hole-punching". En gros, à condition d'avoir une troisième machine totalement démunie de NAT et dévouée à cette tâche, deux machines "masquées" par un NAT chacune peuvent établir une liaison bidirectionnelle directe en UDP. Ca a juste quelques inconvénients :
La technique de traversée de NAT "directe" est formalisée sous le nom de STUN. Pour plus de robustesse, on lui adjoint généralement TURN - une formalisation du principe de "relais", pour une traversée "indirecte" du NAT. Et pour rendre tout ça "simple", on a formalisé une méthodologie qui indique quelles techniques employer dans quel ordre : ICE.
Jingle (de base) s'appuie sur ICE pour mettre en place son canal de communication.
Des gens ont également proposé une XEP pour permettre de mieux supporter les cas pourris (pas de serveur disponible pour faire du TURN ni du STUN). Cette XEP utilise l'approche qui a rendu Skype célèbre, en l'adaptant à la sauce XMPP : se servir des (rares) clients qui n'ont PAS à souffrir des méfaits du NAT pour fournir les fonctions de TURN et STUN aux autres. Et, tant qu'à bien faire, essayer de calquer ça sur le roster de l'utilisateur (qu'on ne se retrouve pas à perdre de la BP pour la conversation de deux mecs qu'on ne connaît ni d'Eve ni d'Adam).
Cette amélioration de Jingle, elle porte le nom de "Jingle Nodes", et elle est actuellement implémentée par (au moins) deux clients libres : OneTeam et Jitsi (anciennement SIP Communicator).
C'est mieux, comme ça? ;)
[^] # Re: Juste pour s'échanger des commérages !
Posté par devnewton 🍺 (site web personnel) . Évalué à 0.
C'est mieux, comme ça? ;)
Je comprends mieux! Je comprends aussi que c'est pas demain la veille que ça va marcher au poil :-(
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Juste pour s'échanger des commérages !
Posté par Nÿco (site web personnel) . Évalué à 1.
Tu vas avoir du mal avec SIP Communicator (Jitsi), car il n'implémente pas ICE. Préférer OneTeam Desktop.
[^] # Re: Juste pour s'échanger des commérages !
Posté par devnewton 🍺 (site web personnel) . Évalué à -5.
Connaissez-vous une solution Jingle fiable ?
Si c'est fiable, mais il te faut une IPV6 et un bac+5 en système réseaux parce que quelques gus ont décidé d'utiliser des ports dynamiques.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Juste pour s'échanger des commérages !
Posté par Larry Cow . Évalué à 3.
Tu ne serais pas légèrement monomaniaque? Tu lis, quand les gens te répondent, ou bien tu te contente de répéter la même ânerie jusqu'à l'agonie?
[^] # Re: Juste pour s'échanger des commérages !
Posté par devnewton 🍺 (site web personnel) . Évalué à -2.
Ok je veux bien vous écouter. Voici la situation:
Je suis derrière NAT. Mon correspondant aussi. Ca ne marche pas.
Qu'est-ce que je dois faire?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Juste pour s'échanger des commérages !
Posté par Larry Cow . Évalué à 3.
Ça ne marche pas avec quel(s) logiciel(s)?
[^] # Re: Juste pour s'échanger des commérages !
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Empathy.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Juste pour s'échanger des commérages !
Posté par Larry Cow . Évalué à 3.
Essaye donc avec un logiciel qui gère Jingle Nodes, comme je te le recommande depuis le début.
Avec les autres, il faut régler un serveur STUN (plus simple que d'ouvrir un port sur un routeur, tu mets "stun.ekiga.net" - par ex. - des deux côtés et on en parle plus). Après, ça peut merder quand même, mais mets au moins toutes les chances de ton côté.
[^] # Re: Juste pour s'échanger des commérages !
Posté par devnewton 🍺 (site web personnel) . Évalué à -3.
Je n'ai toujours pas bien compris à quoi sert ce STUN. S'il n'y aucun port de redirigé, comment va-t-il faire pour établir une connexion directe entre les deux correspondants?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Juste pour s'échanger des commérages !
Posté par Larry Cow . Évalué à 3.
Tu as pris le temps de lire les liens qu'on t'a filé (notamment le lien Wikipedia que je t'ai mis concernant STUN)? Parce que c'est facile de dire qu'on ne comprend pas quand on ne s'en donne pas la peine.
[^] # Re: Juste pour s'échanger des commérages !
Posté par Larry Cow . Évalué à 4.
Allez, je t'en remets une couche :
http://en.wikipedia.org/wiki/UDP_hole_punching#Algorithm http://en.wikipedia.org/wiki/TCP_hole_punching http://en.wikipedia.org/wiki/Teredo_tunneling#Overview http://en.wikipedia.org/wiki/Session_Traversal_Utilities_for_NAT#NAT_traversal_solutions
[^] # Re: Juste pour s'échanger des commérages !
Posté par devnewton 🍺 (site web personnel) . Évalué à -1.
J'ai vu tes liens, mais je ne comprends pas plus. Je ne suis pas spécialiste des réseaux, alors j'aurais besoin d'une description "talk to me like I'am 3 years old".
Tu fais comment quand tu rencontres une michu? Tu lui balances tes liens wikipedia super techniques?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Juste pour s'échanger des commérages !
Posté par ecyrbe . Évalué à 6.
Pour faire simple, STUN fonctionne au dessus d'UDP. UDP est un protocole non connecté.
Imaginons deux points A et B souhaitant communiquer. Ils sont tous les deux derrière du NAT.
Par un mécanisme algorithmique que l'on nomme STUN et qui emplois 2 serveurs, A arrive connaitre les information sur son son réseau et celui de B. B arrive à obtenir les mêmes informations. A connait donc un port et une adresse publique ou contacter B par UDP. B aussi.
Et voilà... une communication bidirectionnelle vient de se produire entre A et B. Ce mécanisme tombe à l'eau si l'un des NAT est symétrique. Ce type de NAT est rare (aucune box à ma connaissance ne l'implémente), j'en ai rencontré chez des offres pros de FT et certains FAI qui blindent la sécurité et facturent l'administration à l'ouverture de ports. (en gros ils mettent du NAT symétrique pour des raisons de business model et sous couvert de sécurité).
[^] # Re: Juste pour s'échanger des commérages !
Posté par devnewton 🍺 (site web personnel) . Évalué à -1.
Ok merci pour ces explications, je crois avoir compris le système. Par contre ça me semble être assez aléatoire, puisque ça suppose:
Donc au lieu d'expliquer à Mme Michu le port forwarding, je dois lui expliquer quel type routeur acheter et comment configurer son firewall.
Sachant que de toute façon Mme Michu n'a aucune chance de trouver toutes ces informations et procédures toute seule...
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Juste pour s'échanger des commérages !
Posté par Thomas Douillard . Évalué à 2.
Mme Michu a la box de son FAI. Faut pas en attendre plus.
[^] # Re: Juste pour s'échanger des commérages !
Posté par devnewton 🍺 (site web personnel) . Évalué à -1.
Donc si ça bloque, je fais quoi?
(Au passage ce n'est pas très sympa de moinsser alors que je cherche juste une solution).
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Juste pour s'échanger des commérages !
Posté par ecyrbe . Évalué à 3.
Chez toi, ça ne bloquera pas. On te dis qu'aucune box, ni routeur/firewall, ne bloqueront l'usage de STUN et TURN combinés (méthode appelé ICE). Donc utilise un logiciel qui supporte ICE et tu n'auras jamais de souci sans même avoir besoin de port forwarding.
Mieux, contrairement au port forwarding, vous pourrez être plusieurs ordinateurs derrière ton NAT utiliser la visio simultanément, chose impossible avec le port forwarding sans se casser la tête.
[^] # Re: Juste pour s'échanger des commérages !
Posté par ecyrbe . Évalué à 4.
Ca n'est pas aléatoire du tout. STUN permet à l'application de savoir à l'avance si ça va marcher et ce de manière automatique.
En effet STUN te donne des information sur la topologie de ton réseau et celui de ton correspondant.
Si tu vois que ça ne va pas passer (en gros sur des réseaux d'entreprises blindés qui de toute façon refuseront d'ouvrir des ports), le logiciel pourra, s'il voit que c'est possible, passer par un relai TURN. Ce n'est donc pas aléatoire, c'est déterministe, et ça fonctionne. Je développe un logiciel de visio conférence dans mon boulot, qui utilise STUN et TURN et à part quant il y a une volonté de tout bloquer sur son firewall par l'administrateur, ça passe sans que l'utilisateur (et l'admin réseau) n'ait quoi que se soit à configurer.
[^] # Re: Juste pour s'échanger des commérages !
Posté par devnewton 🍺 (site web personnel) . Évalué à 1.
Ok et quand ça ne passe pas, comment est-ce que je peux faire un diagnostic?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Juste pour s'échanger des commérages !
Posté par ecyrbe . Évalué à 3.
Je dirais que tu as trop de lacunes en réseau pour chercher à faire un diagnostique par toi même. Mon conseil, utilise un logiciel qui fait le boulot à ta place et qui utilise le protocole ICE.
S'il ne marche pas, ou ne te dis pas d'ou vient le problème quand ça ne marche pas, c'est un mauvais logiciel, change de logiciel.
[^] # Re: Juste pour s'échanger des commérages !
Posté par devnewton 🍺 (site web personnel) . Évalué à 1.
J'ai déjà tenté Empathy, d'après un commentaire ici Pidgin bloque aussi. Je vais en essayer d'autre ce soir si j'ai le courage, mais bon...
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Juste pour s'échanger des commérages !
Posté par ecyrbe . Évalué à 3.
Tu essaye de communiquer avec qui? La personne en face de toi installe t'elle le même logiciel que toi?
Si tu as un problème avec un logiciel, poste un message sur le forum en décrivant exactement ce qu'il se passe, la topologie de ton réseau et celui de ton correspondant, le message d'erreur qu'il affiche.
Poste ça sur le forum, je jetterais un coup d'oeil ce soir et te donnerais des pistes s'il s'agit d'un problème réseau, de configuration ou logiciel.
[^] # Re: Juste pour s'échanger des commérages !
Posté par Thomas Douillard . Évalué à 4.
T'es de mauvaise foi, les solutions qui sont proposées ont toutes pour but que Mme Michu ait le moins de questions à se poser, mais tu restes bloqué sur la configuration du routeur parce que tu sais faire. D'ailleurs c'est limite si tu attends que Mme Michu sache ou apprenne subséquemment à le faire, puisque tu sais le faire, c'est pas technique. D'un autre côté dés qu'on cause technique, mais pas celle que tu connais, tu veux pas écouter ...
Contradiction ? Mme Michu devrait apprendre la technique, mais pas toi, quoi.
[^] # Re: Juste pour s'échanger des commérages !
Posté par devnewton 🍺 (site web personnel) . Évalué à -3.
Contradiction ? Mme Michu devrait apprendre la technique, mais pas toi, quoi
Il faut dire que vous dégoûtez les gens d'apprendre... Mme Michu serait déjà sur Skype depuis longtemps avec vos "explications".
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Juste pour s'échanger des commérages !
Posté par Larry Cow . Évalué à 3.
Attends, mélange pas tout : Mme Michu ne demande pas d'explication, elle demande que ça marche. Toi par contre, tu assènes ton petit morceau de connaissance réseau (le forward de port) et tu refuses de considérer comme valide toute solution qui s'en passerait.
Tout le monde te dit depuis le début que Jingle (Nodes) est FAIT pour que ça fonctionne sans poser de questions, tu es le seul ici à vouloir compliquer ça.
[^] # Re: Juste pour s'échanger des commérages !
Posté par Thomas Douillard . Évalué à 3.
Oh tu sais moi je dois être environ pareil que toi niveau compétences techniques réseau, et j'ai qu'une vague idée intuitive de comment le truc automatique peut marcher, et j'ai pas envie d'aller plus loin.
Par contre si on me dit de changer de logiciel pour que ça marche ou de renseigner une passerelle dans le logiciel, j'écouterai un peu ...
[^] # Re: Juste pour s'échanger des commérages !
Posté par Zenitram (site web personnel) . Évalué à 3.
Je vais te surprendre : elle l'est. Depuis longtemps. Et elle ne s’embête pas avec le routeur.
Et pas que que Mme Michu, dans mon boulot avec plein de monde à tous les coins de la planète, c'est Skype, Skype et encore Skype, point de XMPP/Jingle.
[^] # Re: Juste pour s'échanger des commérages !
Posté par devnewton 🍺 (site web personnel) . Évalué à 0.
Normal, si les pros de XMPP/Jingle lui répondent toujours "ça devrait marcher tout seul"...
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Juste pour s'échanger des commérages !
Posté par Zenitram (site web personnel) . Évalué à 4.
Ca doit marcher tout seul, sinon c'est un bug du logiciel. Toi tu veux palier au bug du logiciel avec un tout petit peu de verni technique (qui te fera choisir la mauvaise conclusion quand tu demanderas quand même au devs de changer quelque chose) plutôt que de remonter le bug, c'est une mauvaise approche. Tu n'as pas les compétences techniques, remonte le bug et laisse les développeurs décider de ce qu'il faut faire pour corriger.
[^] # Re: Juste pour s'échanger des commérages !
Posté par devnewton 🍺 (site web personnel) . Évalué à 1.
Ben tout ce que je peux remonter, c'est "ça marche po"...
Sinon est-ce que tu peux m'expliquer pourquoi tant de jeux se contentent d'un port forward? Après tout, les jeux c'est plutôt pour des non techniciens, comme pour le chat audio/video, non?
http://portforward.com/cports.htm http://www.resoo.org/docs/counterstrike/steam_ports.html
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Juste pour s'échanger des commérages !
Posté par Thomas Douillard . Évalué à 2.
Ben quand tu branches ta playstation, ça marche, point, en général ...
Les gens qui savent et qui jouent à des jeux pour lesquels on a besoin de monter des serveurs persos chez soi, il y en a pas beaucoup. Et ceux qui ont des teamspeaks sont plus technique que la moyenne, dans un groupe de joueurs t'as souvent l'informaticien de service et le serveur dédié qui traine dans un coin de mon expérience.
[^] # Re: Juste pour s'échanger des commérages !
Posté par devnewton 🍺 (site web personnel) . Évalué à 1.
Ok, mais alors pourquoi ne pas avoir utiliser les mêmes techniques que pour Jingle? Après tout, si c'est plus simple pour Mme Michu, ça doit être plus simple pour tout le monde!
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Juste pour s'échanger des commérages !
Posté par Larry Cow . Évalué à 1.
Parce que c'est assez récent comme technique? Tu cherches à nous faire dire quoi, qu'il y a un vice de conception caché derrière toutes les techniques de traversée de NAT hors forward manuel de port?
[^] # Re: Juste pour s'échanger des commérages !
Posté par devnewton 🍺 (site web personnel) . Évalué à -1.
Imagine un avion qui n'a que des commandes automatiques et pas de mode manuel... Oui j'appelle ça un vice de conception.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Juste pour s'échanger des commérages !
Posté par Larry Cow . Évalué à 2.
Dans les mains d'un mec qui a déjà du mal à conduire une voiture, non. C'est déjà une catastrophe. Et dans ces cas-là, le seul salut c'est un très bon mode automatique : un mode automatique médiocre, fut-il doublé d'un mode manuel, n'est d'aucune utilité.
[^] # Re: Juste pour s'échanger des commérages !
Posté par devnewton 🍺 (site web personnel) . Évalué à -1.
Dans le cadre de la recherche d'une meilleure qualité vocale, il est également conseillé d'ouvrir les trafics TCP et/ou UDP entrants vers le port spécifique que vous voyez dans les options Skype
https://support.skype.com/fr/faq/FA148/Je-ne-peux-pas-me-connecter-a-Skype-sur-mon-lieu-de-travail-ou-en-raison-de-la-presence-d-un-pare-feu-restrictif-Quels-ports-doivent-etre-ouverts-pour-pouvoir-utiliser-Skype
Voilà qui clôt le débat. Pour moi si le premier logiciel du marché le permet, je ne vois une raison objective de refuser cette simple fonctionnalité.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Juste pour s'échanger des commérages !
Posté par Zenitram (site web personnel) . Évalué à 4.
"il est également conseillé". Çà clôt le débat : c'est du bonus, aucunement un truc nécessaire pour que ça marche..
Oui, on sait que ce serait mieux d'avoir un port fixe possible pour quelques bidouilleurs, mais non, ce n'est pas la chose la plus importante à changer aujourd'hui, il y a bien plus important comme par exemple que ça marche sans rien faire, même si c'est un peu moins bien.
[^] # Re: Juste pour s'échanger des commérages !
Posté par devnewton 🍺 (site web personnel) . Évalué à 0.
Joli raisonnement.
Un protocole et des logiciels libres, c'est du bonus, aucunement un truc nécessaire pour que ça marche...
Oui avoir les sources c'est mieux pour quelques bidouilleurs, mais non, ce n'est pas la chose la plus importante, la preuve Mme Michu utilise Skype et se contrefout de XMPP.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Juste pour s'échanger des commérages !
Posté par KiKouN . Évalué à 2.
Un protocole et des logiciels libres ne sont, en effet, pas nécessaire pour que ça marche. Mais pour que ça dur, il est difficile de ne faire confiance qu'à une seule société, un seul logiciel et un seul réseau.
Pour Mme Michu, ça ne change rien, mais pour des entreprises, c'est une valeur ajouté non négligeable.
[^] # Re: Juste pour s'échanger des commérages !
Posté par ecyrbe . Évalué à 3.
Tu n'as pas l'air de comprendre que le port forwarding possède un défaut de conception. Celà autorise n'importe qui à rentrer dans ton réseau, contrairement à la méthodologie stun qui ne laisse rentrer que ceux avec qui tu souhaite communiquer.
Cependant, si tu souhaites vérifier par toi même qu'il n'y a pas de défaut de conception sur ton logiciel, lance un client STUN à part. exemple celui-ci : http://sourceforge.net/projects/stun/ Lance le chez toi et on correspondant pour vérifier que le diagnostique ne renvoit pas "symetric NAT".
S'il renvoi autre chose, c'est un bug dans le logiciel,ou bien un problème de configuration de STUN lui même qui ne pointe pas sur les bon serveurs. S'il renvoi "symetric NAT", et que logiciel est sencé supporter ICE, c'est soit qu'il y a un bug logiciel, soit qu'il ne pointe pas sur un serveur TURN valide. S'il n'y a pas de serveur TURN publiquement accessible (pas étonnant, vu le cout d'un serveur), tu peux installer un serveur TURN ou tu le souhaite. par exemple celui-ci: http://turnserver.sourceforge.net/ Si tu n'as pas accès à une machine avec une adresse publique pour installer ce serveur. Il te reste la solution de secourt que tu propose depuis le début. Met ton serveur TURN directement sur ta machine derrière ton NAT et fait du port forwarding dessus. Configure ton logiciel pour l'utiliser et celui de ton correspondant. C'est manuel et compliqué... mais tu n'as besoin de ça, mais comme tu insiste pour avoir une solution avec mains dans camboui, je te la donne. Amuse toi bien...
[^] # Re: Juste pour s'échanger des commérages !
Posté par Larry Cow . Évalué à 3.
Ben tout ce que je peux remonter, c'est "ça marche po"...
Tout ce qu'il nous manque, c'est "ça".
[^] # Re: Juste pour s'échanger des commérages !
Posté par Zenitram (site web personnel) . Évalué à 0.
Franchement, je ne sais pas ce que tu fais avec les jeux, perso j'installe et ça marche, je peux causer directement avec mes correpsondants.
Après, il y a les admins, ceux qui veulent mettre des serveurs de jeux sur une machine, mais la, ce n'est plus Mme Michu, on revient sur les quelques rares geeks qui aiment bidouiller.
Tu mélanges toujours une très très faible partie de la population avec les gens en général.
[^] # Re: Juste pour s'échanger des commérages !
Posté par Larry Cow . Évalué à 3.
Je ne suis pas spécialiste des réseaux
On s'en était rendu compte tous seuls.
[^] # Re: Juste pour s'échanger des commérages !
Posté par Zenitram (site web personnel) . Évalué à 2.
J'ai du mal à te suivre : tu dis connaitre un peu la technique (port forwarding), et demande à ce que la technologie change pour que tes connaissances te permettent de faire ce que tu veux, plutôt que de lire un lien Wikipedia, apprendre que d'autres choses que le port forwarding existent, et apprendre comment utiliser ces choses pour arriver à ton but.
Désolé, je ne comprend pas comment on peut dire qu'un truc manque dans une technologie ("inacceptable en 2011" pour reprendre tes mots) quand on refuse de se renseigner (lire Wikipedia par exemple) et de voir qu'il y a déjà des solutions plus optimales (et surtout qu'un logiciel peut implémenter automatiquement, pour être transparent pour l'utilisateur, bien plus utile pour tout le monde!) pour résoudre ton problème.
[^] # Re: Juste pour s'échanger des commérages !
Posté par Firwen (site web personnel) . Évalué à 2.
Ce qui serait nettement plus simple pour tout le monde, c'est que nos dirigeants bien aimés force le passage à l'IPv6 pour balancer cette saloperie de NAT.
C'est pas XMPP le problème, on retrouve ça avec SIP et avec tous les procoles qui font des flux pair à pair. C'est sur le NAT qu'il faut tirer à vu, pas sur XMPP
[^] # Re: Juste pour s'échanger des commérages !
Posté par Albert_ . Évalué à 3.
cela ne resoud pas le probleme en entreprise ou je suis pret a parier que ipv6 c'est pour demain et pour pas mal de raison avec la premiere etant: "ca marche comme ca on touche pas".
[^] # Re: Juste pour s'échanger des commérages !
Posté par djano . Évalué à 2.
Ah ben ça risque pas d’arriver avec ce gouvernement la: "Passage à IPv6 : la position du gouvernement français est de ne rien faire..." http://www.zdnet.fr/blogs/infra-net/passage-a-ipv6-la-position-du-gouvernement-francais-est-de-ne-rien-faire-39759511.htm
Il n'a toujours pas compris quoi que ce soit a l'informatique et en quoi la France pouvait être bonne dedans. C'en est désespérant.
[^] # Re: Juste pour s'échanger des commérages !
Posté par Larry Cow . Évalué à 3.
En même temps, c'est peut-être à toi/moi/nous de leur montrer. Il y a déjà quelques sociétés françaises qui sont très bonnes là-dedans, mais manifestement pas assez pour attirer l'attention de nos gouvernements successifs.
[^] # Re: Juste pour s'échanger des commérages !
Posté par Albert_ . Évalué à 2.
Nos gouvernants preferent serrer les mains de Gates et Ballmer plutot que de promouvoir les boites francaise. Que veux tu ils savent ou est leur portefeuille...
[^] # Re: Juste pour s'échanger des commérages !
Posté par Adrien . Évalué à 3.
pidgin par exemple aussi.
[^] # Re: Juste pour s'échanger des commérages !
Posté par Nÿco (site web personnel) . Évalué à 1.
Tu veux ré-architecturer RTP ? Bon courage...
# Poezio
Posté par louiz’ (site web personnel) . Évalué à 8.
Ah ben comme je vois que mon camarade est déjà passé pour parler de son client (Salut-à-Toi), alors je vais parler du mien, si peux me permettre.
Alors poezio (http://poezio.eu) c’est un client Jabber en console qui a pour but de ressembler aux clients IRC « pour geek » populaires, c’est à dire irssi et weechat.
En effet, il est principalement tourné autour des salons de discussions (MUC) et permet, comme sur IRC, de glander (idler) sur un très grand nombre de salons, et d’avoir une interface rapide et pratique pour gérer tout ça, tout en laissant trainer ça dans un Screen ou Tmux. De plus, il se connecte anonymement par défaut, ne requérant ainsi aucune création de compte.
Mais bien sûr, on peut utiliser son compte, discuter avec ses contacts ainsi que gérer et chercher dans son roster (liste de contacts). Il peut donc parfaitement être utilisé en tant que client principal (quelques personnes, dont moi, le font), et dans le futur, même des fonctionnalités de microblogging et ce genre de choses.
C’est encore un client assez jeune, même s’il implémente déjà quelques fonctionnalités « avancées ». Je vous invite à le tester si ça vous intéresse.
Liens :
La forge avec la version de développement (conseillée si vous compter me faire des retours)
les sources
Ah, et n’hésitez pas à poser vos questions ou remarques sur le salons Jabber : poezio@kikoo.louiz.org :)
Et XMPP, c’est cool.
[^] # Re: Poezio
Posté par Internaciulo . Évalué à 1.
Ĉu vi konscie elektis esperantan nomon ?
[^] # Re: Poezio
Posté par louiz’ (site web personnel) . Évalué à 2.
Oui, j’aime bien prendre des mots espéranto pour le nom de mes logiciels. (Précédemment y’a eu Ludimagia (ludi + magia))
Mais en vrai, même si j’aimerais bien, et que j’ai tenté : je parle pas espéranto :p (Mais j’ai réussi à comprendre ta question !)
# mail over XMPP
Posté par KiKouN . Évalué à 4.
SMTP est une plaie que l'on traine depuis 30 ans et que l'on essaye de patché notament contre les spams.
XMPP implémente déjà un système de message déconnecté juste suffisant pour dire que l'on as cherché à joindre un contact absent. Est-ce qu'une XEP existe ou est prévue pour apporter une système de messagerie asynchrone avec les possobilités que l'on dispose comme avec IMAP (et les scripts sieve) ?
[^] # Re: mail over XMPP
Posté par Goffi (site web personnel, Mastodon) . Évalué à 3.
Qu'entends-tu par « les possibilités que l'on dispose comme avec IMAP » ?
XMPP permet la messagerie "asynchrone", et le filtrage type sieve envisageable (à ma connaissance il n'existe rien pour le moment côté serveur, mais il suffit de proposer une xep).
Sinon je t'invite à lire la discussion plus haut, et notamment mon billet sur le courriel via XMPP: https://linuxfr.org/news/xmpp-au-printemps-le-grand-rafra%C3%AEchissement#comment-1221472 , je pense aussi que XMPP a toute les qualités pour remplacer avantageusement, à terme, SMTP.
[^] # Re: mail over XMPP
Posté par KiKouN . Évalué à 1.
J'entendais surtout la gestion de dossier et la gestion des messages (déplacements et autre).
Je n'avais pas vu ce fil de discussions. Sinon ton post sur ton blog explique très bien ma pensée.
# norloges ?
Posté par gregR ☯ (site web personnel) . Évalué à 3.
des norloges dans XMPP ? la tribune n'a qu'à bien se tenir !
http://gregr.fr
[^] # Re: norloges ?
Posté par Nÿco (site web personnel) . Évalué à 1.
C'est implémenté dans OneTeam Desktop : http://oneteam.im/
[^] # Re: norloges ?
Posté par gregR ☯ (site web personnel) . Évalué à 1.
Merci, derrière le clin d'œil c'était une vrai question. Je ne pensais pas qu'un client l'implémentais déjà.
http://gregr.fr
# les nhorloges
Posté par grid . Évalué à 3.
Pour ceux qui ont déjà testé les salons XMPP, tous regrettent la puissance des nhorloges et du highlight de https://linuxfr.org/board/
[^] # Re: les nhorloges
Posté par Nÿco (site web personnel) . Évalué à 1.
Voir le même commentaire au-dessus : OneTeam Desktop le fait http://oneteam.im/
Avec highlight d'un thread dans une conversation, affichage du thread uniquement (filtrage de la conversation par élimination des autres threads), et puis même qu'il fait la correction/édition de ton dernier message (une seule fois, parce que).
[^] # Re: les nhorloges
Posté par grid . Évalué à 2.
on est loin de la puissance des nhorloges, qui permettent entre autre de faire du multi référencement de post
# Requête de mise à jour aux admins
Posté par Jehan (site web personnel, Mastodon) . Évalué à 5.
Bonjour,
1/ pourrait-on mettre à jour les liens RFCs? Je pensais qu'ils resteraient un peu, mais les liens donnés étaient en fait les liens dans la dernière phase du processus de standardisation (qui s'est stabilisé aujourd'hui, bien que les versions données étaient déjà les versions finales qui n'avaient quasiment aucune chance d'être modifié dans cette étape avant le statut final).
Les bons liens sont donc:
http://www.rfc-editor.org/rfc/rfc6120.txt http://www.rfc-editor.org/rfc/rfc6121.txt http://www.rfc-editor.org/rfc/rfc6122.txt
Ou encore, je préfère personnellement utiliser:
http://tools.ietf.org/html/rfc6120 (etc. 6121, 6122)
parce que c'est du html avec hyperliens dans les menus (et qu'on peut aussi avoir la version txt ou pdf à partir de là).
2/ Aussi pourriez-vous modifier aussi le "TLS EXTERNAL" qui est une bête erreur alors que je sais pertinemment que c'est TLS + SASL EXTERNAL. Ça m'évitera d'avoir honte. ;-)
Je donne aussi l'astuce aux gens intéressés dans les RFCs et dans l'utilisation avancés d'un navigateur web aussi: dans Firefox (et je pense dans le plupart des concurrents, y a un équivalent), vous pouvez enregistrer un bookmark de la sorte: http://tools.ietf.org/html/rfc%s Et vous mettez un "keyword", par exemple "rfc". Puis dans votre barre d'adresse, vous tapez juste "rfc 6120" et paf! Vous êtes direct dans la bonne rfc! C'est ce que je fais personnellement pour naviguer rapidement d'une RFC à l'autre.
Vous pouvez adapter cette astuce à tout type de site qui utilise des URL "parlantes" et simples (comme quoi, c'est important de penser l'architecture des URL!).
Merci.
Jehan
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
# Bataille perdue d'avance
Posté par Changaco (site web personnel) . Évalué à 4.
XMPP fonctionne à peu près correctement en tant que protocole de messagerie instantanée, mais contrairement à ce que soutiennent ses partisans il n'est ni générique ni efficace.
Bref, XMPP est un vieux protocole et la XSF fait partie de la même église que le W3C, celle de la rétro-compatibilité à tout prix et de la vision à court terme. Maintenir voire améliorer XMPP est tout à fait louable, mais réfléchir à sa succession me parait nécessaire si l'on ne veut pas que les futures innovations soient privatisées et privatrices comme l'est Facebook aujourd'hui.
[^] # Re: Bataille perdue d'avance
Posté par devnewton 🍺 (site web personnel) . Évalué à -2.
incapable de transporter efficacement (ni base64 ni ouverture d'une nouvelle connexion) des données binaires comme des images
Mais si! Il suffit de passer par Jingle qui est super parce qu'il traverse les NAT à la nage :-)
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Bataille perdue d'avance
Posté par Nÿco (site web personnel) . Évalué à 0.
Oui, enfin effectivement, c'est pas prévu pour. Le Jingle ou autres proxies, c'est du out-of-band uniquement hein.
[^] # Re: Bataille perdue d'avance
Posté par Nÿco (site web personnel) . Évalué à 1.
Donc tu proposes un publish-subscribe générique, comme c'est la tendance actuellement ?
[^] # Re: Bataille perdue d'avance
Posté par Changaco (site web personnel) . Évalué à 1.
Je pense que le protocole serait plus simple (et les implémentations plus légères) s'il avait été conçu autour d'un mécanisme de pub-sub générique.
[^] # Re: Bataille perdue d'avance
Posté par KiKouN . Évalué à 3.
Si tu utilise un JID en @jabberfr.org ou autres serveurs publics, il est en effet pénible de changer de serveur. Si tu utilise ton propre nom de domaine hébergé par tes soins ou par d'autres. Il est très simple de changer de serveur, une modification de son dns, prevenir le nouveau serveur, l'ancien aussi pour être courtois, et voilà.
Non, le problème n'est pas de changer de serveur, mais de migrer son compte (sauvegarde de sa liste de contact et ton autres préférences). Toutefois, une telle migration demandera toujours une acceptation des contacts d'en face et de redonner les droits au comptes sur des salons par exemple.
[^] # Re: Bataille perdue d'avance
Posté par Changaco (site web personnel) . Évalué à 5.
Je parlais bien de changement de JID, et ce que je voulais dire c'est que cette opération est pénible car XMPP mélange localisation et identité, ce qui fait qu'on ne peut pas «se déplacer» facilement.
[^] # Re: Bataille perdue d'avance
Posté par Cyrille Pontvieux (site web personnel, Mastodon) . Évalué à 2.
En effet ça m'embête beaucoup moi.
Je voudrais pouvoir utiliser le domaine que j'ai acheté comme JID. Et faire pointer ce JID sur le serveur de mon choix. Mais le JID contient directement le nom du serveur à contacter, il n'y a pas, à ma connaissance, d'indirection possible.
Enfin si c'est possible ça m'intéresse grandement.
Pour résumer je voudrais avoir moi@mondomaine.fr que je fasse pointer sur le serveur jabber/JID moi@le_serveur_jabber_que_j_utilise.fr
Ainsi je pourrais donner mon adresse Jabber moi@mondomaine.fr à tout le monde, même si un jour je décide de migrer sur serveur_jabber_qui_dechire.fr en migrant mon compte.
Pour l'instant changer de serveur = redonner son nouveau JID à tout le monde. Est-il possible de résoudre cette problématique actuellement ? Est-ce qu'une XEP existe ou est en cours de rédaction pour permettre de répondre à ce problème qui ne doit pas uniquement me concerner ?
[^] # Re: Bataille perdue d'avance
Posté par Jehan (site web personnel, Mastodon) . Évalué à 10.
Salut,
bien sûr que c'est possible! J'en parle même dans mon article!
Je cite un organisme qui propose ce service (payant): Google avec les Google Apps.
Beaucoup plus proche des libristes, l'Apinc (Association pour la Promotion de l'Internet Non Commercial) aussi propose le même service gratuitement: http://jabber.apinc.org/. Je suis un peu bête d'avoir oublié de parler de leur service (n'hésitez pas à ajouter ce lien à la dépêche!). Ce genre de service se démocratise de plus en plus et leur sécurisation est un de nos gros sujets du moment (cf. l'article et je détaille plus bas dans ce post).
L'un comme l'autre te permettrait d'avoir ton jid comme toi@tondomaine.fr, et ce sans que tondomaine.fr redirige vers quoi que ce soit d'autre que ton site web dans un navigateur.
J'explique même comment ça marche dans l'article (même si c'est vrai que je n'ai pas détaillé, car si je détaille tout, l'article est trop long, un reproche qu'on me fait souvent): on utilise les DNS SRV records.
Les ancêtres
La vieille méthode que http utilise encore, c'est effectivement juste de rediriger un domaine vers l'adresse principale qui lui est dédiée (ce qu'on appelle un enregistrement A pour IPv4 et AAAA pour IPv6. Il existe chez Mozilla un rapport de bug depuis 11 ans et demi pour utiliser les SRV et ne passer aux A/AAAA qu'en fallback, auquel je suis abonné moi-même depuis quelques années et qui a beaucoup de votes, d'abonnés, et a même eu des patchs envoyés par certains, mais Mozilla ne semble pas intéressé alors que le service http a déjà été enregistré par l'IANA).
Mais ça c'est la méthode antique, aucune flexibilité.
La relêve (actuelle)
Les enregistrements de service, c'est bcp plus subtil. On fait un enregistrement DNS qui dit quelles IPs regarder pour tel "service". Nous, on a deux enregistrement de service principaux: xmpp-client ou xmpp-server (selon qu'on parle au client ou serveur).
Une entité fait donc une requête DNS pour le domaine concerné du service désiré, et ça retourne une liste de couples (IP, port) à utiliser. Ça permet de préciser quelles IPs hébergent ton service Jabber et sur quel port (je connais au moins 2 serveurs qui n'utilisent pas le port par défaut sans aucun problème de fonctionnement alors que les services web doivent utiliser un truc moche à la example.com:8888 pour faire pareil), qui peut tout à fait être différent de ton serveur web.
Note que pour les petits organismes avec plusieurs serveurs mais sans beaucoup d'argent, ou sans tout une équipe d'administrateurs dédiés à l'infrastructure, SRV permet aussi un répartition de charges statique (donc basique mais suffisante pour beaucoup de petites et moyennes structures). Les enregistrements possèdent en effet un système de priorité et poids à utiliser conjointement pour se connecter aléatoirement (avec préférence) sur des machines différentes d'une utilisation à l'autre.
Un enregistrement normal (A/AAAA) n'a pas d'équivalent de ce système de répartition de charges car au mieux, on mélange les enregistrements A/AAAA aléatoirement (ils ont donc tous le même poids, on ne peut préciser les probabilités de connexion souhaités selon la machine, ce que fait SRV).
Donc oui, c'est possible, c'est même facile à faire. Ça demande des compétences très basique pour quiconque a les compétences de base pour avoir son propre domaine (c'est presque pas de l'administration info tellement c'est facile).
1/ tu t'inscris sur le service qui va héberger ton serveur.
2/ tu ajoutes un enregistrement DNS (pour ceux qui n'hébergent pas leurs propre serveur DNS, c'est en général simplement dans l'interface web de ton registrar) et tu ajoutes un (ou plusieurs si le service qui t'héberge a plusieurs machines) enregistrement de service xmpp-client et xmpp-server.
Et... c'est fini! XMPP fait ça depuis des années. En fait c'était déjà standard dans la RFC3920, comme je le dis dans l'article, donc on fait tous ça depuis au moins... 7 ans!
Google ne se gêne pas pour utiliser tout cela pour ses 5 machines XMPP client (et il a 5 machines xmpp-server différentes pour le même domaine):
Bien sûr certains font encore la vieille méthode avec un enregistrement A et/ou AAAA sur un sous domaine de leur domaine principal. Genre im.example.com. Perso j'ai jamais compris pourquoi! Je ne connais pas un client ni un serveur de nos jours qui ne gère pas les SRV records. Et au final c'est plus compliqué car on doit créer et gérer un nouveau sous-domaine.
Le futur
Enfin la seule problématique avec cette solution est la sécurisation par certificats X509 (TLS). Les possesseurs d'un domaine n'aime pas toujours donner un certificats pour leur domaine principal à un service tier, et ça peut se comprendre (le service tier, si malveillant, aurait alors le pouvoir — presque officiel — pour se faire passer pour le domaine principal pour d'autres types de service, comme le web).
Il est en réalité possible d'associer un certificat à un enregistrement de service (il y a au moins un CA qui propose ce genre de certificat), mais malheureusement à ce que j'ai compris les navigateurs web (encore eux!) ne regardent pas vraiment ce champs et donc cette sécurité passe à la trappe à l'heure actuelle. C'est pourquoi (encore comme je le dis dans l'article! J'explique trop mal?) pas mal de gens réfléchissent à une solution pour rendre ce passage de pouvoir à la fois aussi sécurisé que si on le faisait nous-même mais sans donner les pleins pouvoirs sur tout le domaine. Y a au moins un brouillon de RFC proposé sur le sujet (mais je l'ai pas encore lu, je ne connais pas sa pertinence).
Et après j'en lis plus haut que XMPP est une vieux truc alors qu'on est parmi le top de la technologie Internet (on est parmi les premiers à utiliser les technologies les plus récentes. SCRAM par exemple, XMPP est LA technologie qui fait vraiment démarrer ça et comparé aux vieux mécanismes SASL, c'est vraiment génial. SRV aussi, nous sommes parmi ceux qui ont créé une adoption massive; bien que sur le coup, je crois que SIP était avant nous) et qu'on est constamment à innover sur tous les fronts et à prendre des risques en adoptant des technologies avant les autres. Alors bien sûr on cherche aussi la rétrocompatibilité en même temps. Mais après si on cassait l'intéropérabilité entre les serveurs récents et anciens, vous iriez encore vous plaindre (et un peu plus à raison pour une fois)!
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Bataille perdue d'avance
Posté par Cofequei . Évalué à 1.
C'est mon cas, j'ai un truc tout moche du type user@jabber.example.net. À l'époque où on a mis en place notre serveur xmpp, il n'y avait pas beaucoup de clients et de serveurs qui géraient correctement les enregistrements SRV, du coup on a fait ce choix pour ne pas être trop emmerdé.
À ton avis, c'est possible de passer facilement de user@jabber.example.net à user@example.net ? Si possible, de manière transparente pour les utilisateurs et les contactes des utilisateurs ? Je ne sais pas trop quoi chercher sur google, si tu as quelques mots clés ça m'intéresse.
[^] # Re: Bataille perdue d'avance
Posté par Jehan (site web personnel, Mastodon) . Évalué à 3.
Salut,
non c'est pas facile. Pour les utilisateurs, tu peux le faire de manière plus ou moins transparente mais c'est pas forcément facile. Si le serveur ne prévoit pas ce genre de cas, c'est à toi de faire le nécessaire, ce qui implique quelques requêtes ds la BDD. Par contre, ça ne peut pas être transparent pour les contacts des utilisateurs par définition. En effet tu n'as pas accès à la base de données des contacts (sauf si tous les contacts de tes utilisateurs sont aussi dans tes utilisateurs bien sûr) et tu ne peux donc pas agir sur leur roster (imagine s'il existait une possibilité pour cela, ça signifierait que quelqu'un pourrait monter un faux serveur et créer des utilisateurs dessus pour "s'emparer" des utilisateurs d'autres serveurs, et ce de manière totalement invisible, donc il serait capable de faire des attaques ciblées en se faisant passer pour d'autres).
En conclusion, ce n'est pas la bonne solution.
Une solution pourrait être que tu pourrais envoyer des notifications de "déménagement" pour tous les contacts de tous les comptes utilisateurs (XEP-0283, l'extension expérimentale qui existe actuellement et implique que les contacts devront approuver manuellement le changement, par rapport à ce que je disais précédemment sur les problèmes de sécurité). Mais je ne sais pas exactement quels clients implémentent réellement cette XEP. Je ne la connais pas trop non plus, mais je pense qu'elle pourrait être vraiment améliorée pour être rendue plus transparente, tout en étant sécurisée. J'y jetterai peut-être un œil un jour.
Ma conclusion cependant serait que je ne te conseille pas de le faire de manière trop transparente. Déjà simplement parce que tes utilisateurs devront bien savoir que leur adresse a changée pour la donner aux gens. Ensuite parce que s'il y a des problèmes parce que des contacts n'ont pas pris en compte le changement (leur client ne supportait pas la XEP "moved" par exemple), ben tes utilisateurs pourraient ne pas s'en rendre compte immédiatement et simplement croire que tel ou tel contact ne se connecte plus pendant longtemps. Alors que s'ils sont bien informés, ils sont conscients que des problèmes peuvent survenir et donc être proactifs (rentrer en contact avec certains utilisateurs pour s'assurer qu'ils se mettent à jour).
Mon conseil:
1/ utilise la nouvelle adresse pour les nouveaux inscrits, mais garde l'ancienne en parallèle par défaut sans transférer personne. Un nouvel inscrit ne peut se faire par contre que sur la nouvelle.
Par contre informe tes anciens utilisateurs qu'une nouvelle adresse est disponible. 2/ réserve tous les nicks sur la nouvelle adresse qui existent déjà sur l'ancienne. Et fais savoir à chaque utilisateur que s'ils décident de "déménager", leur nick leur est réservé aussi longtemps qu'ils ont leur ancien compte. 3/ si un utilisateur désire déménager vers la nouvelle adresse, prépare tout pour lui faciliter la tâche le plus possible. Par exemple, il a juste un clic à faire sur une page (ou un bot XMPP à qui il envoie un message), ce qui génère automatiquement des stanzas de déménagement pour tous ses contacts, ainsi qu'envoie des autorisations à tous ses anciens contacts pour son nouveau compte). 4/ L'utilisateur qui déménage devrait garder un accès à son ancienne adresse un certain temps (6 mois?), ce qui lui permettrait de gérer les contacts qui ne supportaient pas la XEP-0283 et donc n'ont pas inscrit le nouveau JID (l'utilisateur a donc besoin de son ancienne adresse pour voir quand ils sont connectés, discuter avec eux et leur dire qu'il a changé si besoin par exemple) ou gérer les gens à qui il aurait récemment donné son ancien JID et qui inscriraient ce dernier. Et autre...
Et il faut savoir que tout type de migration a toujours son lot de problème. Mon expérience là-dedans, c'est qu'une bonne communication pour prévenir de cela vaut mieux qu'essayer d'être le plus discret possible (transparent) car lorsque les utilisateurs s'en rendent compte (car ils s'en rendront compte, et certains auront des problèmes), ils seront furieux. Alors que si tu leur laisses le choix en les prévenant des risques sur le court terme mais des avantages sur le long terme, ce sera un choix conscient de leur part, donc ils prennent leur part de responsabilité!
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Bataille perdue d'avance
Posté par jon . Évalué à 1.
Chez mes parents qui ont une Livebox, je peux pas faire de requêtes DNS sur des champs SRV, apparement, c'est bloqué par la Livebox:
Du coup, je suis obligé de configurer mes clients XMPP à la main :/
[^] # Re: Bataille perdue d'avance
Posté par Hobgoblins Master (Mastodon) . Évalué à 2.
Et
ça dit quoi ? Si tu as une réponse correcte, c'est juste les forwarders orange qui sont mal configurés, comme d'hab…
[^] # Re: Bataille perdue d'avance
Posté par devnewton 🍺 (site web personnel) . Évalué à -1.
XMPP façon linuxfr, c'est simple, si ça ne marche pas, il suffit de changer de logiciel, de routeur et de FAI!
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Bataille perdue d'avance
Posté par Hobgoblins Master (Mastodon) . Évalué à 2.
Il y a au moins 3 protocoles pour lesquels Orange est notoirement mauvais :
Et si
dig -t SRV _xmpp-client._tcp.gmail.comne fonctionne pas chez toi, c'est que tu est abonné à un FA <tout ce que tu veux> mais certainement pas à un Fournisseur d'Accès à Internet donc tu peux changer ;-)…[^] # Re: Bataille perdue d'avance
Posté par devnewton 🍺 (site web personnel) . Évalué à -2.
Décidément on manque d'humour chez les XMPP fanboys!
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Bataille perdue d'avance
Posté par Zenitram (site web personnel) . Évalué à -2.
En quoi un truc sur les DNS a à voir avec Internet? Désolé, mais je peux très bien avoir Internet sans DNS, Internet c'est une communication entre deux machines en IP, point. Sans DNS, je continue d'avoir Internet, l'envoi de paquet d'une IP à l'autre fonctionne. Le reste, c'est du bonus, et miracle, tu peux te servir des DNS de n'importe quel autre fournisseurs, c'est la joie d'Internet, le DNS ne fait pas partie d'Internet, pas obligatoire, donc tu peux mettre le DNS où tu as envie, voire ne pas t'en servir (les DNS, c'est fait surtout pour les humains...). Idem pour SMTP et NNTP...
Orange est un FAI, mais n'est pas un bon fournisseur de DNS ni SMTP ni NNTP, ça ne change rien à la partie FAI.
[^] # Re: Bataille perdue d'avance
Posté par claudex . Évalué à 3.
Non, si tu ne peux pas utiliser les DNS, tu ne peux pas envoyer des paquets d'une machine à l'autre ou alors tu dois te limiter dans les paquets que tu envoie, et donc, ce n'est pas Internet.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Bataille perdue d'avance
Posté par Zenitram (site web personnel) . Évalué à 1.
Tu peux m'expliquer plus en détail? comment je dois me limiter dans ce que j'envoie? Parce que moi, je vois vraiment pas en quoi zapper la partie "pour l'être humain" change quoi que ce soit. J'utiliserai des @IP, et voila tout. Les DNS sont une surcouche pas du tout utile à Internet, seulement aux humains qui ne savent pas retenir des chiffres, ou alors donne moi un exemple de ce que je ne peux pas faire (on évite les exemples où le protocole demande des noms de domaine alors qu'il pourrait accepter des @IP évidement...)
Des exemples!
[^] # Re: Bataille perdue d'avance
Posté par claudex . Évalué à 3.
Tu ne peux pas communiquer avec le port 53 en udp.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Bataille perdue d'avance
Posté par Zenitram (site web personnel) . Évalué à 1.
pourquoi pas? En quoi le protocole IP te l'interdit? Qui a dit dans le protocole IP / UDP / TCP que 53 = DNS. Qui m'interdit de pointer sur le DNS de mon serveur que j'aurai mis en place plutôt que d'utiliser celui de mon FAI? C'est des choses en plus d'Internet, pas Internet lui-même. un paquet, c'est une adresse IP+port destination, IP ne fait pas de différence entre les ports ou alors montre moi comment, car franchement, je n'arrive pas à comprendre ce qui m'en empêche actuellement. Même je pourrai utiliser autre chose que TCP ou UDP, j'ai 256 possibilités dans le champs "protocol" de trame IP.
[^] # Re: Bataille perdue d'avance
Posté par Changaco (site web personnel) . Évalué à 0.
L'un n'empêche pas l'autre. Il y a des mises à jour mineures qui étaient prévues par les RFC précédentes, mais le cœur reste inchangé et commence à se faire vieux. Le W3C aussi innove dans tous les sens, le Web n'est pas pour autant le meilleur possible, car on ne peut pas toucher aux fondamentaux.
Personne n'a proposer de casser le réseau XMPP.
[^] # Re: Bataille perdue d'avance
Posté par Maclag . Évalué à 2.
Je ne vais pas revenir sur le commentaire de Jehan, il s'y connait bien mieux que moi, et résume bien la question: oui, c'est possible, et depuis looooongtemps!
Par contre, j'aimerais attirer un peu plus l'attention sur:
1 - je ne connais rien d'autre de similaire (à part si vous considérer qu'utiliser votre compte FB partout sur la toile est une manière d'avoir un identifiant portable...)
2 - les implications pourraient aller bien plus loin à long terme, grâce aux autres avantages de XMPP, tels que les priorités et multi-sessions.
On peut imaginer à terme que les téléphones portables feront plus de VoIP que téléphone classique (actuellement c'est souvent interdit, mais ça ne durera probablement pas éternellement).
Dès lors:
Et le plus génial: suivant où l'on est et/ou ce qu'on fait, ça viendra soit sur l'ordinateur, soit sur le netbook, soit sur le tél portable!
L'antispam est presque déjà inclus: si pas dans ma liste de contact, pas d'appel possible, on peut imaginer à l'avenir des solutions flexibles telles que "ne m'emmerde pas avec les demandes de contact quand je suis sur mon téléphone, envoie ça au netbook/desktop"
Et enfin un commentaire qui n'a rien à voir, au sujet du nom du protocole:
Je n'aime pas le mot "Jabber", je trouve qu'il sonne très mal. C'est pas bô à entendre.
XMPP est quasiment imprononçable.
Mais je me rappelle avoir lu une fois sur le blog de Nÿco le nom "Zimppy" (ou un truc du genre). Je trouve que c'est 'achement mieux!
# Ça presque marche
Posté par devnewton 🍺 (site web personnel) . Évalué à 0.
Après configuration de mon routeur (firewall en mode gentil et UPNP) et l'essai de trois logiciels (Empathy, Pidgin, Jitsi), j'ai réussi à avoir une visioconf avec un son pas terrible et une vidéo buggée.
Jingle existe depuis plusieurs années, comment se fait-il que ce soit toujours aussi galère? Est-ce que la visioconf c'est très difficile à implémenter en général ou est-ce lié à ce protocole particulier?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.