On peut encore aller le loin... Tout est fichier ! On peut généraliser ce comportement ! On peut aller jusqu'à envoyer toutes les requêtes sur la même boucle d'événement.
Et cette « boucle d'évènement » unique, elle s'appelle... ton noyau. Démultiplexer des « requêtes » selon un sélecteur donné, c'est ce que fait le noyau quand il répartit les paquets reçus du réseau selon l'adresse et le port de destination du paquet (oui, je me suis placé à un niveau « en dessous »). Forcément, quand tu as oublié qu'il existait autre chose que le Web et le port 80, ça peut faire bizarre comme sensation.
Ainsi à chaque IO, on donne éventuellement à une autre requête (ou une autre IO) la possibilité de s'exécuter. On minimise encore le temps d'attente des fils d'exécution. Cette démarche permet de tirer parti des infrastructures du noyau et de tenter de maximiser le temps d'exécution utile du CPU.
Moui... tu viens de décrire l’ordonnanceur du noyau, quoi, qui répartit les tâches entre différents processus représentant différentes applications qui écoutent sur des ports différents, non ?
En fait, la manie du tout-Web a amené de gros anciens SPOF sous forme dispatchers de requêtes HTTP.
Alors imagine quand ton sélecteur est à un offset donné dans ton paquet (= port de destination), facile à parser, qu'en plus en cas de problème de charge tu veuilles pouvoir répartir les requêtes avec l'assistance du client (= adresse IP de destination, obtenue par la base géante clé-valeur qui s'appelle DNS parmi un ensemble façon round-robin avec priorités, autrement appelés enregistrements SRV), ou alors si tu gardes une seule IP mais que tu veux pouvoir faire de la répartition de charge y compris sur ton architecture réseau amont (= flow ID ; seulement en IPv6), tu auras alors l'architecture ultime, distribuée, et qui en plus n'aura pas d'état incrusté dedans (= connexion HTTP ; la connexion n'a de sens que pour nœuds aux extrémités) et qui scalera à mort. Et tu pourras l'appeler « Internet ».
Sans parler de comment tu gères ta file quand elle est pleine, parce que le tail-drop ça fait plus de 20 ans qu'on sait que c'est mauvais.
# Petit joueur
Posté par benoar . En réponse au journal Des vieilles bases d'unix à la hype reactive actuelle. Évalué à 7.
Et cette « boucle d'évènement » unique, elle s'appelle... ton noyau. Démultiplexer des « requêtes » selon un sélecteur donné, c'est ce que fait le noyau quand il répartit les paquets reçus du réseau selon l'adresse et le port de destination du paquet (oui, je me suis placé à un niveau « en dessous »). Forcément, quand tu as oublié qu'il existait autre chose que le Web et le port 80, ça peut faire bizarre comme sensation.
Moui... tu viens de décrire l’ordonnanceur du noyau, quoi, qui répartit les tâches entre différents processus représentant différentes applications qui écoutent sur des ports différents, non ?
En fait, la manie du tout-Web a amené de gros anciens SPOF sous forme dispatchers de requêtes HTTP.
Alors imagine quand ton sélecteur est à un offset donné dans ton paquet (= port de destination), facile à parser, qu'en plus en cas de problème de charge tu veuilles pouvoir répartir les requêtes avec l'assistance du client (= adresse IP de destination, obtenue par la base géante clé-valeur qui s'appelle DNS parmi un ensemble façon round-robin avec priorités, autrement appelés enregistrements SRV), ou alors si tu gardes une seule IP mais que tu veux pouvoir faire de la répartition de charge y compris sur ton architecture réseau amont (= flow ID ; seulement en IPv6), tu auras alors l'architecture ultime, distribuée, et qui en plus n'aura pas d'état incrusté dedans (= connexion HTTP ; la connexion n'a de sens que pour nœuds aux extrémités) et qui scalera à mort. Et tu pourras l'appeler « Internet ».
Sans parler de comment tu gères ta file quand elle est pleine, parce que le tail-drop ça fait plus de 20 ans qu'on sait que c'est mauvais.