[WARNING / HS]
Allez petite parenthèse technique : j'ai fait un serveur hautes performances sur des sockets "pures" (TCP).
L'idée est simple : je voulais faire un "aspirateur Web". A qui ont donne une "liste d'ordres". Cet aspirateur se voit donner une liste d'ordre par un "Chef". Ce "Chef", lui même, se voit donner une liste immense de sites Web à aspirer par un "Grand Chef" qui centralise tout.
- "Technicos"
- "Chef"
- "Grand Chef"
Il fallait que les "discussions" entre eux soient full TCP, zippées, et rapides.
Je tenais absolument à faire un "Chef" qui affiche en temps réel ce que faisaient les "Technicos".
Je tenais absolument à faire un "Grand Chef" qui affiche en temps réel ce que faisaient ses "Chefs".
Et je voulais que l'application soit parfaitement intégrée.
J'ai donc voulu me servir du coeur même de Windows, basé sur l'asynchronisme : un programme prend 0% de temps CPU, et c'est Windows qui envoie les événements à l'application.
Partant de ce principe, Windows a sa propre gestion des sockets, qui n'a aucun rapport avec le monde Linux (si si très peu de monde le sait, j'y reviens après) : les sockets asynchrones.
Le fonctionnement en gros :
- tu ouvre une socket en TCP et tu lui envoie un callback
- quand le callback tombe, tu analyse ce que le cœur de Windows t'a passé en paramètre :
- soit réception d'une partie de message
- soit validation qu''une partie du message a été envoyée
- soit fermeture de socket (et dans ce cas, analyse énorme du type de fermeture)
Maintenant je t'explique comment tu dois faire le code :
- tu dois réserver tes propres paquets, et avoir ta propre gestion de mémoire pour les concaténer rapidement
- tu dois pouvoir facilement les concaténer, parce que le message que tu as reçu n'est pas forcément complet
- tu dois écrire toi même ton analyse de trame pour savoir le début et la fin de tes paquets
- tu dois gérer les fermetures inattendues de socket (ici, par contre, c'est normal)
Concrètement parlant, tu as un seul callback asynchrone pour faire tout ça, en C++ ou en Delphi (pour ma part c'était en Delphi). Je laisse lire la doc sur WSARecv:
https://msdn.microsoft.com/en-us/lib...(v=vs.85).aspx
Et... allez juste l'introduction :
https://msdn.microsoft.com/en-us/lib...(v=vs.85).aspx
Ah j'ai oublié : en fait toutes les fonction WSA = Windows Socket Asynchrone.
Celui qui me dit qu'on ne peut plus avoir d'écran bleu sous Windows aujourd'hui, je lui fais le pari à la hauteur du montant qu'il veut, que je peux lui faire un écran bleu quand je veux. Pour la note, il suffit juste de travailler au niveau des routines cœur de Windows (et ça, quoique me disent les défenseurs de Windows, faire crasher Linux, et être obligé de rebooter rien qu'en écrivant des routines de lecture/écriture sur des sockets, c'est extrêmement difficile, voire impossible).
Concrètement parlant, je saturais le réseaux en échanges entre le Grand Chef et les 15 PC qui avaient des "Chef" ainsi que deux autres sites qui n'avaient que des Chefs + Technicos, et je n'avais que 2% de CPU utilisé par tous mes programmes : bah oui ils étaient uniquement en attente des retours Windows, et "concaténaient" les messages avant de les décoder et écrire le résultat. Presque tout le temps n'était que de l'attente réseau. Oui oui je pouvais gérer > 20000 connexions simultanées, meilleur que du NodeJS, sous Windows... pas de quoi s'en vanter, tu vas voir pourquoi...
Après avoir passé des semaines entières à écrire un gestionnaire 100% multithreadé, j'ai aussi utilisé les fameux SendMessage() et PostMessage() avec tous les soucis inhérents à mes amis les fonctions soi-disant threadsafe... des semaines entières pour faire tout fonctionner, mais j'y suis arrivé : code propre, lisible, et sur le plan de l'utilisateur, c'était magique : le "Grand Chef", et les petits "Chef", se mettaient dans la tray icon, quand on cliquait dessus on avait un schéma magnifique, plein de petites leds qui s'allumaient pour indiquer l'état de leurs subalternes, quand tu fermais, le message de fermeture était envoyé à tous les "enfants", ceux ci se fermaient "proprement" et coupaient la connexion proprement.
J'ai passé des semaines entières à développer les "Technicos". Aspirer une page Web avec les IndySocket ? Ca fonctionnait bien... mais pour des mini programmes. Quand on aspire des centaines de milliers de pages, ils plantaient très très rapidement... obligé d'écrire des programmes de tests, des programmes de performances et là, personne pour aider : code des Indy totalement pourri, impossible à déboguer, et pour information : la seule suite viable, indestructible, rock-stable et multithread : RTC de DeltaSoft (à l'époque). Et Indy, tous les newbies me sortent "c'est super" et je leur explique que c'est de la merde en boîte mais ils ne comprennent pas parce qu'ils n'ont jamais été aussi loin que moi et mis la main dans le code même... et ont même parfois essayé de me faire passer pour un débutant
Pour information, l'écriture de WSARcv est une fonction qui fait ~4000 lignes de codes en Delphi, impossible à écrire proprement. Impossible. Des switch case gigantesques, la gestion de tous les cas et types de fermeture affreuse (avec des attentes de fermeture), et pire : des fois les lignes TCP sont fermées, mais Windows ne te le notifie pas, tu le sais uniquement lorsque tu tente d'écrire dedans et Windows te rappelle un WSARcv instantané pour te dire que la socket est fermée de manière inattendue ! Imagine la gestion des messages que t'as alloué dynamiquement et que tu dois refaire (c'est là que j'ai appris ce qu'était la gestion avancée pooling pour être performant d'ailleurs).
Et voici la suite :
- je suis arrivé sur Linux et j'ai vu la gestion des socket : ultra bourrine, et dans le bon sens du terme : hop socket() pour ouvrir, send() pour envoyer recv() pour envoyer. En une soirée j'avais ré-écrit les échanges entre deux threads ! Quatre mois contre une soirée !
- sur Linux : fork() et si pid résult = 0 c'est le père (je dis ça de mémoire) sinon c'est le pid du fils. Bam ! En une soirée, ré-implémentation. Ah oui on a les pipes nommés. Bim pipe nommé, on exécute tar, on envoie les 4 premiers octets pour la taille + on lit en tar. En une matinée, ré-implémentation de tout ce qui m'avait pris des semaines entières : Linux a déjà tout de prêt pour ça ! Ecriture du Grand Chef + Chef en moins d'une semaine
- enfin le must du must : wget. J'ai eu le malheur d'apprendre à mes étudiants comment utiliser wget, maintenant il est officiellement interdit à l'IUT . Bah oui wget permet de tout, absolument tout faire lorsqu'on veut aspirer un site. Hop un pipe nommé via exec() et l'aspiration de tous les sites a été faite en une journée. Ecriture du Technicos en moins d'une semaine
- mis en oeuvre de tout ça : un mois.
Pour l'information historique, le système même de Windows et de gestion des sockets est tellement complexe à gérer qu'ils ont copié collé Linux, et c'est pour cela que tu as les sockets bloquantes sur Windows : parce que du point de vue développeur, code, et maintenabilité, c'est affreux de gérer des callback.
Nous n'avons été qu'une centaine de personnes au monde a avoir fait un serveur asynchrone hautes performances sous Windows stable (aux dires des techniciens Microsoft qui s'occupaient de l'écriture du coeur réseau avec lesquels j'ai un peu discuté). Je n'en retire aucune fierté, juste pour dire que, quand j'essaie d'expliquer que par essence même, le principe des callbacks ne permet pas de faire du code maintenable sur du long terme, et que les développeur NodeJS me disent que je ne sais pas de quoi je parle... bref vous voyez où je veux en venir.
--------------
Et si tu veux une raison qui date d'aujourd'hui même de détester Windows, la voici :
- j'ai payé ~100 euros (je ne me souviens plus exactement à l'euro près) pour avoir Windows Vista familiale officielle.
- quand j'ai vu l'immondice que c'était (et je suis poli je trouve), j'ai tout de suite re-payé pour upgrader à Seven.
- j'ai donc une licence officielle, payée
- là j'ai voulu changer la carte mère. L'erreur monumentale à ne pas faire ! Bam ! Windows n'a pas su récupérer ni tout réinstaller
- un ami m'a amené une version Enterprise, comme ça toute l'installation devait se dérouler rapidement sans avoir à taper "suivant" "suivant" "suivant" "suivant"
- je l'ai mise, tout a fonctionné depuis 3 ans
- avant-hier, je lance "cleanmgr" tu connais sûrement, l'outil officiel de Microsoft. Oui, l'outil officiel, développé par Microsoft même
- il me dit qu'il y a 2 To de fichiers à nettoyer, alors que mon SSD fait 250 Go. Je me dis "ça sent pas bon mais comme c'est l'outil officiel, développé par Microsoft même", je valide
- il m'a tout supprimé. TOUT SUPPRIME : Windows, tout Windows, et tout ce qu'il y avait dans mon répertoire User (C:\Users\Olivier). No joke. Y compris presque tous les programmes que j'avais installés (PyCharm, etc)
- heureusement que je fais des sauvegardes, et que j'écris tous mes fichiers importants sur du Linux, parce que ils n'ont pas été effacés, au moins au sent qu'on est dans un monde professionnel.
- j'ai pas fini ! je formatte mon SSD, j'installe Windows 7. Et je compte. Un reboot, 2, 3, 4, 5, 6 reboot. Sans mise à jour hein. J'installe la première mise à jour qui... met à jour le gestionnaire de mise à jour (!) puis reboote. Après cela, Windows 7 service pack 1. Ok, j'installe. Et là : > 200 mises à jour. Oui oui, voici l'écran pour preuve :
Après une journée complète d'installation (oui, une journée), le soir arrive, et je me dis "ok". Dernier Windows update.
Je le lance, et là 45 langues "optionnelles" à installer. C'est un bordel, même dans les mises à jour facultatives. Je me dis "ok j'installe comme ça je serai débarassé".
Je lance les mises à jour hier soir, ça dure toute la nuit, ce matin il me demande à redémarrer.
Je redémarre, et là "installation des mises à jour en cours". Il est resté bloqué de 9h00 à 18h00 en avançant de ~1% par heure.
Il y a une heure de cela il redémarre et voici son message :
Il a donc pris TROIS JOURS pour installer uniquement les mises à jour sur un disque VIERGE et il m'a fait perdre une journée pour rien parce que sur une installation vierge, il n'est pas capable de faire les mises à jour.
Actuellement, je t'écris d'un portable qui était soi-disant bon à la casse, sur lequel,qu'un ami voulait jeter : j'ai mis un SSD à 30 euros, installé MINT et ça fait deux ans que je me ballade avec, je n'ai jamais eu de problème. Jamais. Pourtant j'ai steam, et j'ai testé mes 200 jeux portés sur Linux.
Et tu me demande, sérieusement, pourquoi je n'aime pas Windows ?
Même jusqu'à aujourd'hui il me fait perdre de l'argent, une journée de boulot.
Donc pour résumer, j'ai acheté un tout nouveau matériel que je vais recevoir courant de semaine, 2 disques SSD, avec Windows 10 familial pré-installé (j'ai préféré repayer 138 euros et l'avoir pré-installé, cela me coûte moins cher que revivre des 3 jours totalement inadmissibles d'un point de vue professionnel).
Windows = que pour les jeux, ça fait 15 ans que c'est comme ça et aujourd'hui rien n'a changé, et heureusement que de plus en plus de jeux sont portés sur Linux, car il me tarde le jour où je pourrais me passer définitivement de Windows.
[/ WARNING / HS]
Côté console :
J'espère que tu comprendras aussi que quand on me sort "Microsoft met des couleurs dans sa console", j'ai masse d'arguments, à tous les niveaux, pour me moquer du manque de professionnalisme de cet OS, et que je ne suis pas un "idéaliste" qui rêve de vivre dans un monde libre : je suis un professionnel qui a utilisé un outil qui est beaucoup moins bon qu'un autre et ça s'arrête là : Windows qui m'a fait perdre plein d'argent, point à la ligne.
Toujours pour parler console, quand Microsoft, sort, tout fier, qu'une des grandes nouveautés de Windows, c'est qu'il peut tourner sans carte graphique, en mode console, alors que Linux fait ça depuis toujours, là aussi, j'ai l'impression, ici aussi en tant que professionnel (et pas rageux idéaliste Linuxien), qu'on se fout ouvertement de ma gueule. J'ai dû réinstaller Windows il y a quelques années à cause d'un simple changement de carte graphique (alors que j'ai arrêté de compter le nombre de fois où j'ai pris un disque Linux, booté sur un autre PC sans aucun problème (vas-y fais moi ça avec Windows, en direct live)). Ici aussi : dans le monde professionnel, je n'ai jamais, absolument jamais eu sous Linux les problèmes basiques que j'ai eu avec Windows, et la console Windows reste toujours un scandale, et est toujours à l'âge de la préhistoire comparé à ce qu'on fait sous Linux.
Partager