Samuel Thibault a écrit 192 commentaires

> Euh et c'est la faute de linux ca?

Ce n'est pas parce que mon disque dur externe se débranche de manière inopinée que le noyau a le droit de crasher...

Tu as bien de la chance que ton USB ne se vautre pas. J'ai régulièrement des problème avec l'USB. D'autre part, quand j'allume ma lampe, ça perturbe un peu l'alimentation de mon disque externe, qui fait alors un reset... et crashe mon noyau au passage avec un déréférencement de NULL... Bien sûr qu'un système qui ne crashe pas c'est mieux. Mais ce n'est pas pour rien qu'à la base on a fait des séparations user/noyau, processus/processus, etc. Il est aussi à noter que beaucoup de bugs inexplicables et rarement corrigés dans Linux sont des problèmes de débordements entre un driver et autre chose...

Heu, X est déjà intégré. Les problèmes essentiels actuellement, c'est le passage de X vers du KMS et DRI obligatoires. Et quand bien même X serait remplacé par autre chose, le problème de portage de cet autre chose, c'est justement ces morceaux de drivers qui auront été redispatchés.

L'objectif reste d'avoir quelque chose d'utilisable. Il se trouve que quelques développeurs l'utilisent comme plate-forme d'expérimentation, et d'autres développent dedans notamment parce qu'il reste des choses pas trop dures à faire et qui permettent de se donner de l'expérience, cf le gsoc sur la gestion mémoire (au contraire de Linux, où c'est extrêmement difficile de travailler dans la gestion mémoire). Personnellement, des choses en-dehors du Hurd m'ont aidé pour développer des choses dans le Hurd, et des choses que j'ai développées dans le Hurd m'ont ensuite été utiles en tant que savoir-faire en-dehors du Hurd (bricoler dans la glibc, le support TLS, Xen, ...)

Il est à noter par exemple que minix compte nécessite une IPC pour _chaque_ opération in/out, plutôt que laisser le processus faire ses in/out après demande ioperm().

Relis la partie DDE.

Ils sont incessants, oui, mais ce n'est rien comparé à la lenteur d'un disque ou d'une carte réseau, même SSD. Il faut que ce soit bien pipeliné pour garder un bon débit, c'est tout.

À propos du module FUSE fuse.xml, GNU/Hurd a un translator xmlfs depuis 2006 :)

Il y a justement un protocole d'évitement de conflit.

Oui, sauf qu'avec ipv6, comme tu connais la vraie adresse IP, tu peux faire du splicing: des deux côtés on lance la connexion vers l'autre, et le routeur accepte alors la connexion, puisqu'il voit bien arriver un paquet venant de l'extérieur correspondant au paquet qui vient de l'intérieur.

> > De manière complètement transparente pour tous les protocoles existants ?
> En même temps, le protocole s'est un peu comme l'algo d'un programme, tu peux le faire en complexité log n ou e^n.

Heu, et alors ? Le problème, c'est qu'il y a pas mal de protocoles qui encodent l'adresse IP à laquelle il faut se connecter dans leur flux. Il y a des modules conntrack pour faire du NAT pour ftp, h323, irc, pptp, etc. et même sip (voir les nf_nat_*) mais à chaque fois il faut le bricoler et ça n'est en aucun cas générique.

> SIP n'est pas d'adapté à la réalité des réseaux actuels. Il le sera peut être plus adapté à l'avenir avec IPv6.

C'est la réalité des réseaux qui a changé. Avant que le NAT se généralise, il n'y avait pas de tel problème.

> L'arrivé d'IPv6, ce n'est pas pour tout de suite. Il vaut mieux trouver des solutions alternatives en attendant.

Si les gens avaient un brin anticipé les choses, on n'en serait pas là, surtout. Ces solutions alternatives, c'est essentiellement du bricolage qui marche mal, et qui ne fait que laisser les gens croire qu'il n'y a pas de problème, et repousser encore plus le passage à IPv6, jusqu'au jour où on n'aura vraiment plus ni IPv4 ni port de libre du tout, et là ouille. Ça m'étonne que jusqu'ici personne n'ait fait le rapprochement avec la fin du pétrole.

Mais le wifi peut très bien tomber en rade pendant toute ces minutes, y compris au-delà de la période de maintient de l'entrée dans la base du serveur dhcp !!

Tout ce dont j'ai parlé, ce n'est pas des hypothèses, c'est du vécu, et qui m'enquiquine vraiment.

(et oui, TCP peut garder des connexions actives plus d'une minute)

Merci pour ce magnifique cours, mais je n'en avais nullement besoin.

D'abord, ce n'est pas parce que _une_ machine cliente bittorrent est limité à 65000 ports qu'on peut se permettre de reporter la même limitation sur le routeur en utilisant du NAT: avec du NAT, c'est _l'ensemble_ des machines derrière le routeur qui est limité à 65000 connexions. Et là ça peut rapidement devenir gênant, si les ISP se retrouvent à devoir NATer des centaines de clients derrière une même IP parce qu'ils n'en ont plus, il n'y a plus assez de ports non plus !

> L'algo du NAT, ce n'est pas compliqué.

Bwahahahahahaha. De manière complètement transparente pour tous les protocoles existants ? Le scénario que tu décris, c'est effectivement le cas facile: pour l'UDP sortant vers un serveur qui a sa propre IP publique, où il n'y a pas établissement d'autres connexions.

Maintenant, moi je veux faire de la téléphonie entre deux machines. Manque de bol elles sont toutes les deux NATée. Eh bien on est juste coincé: déjà il faudrait déterminer l'adresse IP publique sous laquelle on est NATé pour pouvoir indiquer à l'autre vers quelle IP envoyer ses datagrammes, mais en plus il faudrait deviner quel port le routeur a utilisé pour masquerader mes paquets sortant... Sans intermédiaire, c'est juste pas possible.

Non, les baux dans un aéroport etc. sont typiquement très courts (vraiment).

Teuteuteu, si je n'étais pas _obligé_ de faire du NAT, je n'aurais pas besoin d'avoir une machine capable de une machine capable de suivres des milliers de connexions en parallèle. Une bête carte réseau complètement stupide qui sait juste router selon l'ip et filtrer selon quelques règles triviales, et c'est marre (et ça consomme moins).

Pour ce qui est d'utiliser TCP pour faire du SIP, j'ai justement posé ça comme question à mon examen de réseau. Pourquoi ça ne marche pas bien ? Parce que le client n'a alors _aucun_ contrôle sur la gestion de flux. S'il y a quelques paquets perdus, TCP va essayer de retransmettre etc. et faire patienter l'application. Alors bien sûr il y a la solution "je tamponne". Super pour discuter, d'avoir quelques dizièmes de secondes de décalage... Pour du téléphone on veut du temps _réel_. Pour ça rien de tel qu'UDP, qui garantit à l'application d'obtenir réellement la latence du réseau, sans surcouche. Avec un codec bien senti, les pertes de paquets s'entendent à peine.

Dans ce scénario-là, je ne parle pas de mon propre réseau wifi (j'ai une bonne couverture dans mon petit appart), mais d'un réseau public (fac, café, aéroport, etc.), et là pas moyen d'aller gentiment demander à l'admin de faire une association statique...

Et donc ça ferait du bien à tout le monde si les navigateurs arrêtaient de donner des tonnes de détails, on aurait peut-être enfin des sites portables (potables?).

Les "problèmes inattendus", ce sont essentiellement les bricolages à droite à gauche. Le problème d'échelle, c'est essentiellement la diversité de craderies mal testées ici et là.

Il me semble qu'il y a des propositions (voire des implémentations) de ça au niveau DNS. Du coup tu peux choisir vers quoi tu le fais pointer.

> En plus ça générerait de l'économie.

YES ! Ça c'est très bon ! Ah bah oui, on va créer de la valeur venant de nul part, comme ça on va pouvoir spéculer comme des porcs sans se demander d'où sort l'argent qu'on encaisse !!

Oui, c'est le bordel: mon routeur perd les pédales quand je fais du bittorrent parce que je suis obligé de faire du NAT. Le téléphone sur IP marche mal (on ne peut pas facilement m'appeler) parce qu'il faut percer le NAT. Quand le wifi tombe et revient, puisqu'entre-temps j'ai changé d'IP, et malgré les efforts de TCP, j'ai perdu toutes mes connexions actives. On peut continuer assez longtemps sur ce registre.

De pouvoir basculer du réseau ethernet de mon premier labo au wifi de l'université, puis au réseau wifi de mon autre labo, puis au réseau ethernet de mon autre labo, sans perdre mes connexions ssh, irc, etc. Oui, c'est vraiment relou de perdre ses connexions ssh juste parce qu'on va à une réunion, par exemple.

Et donc ce n'est pas plus intrusif que l'IPv4. CQFD.

IPv6, il l'est, ça fait des plombes que c'est testé à grande échelle etc.

Ceux qui ne sont pas prêts, ce sont essentiellement les FAIs grand public.

Non, c'est parce que les opérateurs ne peuvent rien faire tant que le bazar côté client final n'est pas au point. Et ceux qui en sont en charge refusent de faire leur boulot.