Towel. Sans 'r'. Le jour de la serviette. Pas hygiénique, du coup, vu tout ce qu'elle est censée pouvoir contenir... ;-)
Mais oui, une fois par an, on me regarde de travers au boulot, sous prétexte que j'ai une serviette autour du cou. Et les vannes salaces de fuser, style "Salut ca va ?", ou "tu viens, on va bouffer !", "on va en pauses, tu viens fumer une clope ?"... Et vraiment, je me sens humilié, sali, rabaissé... :-]
Je propose donc une journée de "la journée de la serviette". Que tous les porteurs et porteuses de serviette sortent de chez eux avec une serviette autour du cou ! :-]
Par contre, je n'ai pas encore testé kilt + serviette le même jour ! :-)
> [...] alors on peut dériver sur le fait qu'un homme ne puisse pas porter de jupe...
> pression sociale ou ségrégation ?
C'est pas vrai. Moi j'ai déjà porté une jupe. Plus d'une fois. C'était drôle, j'ai bien aimé. Par contre, je ne le referai plus en hiver, ca fait froid.... Avec un effet, comment dire, diminuant sur l'aspect "taille"... :-)
Et puis j'ai aussi porté (et porte encore parfois) un kilt, un vrai, avec tout qui va bien. Un kilt c'est bien vu pour les hommes. Tout de suite tu as plein de minettes qui s'approchent de toi. En plus, c'est gratifiant, d'être enfin attirant. ;-)
Plus sérieusement... Il me semble qu'il y a des actions plus importantes à entreprendre sur le respect des femmes. Tout d'abord, dans l'éducation. Il faut arrêter d'orienter les filles et les garçons dans certaines filières sous prétexte uniquement du sexe. Trop souvent, l'orientation est biaisée (enfin, ca fait bien longtemps que je suis sorti de la filière éducation, alors ca a peut-être changé, mais en écoutant mon petit frère qui y est encore, je n'en ai pas l'impression).
Ensuite, professionellement, à travail égal, salaire égal. Il y a une loi (des lois ?) sur le sujet, mais sont-elles réellement respectées ? Dans mon entourage, je remarque fréquemment des différences notables, à responsabilités, expériences, etc... équivalentes, entre les rémunérations de mes amis et celles de mes amies. Les sanctions envers les employeurs non-respectueux de cette parité devraient être exemplaires, afin de dissuader les autres, ou plutôt de les inciter à corriger le tir.
Et tellement d'autres points tellement plus importants que la jupe...
> [le] droit aux femmes d'être belle de communiquer à l'extérieur, de manière
> verbale, mais aussi non verbale avec l'entourage
s/femmes/hommes/g; s/belles*/beaux/g;
Ah et puis aussi, supprimer le masculin/féminin de la langue française, et utiliser un nouveau genre, le neutre. Ca serait un message fort ! :-P
> C'est un peu comme si pour défendre le logiciel libre, on nous demandais de se
> déplacer une fois par an avec un costume de manchot, de Gnou ou déguisé en
> diablotin.
<flame>Diablotin, pas pour moi, mais manchot, je suis pour.</flame> Et pas qu'une fois par an. Et pas que pour défendre le FLOSS. Juste comme ça, parceque j'en ai envie. Et je suis aussi pour que quiconque a envie de se déguiser en Diablotin puisse le faire. Ou en carotte, ou en n'importe quoi, tant qu'on est "à l'aise". Qu'on ne soit pas jugé(e)s (que) sur notre apparence. :-)
> Ceux qui hésitent à participer à ce concours pourraient-ils indiquer pour quelle(s) raison(s) ?
Pour ma part :
1) Je trouve DLFP très bien tel qu'il est aujourd'hui.
2) RoR : Beark, encore un n-ième langage à apprendre.
3a) Je suis une bille en design. Voir pire.
3b) Je suis adepte du minimaliste, voire pire.
Du coup, une suggestion/question : pourra-t-on lire DLFP en mode texte ?
Voila, je vous avais prévenus : mi-ni-ma-lis-te... :-)
> MQ permet de modifier l'historique des patches gérés par lui, pas de n'importe quel morceau de l'historique du dépôt.
Pardon, pardon, mais c'est (en partie du moins) possible :
---8<---
# LC_ALL=fr_FR.UTF8 hg help qimport
[...]
Un "changeset" existant peut-être placé sous le contrôle de mq à l'aide de -r/--rev (par
exemple qimport --rev tip -n patch placera la révision tip sous le contrôle de mq).
[...]
---8<---
Mais MQ travaillant sur une série de patches, je comprend qu'il ne soit pas possible de transformer un embranchement de l'arbre (merge ou branche) en patch. Il n'est pas possible de stocker dans un patch ce genre d'info.
> Un conseil : renseigne toi aussi sur Git ;)
> C'est à peu près pareil que Mercurial, sauf que ça marche.
De mon expérience, les différences entre Git et Mercurial, d'un point de vue pratique, sont :
- pour un contributeur occasionel : la CLI de Hg est plus rapide à maitriser
- pour un contributeur régulier : la CLI de Hg est plus simple à utiliser
- pour le mainteneur : la paradigme Hg est plus rapide a comprendre, et maintenir le projet est plus simple.
Alors bien sûr, ce n'est qu'un retour de mon expérience personelle à moi. YMMV, comme ils disent.
Enfin, tout de même un trés gros bonus pour Mercurial : les MQ. Avec les MQ, le développeur maintient une serie de patchs par dessus le repository, et se ballade facilement avec des empilements/depilements (qpush/qpop). C'est très utile lorsqu'une modification est découpée en plusieurs étapes : ca permet de tester un ensemble de changements de revenir en arrière, de recommencer, etc... sans avoir fait le moindre commit.
Alors bien sur, on peut aussi faire ça avec Git, mais c'est plus compliqué. Il y a bien un utilitaire, stgit, mais il semble n'être plus maintenu, et n'est pas intégré 'de base' à Git, quand les MQ sont natives dans Mercurial.
> Comment se comporte Mercurial avec les fichiers binaires ?
Deux possibilités:
- 'nativement' : les fichiers binaires sont détectés, et stockés 'comme ca'.
- avec une extension (bfiles),
J'ai pas essayé bfiles. Par contre, j'ai un fichier binaire conséquent (et qui évolue peu) dans mon repository, et Mercurial se démerde plutôt OK.
> Au niveau de la gestion des droits du dépôt central, ça marche a peu près comme SVN ?
Plusieurs solutions aussi :
- authentification par le serveur http/https, si tu veux pousser par http/https
- authentification par ssh, si tu veux pouser par ssh
Pour ma part, http/https sont en lecture seule, et je pousse uniquement par ssh.
> les tabulations restent indispensables pour les Makefile.
Pas vrai. Tu peux utiliser la variable .RECIPEPREFIX pour changer le préfix des règles :
http://www.gnu.org/software/make/manual/make.html#Special-Variables
Et là, tu commences sérieux à rendre le Makefile pâteux. Déjà que c'est pas simple à lire...
Un des premiers jours dans un nouveau taf', j'ai fait une présentation en ASCII art, sous vim, en 80x25 !
Pas la peine de raconter la tête de mes collégues... Catalogué, que j'étais ! :-)
Tu fais un concours de la plus descriptive et longue dépêche avec patrick_g ? ;-)
Je ne ferai ni éloge ni reproche, n'utilisant pas cette distribution, mais je trouve que tu as bien décrit toutes les nouveautés et évolutions de cette version.
Cependant, quelques pointeurs auraient été les bienvenus (par exemple, pour illustrer le nouvel installeur graphique, un pointeur vers une gallerie de captures d'écran).
Au final, j'ai presque envie d'essayer. Presque ! ;-)
Je tiens à vous faire part de mes plus sincéres remerciements pour m'avoir fait connaître ce merveilleux outils qu'est ce Debian vivant !
Ce petit journal tombe vraiment au poil, juste le soir, ou devrais-je dire la nuit, où je devais préparer une clé USB bootable avec Debian dessus. Vraiment, vous m'ottates une épine du pied /
Veuillez recevoir, cher fleny68, mes plus chaleureux remerciements !
Cordialement,
Moi.
( OK, il est tard, j'ai pété un câble, je --> ZZzz )
( fleny68, quand squeeze sera dispo, tu t'apelleras fsqueze68 ? ;-] )
Un paquet IGMP (v2!) contient:
- le type : en gros je m'abonne / me désabonne
- le flux que je veux : l'adresse multicast
- un checksum
- et c'est tout.
IGMP n'est _pas_ encapsulé dans IP. IGMP est au même niveau que IP. Donc j'ai dit une petite bêtise en parlant de l'adresse unicast du serveur : il n'y en a tout simplement pas. Pas plus qu'il n'y a d'adresse source de la requete.
Donc, mon explication était peut-être implémentatoire ( qui n'est pas un mot français ! ), mais c'était surtout pour te faire comprendre qu'il n'y a pas d'adresse IP de destination contenant l'IP unicast de l'abonné au flux.
Les packets multicast ont une adresse de _destination_ qui est, je te le donne en mille... une adresse multicast !
Lorsqu'un routeur voit une requête IGMP passer, il mémorise /juste/ :
- l'adresse du flux demandé
- l'interface d'ou la requête provient
- l'heure du dernier (renouvellement de l') abonnement pour ce flux
Ensuite il propage la requête IGMP vers le routeur suivant, jusqu'au serveur.
A noter, bien entendu que les requêtes IGMP ont une adresse destination (et source?) qui est une adresse unicast, evidemment.
Ensuite, lorsqu'un routeur recoit un packet multicast, il regarde dans ses tables s'il a un abonnement pour ce flux, en ce basant sur l'adresse multicast. S'il n'en trouve pas, alors il droppe le packet. S'il trouve un (ou plusieurs) abonnement en cours, il transfert le packet vers chacune des interfaces ou un abonnement est en cours.
Et enfin, tous les equipements dans le réseau /local/ reçoivent le packet multicast. S'ils sont abonnés (ou espionnent), ils le prennent, sinon ils le droppent.
Donc, nulle part sur le chemin il n'y a besoin de l'adresse unicast de destination.
> Même en multicast, on a toujours une IP qui identifie chaque ordinateur, et le multicast doit bien garder une trace des adresses IP individuelle à un moment donné pour que les routeurs prennent leur décision, non ?
Non, et c'est l'interet du multicast. Ca marche comme ca (en gros) :
- un client s'abonne a un flux multicast, et envoie une requete IGMP au serveur de flux
- les routeurs sur le chemin memorisent cette requete
- le serveur emet son flux vers cette adresse multicast
- les routeurs envoient le packaget multicast vers tous les clients qui en ont fait la demande (grace a la memorisation de la requete IGMP)
- le client renouvelle periodiquement son abonnement (par d'autres requetes IGMP)
- a la fin, le client se desabonne du flux (par une autre requete IGMP)
- chaque routeur sur le chemin memorise, et si plus aucun client sur cette interface n'a d'abonnement en cours pour ce flux, le routeur cesse d'envoyer le flux sur cette interface
Comme ca, du cote serveur, un seul et unique packet est envoye, et ce sont les routeurs qui decident de dupliquer sur chacuen des interfaces ou ils ont vu une requete IGMP pour ce flux.
[^] # Re: Une bonne initiative
Posté par ymorin . En réponse au journal [HS] Journée de la Jupe. Évalué à 5.
Flûte, je lui ai donné à manger... :-/
[^] # Re: "Pour nous, les hommes"...
Posté par ymorin . En réponse au journal [HS] Journée de la Jupe. Évalué à 3.
Towel. Sans 'r'. Le jour de la serviette. Pas hygiénique, du coup, vu tout ce qu'elle est censée pouvoir contenir... ;-)
Mais oui, une fois par an, on me regarde de travers au boulot, sous prétexte que j'ai une serviette autour du cou. Et les vannes salaces de fuser, style "Salut ca va ?", ou "tu viens, on va bouffer !", "on va en pauses, tu viens fumer une clope ?"... Et vraiment, je me sens humilié, sali, rabaissé... :-]
Je propose donc une journée de "la journée de la serviette". Que tous les porteurs et porteuses de serviette sortent de chez eux avec une serviette autour du cou ! :-]
Par contre, je n'ai pas encore testé kilt + serviette le même jour ! :-)
# "Pour nous, les hommes"...
Posté par ymorin . En réponse au journal [HS] Journée de la Jupe. Évalué à 6.
> pression sociale ou ségrégation ?
C'est pas vrai. Moi j'ai déjà porté une jupe. Plus d'une fois. C'était drôle, j'ai bien aimé. Par contre, je ne le referai plus en hiver, ca fait froid.... Avec un effet, comment dire, diminuant sur l'aspect "taille"... :-)
Et puis j'ai aussi porté (et porte encore parfois) un kilt, un vrai, avec tout qui va bien. Un kilt c'est bien vu pour les hommes. Tout de suite tu as plein de minettes qui s'approchent de toi. En plus, c'est gratifiant, d'être enfin attirant. ;-)
Plus sérieusement... Il me semble qu'il y a des actions plus importantes à entreprendre sur le respect des femmes. Tout d'abord, dans l'éducation. Il faut arrêter d'orienter les filles et les garçons dans certaines filières sous prétexte uniquement du sexe. Trop souvent, l'orientation est biaisée (enfin, ca fait bien longtemps que je suis sorti de la filière éducation, alors ca a peut-être changé, mais en écoutant mon petit frère qui y est encore, je n'en ai pas l'impression).
Ensuite, professionellement, à travail égal, salaire égal. Il y a une loi (des lois ?) sur le sujet, mais sont-elles réellement respectées ? Dans mon entourage, je remarque fréquemment des différences notables, à responsabilités, expériences, etc... équivalentes, entre les rémunérations de mes amis et celles de mes amies. Les sanctions envers les employeurs non-respectueux de cette parité devraient être exemplaires, afin de dissuader les autres, ou plutôt de les inciter à corriger le tir.
Et tellement d'autres points tellement plus importants que la jupe...
> [le] droit aux femmes d'être belle de communiquer à l'extérieur, de manière
> verbale, mais aussi non verbale avec l'entourage
s/femmes/hommes/g; s/belles*/beaux/g;
Ah et puis aussi, supprimer le masculin/féminin de la langue française, et utiliser un nouveau genre, le neutre. Ca serait un message fort ! :-P
> C'est un peu comme si pour défendre le logiciel libre, on nous demandais de se
> déplacer une fois par an avec un costume de manchot, de Gnou ou déguisé en
> diablotin.
<flame>Diablotin, pas pour moi, mais manchot, je suis pour.</flame> Et pas qu'une fois par an. Et pas que pour défendre le FLOSS. Juste comme ça, parceque j'en ai envie. Et je suis aussi pour que quiconque a envie de se déguiser en Diablotin puisse le faire. Ou en carotte, ou en n'importe quoi, tant qu'on est "à l'aise". Qu'on ne soit pas jugé(e)s (que) sur notre apparence. :-)
[^] # Re: participants ?
Posté par ymorin . En réponse à la dépêche Participez au concours LinuxFr.org !. Évalué à 7.
Pour ma part :
1) Je trouve DLFP très bien tel qu'il est aujourd'hui.
2) RoR : Beark, encore un n-ième langage à apprendre.
3a) Je suis une bille en design. Voir pire.
3b) Je suis adepte du minimaliste, voire pire.
Du coup, une suggestion/question : pourra-t-on lire DLFP en mode texte ?
Voila, je vous avais prévenus : mi-ni-ma-lis-te... :-)
[^] # Re: System Rescue CD
Posté par ymorin . En réponse au journal Rescue réussi. Évalué à 1.
http://unetbootin.sourceforge.net/
Tu lui files une image ISO, il te fait une clé bootable.
Pof, pof, Igor...
[^] # Re: Question MQ
Posté par ymorin . En réponse à la dépêche Mercurial : version 1.7 et petit tour d'horizon. Évalué à 3.
Pardon, pardon, mais c'est (en partie du moins) possible :
---8<---
# LC_ALL=fr_FR.UTF8 hg help qimport
[...]
Un "changeset" existant peut-être placé sous le contrôle de mq à l'aide de -r/--rev (par
exemple qimport --rev tip -n patch placera la révision tip sous le contrôle de mq).
[...]
---8<---
Mais MQ travaillant sur une série de patches, je comprend qu'il ne soit pas possible de transformer un embranchement de l'arbre (merge ou branche) en patch. Il n'est pas possible de stocker dans un patch ce genre d'info.
[^] # Re: Très interessant
Posté par ymorin . En réponse à la dépêche Mercurial : version 1.7 et petit tour d'horizon. Évalué à 7.
> C'est à peu près pareil que Mercurial, sauf que ça marche.
De mon expérience, les différences entre Git et Mercurial, d'un point de vue pratique, sont :
- pour un contributeur occasionel : la CLI de Hg est plus rapide à maitriser
- pour un contributeur régulier : la CLI de Hg est plus simple à utiliser
- pour le mainteneur : la paradigme Hg est plus rapide a comprendre, et maintenir le projet est plus simple.
Alors bien sûr, ce n'est qu'un retour de mon expérience personelle à moi. YMMV, comme ils disent.
Enfin, tout de même un trés gros bonus pour Mercurial : les MQ. Avec les MQ, le développeur maintient une serie de patchs par dessus le repository, et se ballade facilement avec des empilements/depilements (qpush/qpop). C'est très utile lorsqu'une modification est découpée en plusieurs étapes : ca permet de tester un ensemble de changements de revenir en arrière, de recommencer, etc... sans avoir fait le moindre commit.
Alors bien sur, on peut aussi faire ça avec Git, mais c'est plus compliqué. Il y a bien un utilitaire, stgit, mais il semble n'être plus maintenu, et n'est pas intégré 'de base' à Git, quand les MQ sont natives dans Mercurial.
[^] # Re: Sismotherapie
Posté par ymorin . En réponse à la dépêche Mercurial : version 1.7 et petit tour d'horizon. Évalué à 4.
Deux possibilités:
- 'nativement' : les fichiers binaires sont détectés, et stockés 'comme ca'.
- avec une extension (bfiles),
J'ai pas essayé bfiles. Par contre, j'ai un fichier binaire conséquent (et qui évolue peu) dans mon repository, et Mercurial se démerde plutôt OK.
> Au niveau de la gestion des droits du dépôt central, ça marche a peu près comme SVN ?
Plusieurs solutions aussi :
- authentification par le serveur http/https, si tu veux pousser par http/https
- authentification par ssh, si tu veux pouser par ssh
Pour ma part, http/https sont en lecture seule, et je pousse uniquement par ssh.
# Lien complémentaire
Posté par ymorin . En réponse à la dépêche ELC-E 2010 : un compte rendu libre !. Évalué à 6.
[^] # Re: Commentaire inutile
Posté par ymorin . En réponse au journal Le projet Debian s’ouvre aux contributeurs qui ne gèrent pas de paquets. Évalué à 2.
+1
Merci Carl !
[^] # Re: et pour le C ?
Posté par ymorin . En réponse au sondage J'indente mon code source avec. Évalué à 2.
Et quelque soit le langage utilisé : shell, awk, C, C++
[^] # Re: Les deux…
Posté par ymorin . En réponse au sondage J'indente mon code source avec. Évalué à 4.
Pas vrai. Tu peux utiliser la variable .RECIPEPREFIX pour changer le préfix des règles :
http://www.gnu.org/software/make/manual/make.html#Special-Variables
Et là, tu commences sérieux à rendre le Makefile pâteux. Déjà que c'est pas simple à lire...
[^] # Re: Zut!
Posté par ymorin . En réponse au journal Facebook se fout de notre gueule.. Évalué à -4.
[^] # Re: LOL, c'est quoi Debian?
Posté par ymorin . En réponse au journal Le concours de popularité de Debian. Évalué à -2.
Et puis, passerait pas, même un vendredi : trop gros...
[^] # Re: Tremble MS !
Posté par ymorin . En réponse au journal FUD Microsoft. Évalué à 9.
Un des premiers jours dans un nouveau taf', j'ai fait une présentation en ASCII art, sous vim, en 80x25 !
Pas la peine de raconter la tête de mes collégues... Catalogué, que j'étais ! :-)
5 ans aprés, ils en reparlent encore...
[^] # Re: BRUB
Posté par ymorin . En réponse à la dépêche Ubuntu 42, la réponse universelle aux besoins de Madame Michu. Évalué à 4.
[^] # Re: Concours ?
Posté par ymorin . En réponse à la dépêche Ubuntu 42, la réponse universelle aux besoins de Madame Michu. Évalué à 4.
Merki, ca m'a fait bien sourire !
Hop, une belle journée !
# Concours ?
Posté par ymorin . En réponse à la dépêche Ubuntu 42, la réponse universelle aux besoins de Madame Michu. Évalué à 8.
Je ne ferai ni éloge ni reproche, n'utilisant pas cette distribution, mais je trouve que tu as bien décrit toutes les nouveautés et évolutions de cette version.
Cependant, quelques pointeurs auraient été les bienvenus (par exemple, pour illustrer le nouvel installeur graphique, un pointeur vers une gallerie de captures d'écran).
Au final, j'ai presque envie d'essayer. Presque ! ;-)
Merci !
[^] # Re: .
Posté par ymorin . En réponse au journal Contre les modes pourries. Évalué à 1.
+1 !
# Merki !
Posté par ymorin . En réponse au journal Debian Live c'est bien. Évalué à 10.
Je tiens à vous faire part de mes plus sincéres remerciements pour m'avoir fait connaître ce merveilleux outils qu'est ce Debian vivant !
Ce petit journal tombe vraiment au poil, juste le soir, ou devrais-je dire la nuit, où je devais préparer une clé USB bootable avec Debian dessus. Vraiment, vous m'ottates une épine du pied /
Veuillez recevoir, cher fleny68, mes plus chaleureux remerciements !
Cordialement,
Moi.
( OK, il est tard, j'ai pété un câble, je --> ZZzz )
( fleny68, quand squeeze sera dispo, tu t'apelleras fsqueze68 ? ;-] )
[^] # Re: et 43, ça marche aussi
Posté par ymorin . En réponse au journal 10/10/10 : le jour de La Réponse Universelle.. Évalué à 1.
[http://fr.wikipedia.org/wiki/La_grande_question_sur_la_vie,_(...)]
[^] # Re: Une bonne idée!
Posté par ymorin . En réponse au journal Les responsables du trousseau de clés de chiffrement de Debian renforcent leurs exigences. Évalué à 4.
Irefvba: TahCT i1.4.10 (TAH/Yvahk)
uDDBNkv5LzZ4kFfkRN/8PfK91iVLPb584Yw8yvDUUQGzEyFvgnN9IMNo8XwEKuyK
SRgzWMPLLlIUemNbFHPyOAYEbNkyYgwTY+8yg5ElfGB7aUaL1hQ9XjGS/Wg/DcbO
N0DMqMUf+P3ALq50G3UlXdCbaTRlWywm6muMvx9CTnnA5bA6/lPL7kiQCsk5vJ1P
dISX0inxIBR6fkSHBz1uN1qZZ3eKXKbaRGTUciZ/P9DvqVGxMIZt+7ULxg9As9KZ
54IXYybj05NknOtIp7GLedBHe4FgoogSrD6VI5z5Nr23qtStZWSsOV6GnWOuYy4Q
Jz9fysj61OZadpCtK80nP502iAXD5xQLihRV79T4cfyD8sJoORdmKOWaceFKrnOz
rZv6xhjie1z/xjs4pCbHS8Tdv85OgwekgZsVWGty52JuZzdp69w7QAm8fI6cegzM
ADEwgzJR3oif+gQvhpBWLIWOQRTT9o0mDMxGe91KBzYFcn2M262RfHu/4Ke5sb6b
yg9VN7+vl6MIjcyjlajvP1RtUtA4tw/lrGbnz77+ei67SzRaOIq7JWrssC34eqiJ
j2jpddtoogcEVQ8s0ANJ8WPbzg2Xd+zLMDMuYPOSAGPpZkKdmFlYkl6+2Wue1qUW
aTDyYwpFimNgsvpGmeMYAKOZMLTHKAYwCeRl37JU2FT9PNRh2QGbZCHm8DcpQtZC
/3l8O9uYY/YJeb6/HTQyNNZCLAFLWEYyRuONNi6pyL4YG3X8a1CwH/QFAKkR1vc2
7Q1oU4ReBs930nMnPTqLHbcVTr574q+BN4loxAAqGA8i5PoyDxFIF2L8Hg7ZdyDa
mZeTWOfXf1MNXTwrAfAyezQDWuNFe6fodLboNzYtQq252YfyBEqc+YbxzsYPryCp
rZVya+bTLDr7dvrZfeTnnniaINipB56rFkr1lTujPEZpTkYLbck0edaiaTBtlV21
5E7hddaM/m1hNCAvlEYnOo/Gbm9ZxvWqSO7xjumu/uCKFPF1CyATpYYww8m9QbWq
9BP44s2PJ4dUjhJUHP8cNVUiObc5efxJQtncq56ADOP4LEIRN3KSqPZuDL+GTLp1
ZNMxe99gik5rdUxz3K+DCT/EG7Ccf7tBJ1JiPvi9hC67F+iAFC89fy+eq836oUIY
Y2WANMJCKCeVmw2gvs48veObvQHmQsH9ZklUzHs9iK/jpDpVyYPpKmDRk57cxOXd
GR+2cc2AXJL0zAtteMOE6AZwo9MweUEpXgeuZWprXdjCZOBgDcwqedPQiUusnNkB
9/CVCb07BLCyWdlXrM3+TKNAWoxIwmtECuaEBHta4xOjio4mtR2LB36fIy8RdyaN
drhtoD3pcY5BjGVaxhcvV0raPTnPcJT/UEFHG/L+0gfs0zZOBEkXmV/3eGZUybTf
RQwpi+4xj4aeRaIgUelj/Xcf0FTA04RfL+k8YWWYA6MDtDLLvWdeZgPd+tu1MzE9
IQ2zefkPMN8f3548chgXKMQ3k96xH41+PbBmJAFx91axBIJ94TH=
=GnJP
-----RAQ CTC ZRFFNTR-----
Tiens, c'est marrant, ce n'est pas plus lisible... ;-P
[^] # Re: Chapi-Chapo
Posté par ymorin . En réponse au journal Définition d'une adresse IP par l'hadopi. Évalué à 5.
http://en.wikipedia.org/wiki/IGMP
Un paquet IGMP (v2!) contient:
- le type : en gros je m'abonne / me désabonne
- le flux que je veux : l'adresse multicast
- un checksum
- et c'est tout.
IGMP n'est _pas_ encapsulé dans IP. IGMP est au même niveau que IP. Donc j'ai dit une petite bêtise en parlant de l'adresse unicast du serveur : il n'y en a tout simplement pas. Pas plus qu'il n'y a d'adresse source de la requete.
Donc, mon explication était peut-être implémentatoire ( qui n'est pas un mot français ! ), mais c'était surtout pour te faire comprendre qu'il n'y a pas d'adresse IP de destination contenant l'IP unicast de l'abonné au flux.
[^] # Re: Chapi-Chapo
Posté par ymorin . En réponse au journal Définition d'une adresse IP par l'hadopi. Évalué à 3.
> Avec une IP unique !
Et bien justement, non !
Les packets multicast ont une adresse de _destination_ qui est, je te le donne en mille... une adresse multicast !
Lorsqu'un routeur voit une requête IGMP passer, il mémorise /juste/ :
- l'adresse du flux demandé
- l'interface d'ou la requête provient
- l'heure du dernier (renouvellement de l') abonnement pour ce flux
Ensuite il propage la requête IGMP vers le routeur suivant, jusqu'au serveur.
A noter, bien entendu que les requêtes IGMP ont une adresse destination (et source?) qui est une adresse unicast, evidemment.
Ensuite, lorsqu'un routeur recoit un packet multicast, il regarde dans ses tables s'il a un abonnement pour ce flux, en ce basant sur l'adresse multicast. S'il n'en trouve pas, alors il droppe le packet. S'il trouve un (ou plusieurs) abonnement en cours, il transfert le packet vers chacune des interfaces ou un abonnement est en cours.
Et enfin, tous les equipements dans le réseau /local/ reçoivent le packet multicast. S'ils sont abonnés (ou espionnent), ils le prennent, sinon ils le droppent.
Donc, nulle part sur le chemin il n'y a besoin de l'adresse unicast de destination.
[^] # Re: Chapi-Chapo
Posté par ymorin . En réponse au journal Définition d'une adresse IP par l'hadopi. Évalué à 4.
Non, et c'est l'interet du multicast. Ca marche comme ca (en gros) :
- un client s'abonne a un flux multicast, et envoie une requete IGMP au serveur de flux
- les routeurs sur le chemin memorisent cette requete
- le serveur emet son flux vers cette adresse multicast
- les routeurs envoient le packaget multicast vers tous les clients qui en ont fait la demande (grace a la memorisation de la requete IGMP)
- le client renouvelle periodiquement son abonnement (par d'autres requetes IGMP)
- a la fin, le client se desabonne du flux (par une autre requete IGMP)
- chaque routeur sur le chemin memorise, et si plus aucun client sur cette interface n'a d'abonnement en cours pour ce flux, le routeur cesse d'envoyer le flux sur cette interface
Comme ca, du cote serveur, un seul et unique packet est envoye, et ce sont les routeurs qui decident de dupliquer sur chacuen des interfaces ou ils ont vu une requete IGMP pour ce flux.