Téléchargement portunusd - Téléchargement du code source portunusd

portunusd

Autres catégories

Acuminatus

Télécharger

Portunusd

Tweets de la feuille de route des documents de caisse

portunusd est un serveur d'applications réseau inspiré du relayd d'OpenBSD et de Heirloom Unix inetd . Il écoute une connexion réseau entrante, transmettant les données entrantes sur une porte Illumos à l'application prévue et renvoyant la réponse de manière similaire. portunusd mappe chaque port connecté à une porte du système de fichiers fourni par l'application cible.

 séquenchestre
    client de participant
    participant Portunusd
    porte de la participant
    application des participants
    Application - >> Porte: Créer /var/run/app.door
    Portunusd - >> PORTE: ouverte
    Portunusd - >> PortuNUSD: Écoutez sur le port 80
    Demandes de manche en boucle
        Client - >> + PortuNUSD: Envoyez la demande HTTP
        PortuNUSD - >> + Application: demande avant via Door_Call
        Application - >> - PORTUNUSD: Envoyer une réponse via Door_return
        PortuNUSD - >> - Client: Envoyer une réponse HTTP
    fin

L'objectif principal de portunusd est de faciliter la mise à l'échelle des applications unique. Dans le cadre du modèle inetd , un nouveau processus est créé pour gérer chaque demande. En tirant parti des portes, portunusd ne peut créer un nouveau thread dans le processus d'application que lorsqu'une nouvelle marque Highwater de concurrence a été atteinte; Sinon, les threads existants seront réutilisés pour gérer les demandes ultérieures.

Déclaration de problème

Nous voulons que nos applications orientées réseau évoluent en fonction de la demande des utilisateurs. Nous voulons minimiser le coût des ressources de nos applications lorsqu'ils sont inactifs, et nous voulons garder nos coûts linéaires en termes de demande. Nous voulons minimiser le degré auquel le développeur d'application est responsable de la gestion des ressources, et nous voulons conserver (dans la mesure du possible) l'environnement de développement familier des outils de ligne de commande UNIX.

Prendre des rails à titre d'exemple, une application Ruby on Rails à thread unique peut gérer une demande utilisateur à la fois. Plusieurs demandes simultanées ne peuvent pas être traitées sans plusieurs copies de l'application résidant en mémoire (sur des interprètes rubis séparés). Ce modèle consomme beaucoup de mémoire même lorsqu'il y a peu de demande des utilisateurs, ce qui rend difficile pour l'hôte d'exécuter d'autres charges de travail. Beaucoup de pagination et de grincement du disque s'ensuivront.

Des environnements tels que Node.js traitent de ce problème en rendant l'asynchronicité plus transparent pour le programmeur. Bien qu'il puisse être utile d'adopter la nature asynchrone des ordinateurs, il a également introduit des changements dans les langues qui le soutiennent; Ce n'est pas un simple changement de syntaxe, mais aussi un changement non trivial du modèle mental que l'on utilise pour lire, écrire et comprendre les programmes.

À l'autre extrémité du spectre, les applications CGI nécessitent un processus unique et un espace d'adressage pour chaque demande. Ces applications peuvent évoluer linéairement avec la demande des utilisateurs, y compris la réduction de la réduction de la mémoire / utilisation de la mémoire du processeur en cas d'inactivité, mais le coût d'invoquer execv(2) pour chaque demande peut entraver le débit.

L'approche postmoderne "sans serveur" satisfait à ces critères, mais au prix de l'abandon du système d'exploitation . Il s'agit d'une approche extrêmement inconnue pour développer des logiciels et jette de nombreux outils qui pourraient être utilisés pour observer et déboguer l'application à l'exécution.

Thèse

Les portes permettent un nouveau modèle (ancien?) Du développement d'applications réseau dans lequel les développeurs sont responsables de la maintenance et de la compréhension d'une tâche synchrone linéaire, tandis que le système d'exploitation + serveur Web travaille ensemble sur le problème de mise à l'échelle

Lorsqu'une application est inactive, une seule copie de est nécessaire en mémoire.
Lorsqu'une demande entre dans le système, elle peut être gérée par un thread existant.
Les nouveaux fils ne sont créés que lorsqu'un nouveau pic de concurrence est atteint.

Ces qualités nous permettent de résoudre notre énoncé de problème en développant des applications de réseau qui ressemblent à des outils de ligne de commande UNIX à thread unique, présentent une dépense minimale lorsqu'il est inactif et à l'échelle linéaire sur une granularité par réflexion.

Bien sûr, les portes à elles seules ne géreront pas la mise à l'échelle à travers la limite d'une seule instance de système d'exploitation, mais une collaboration de style relayd avec le pare-feu pourrait faciliter cela, en supposant que des copies de l'application sont disponibles sur plusieurs hôtes. C'est là que portunusd entre en jeu.