Descarga portunusd - Descarga del código fuente portunusd

portunusd

Otras categorias

Acuminatus

Descargar

Portunusd

Tweets de hoja de ruta de cajas documentos

portunusd es un servidor de aplicaciones de red inspirado en relayd y Heirloom Unix inetd de OpenBSD. Escribe una conexión de red entrante, reenvía los datos entrantes sobre una puerta de Illumos a la aplicación prevista y devuelve la respuesta de manera similar. portunusd mapea cada puerto conectado a una puerta en el sistema de archivos proporcionado por la aplicación de destino.

 secuencediagram
    cliente participante
    Participante Portunusd
    puerta participante
    solicitud de participante
    Aplicación->> puerta: create /var/run/app.door
    Portunusd->> Puerta: Abierto
    Portunusd->> Portunusd: Escuche en el puerto 80
    Solicitudes de mango de bucle
        Cliente->>+Portunusd: Enviar solicitud HTTP
        Portunusd->>+aplicación: reenviar solicitud a través de Door_call
        Aplicación->>-Portunusd: Enviar respuesta a través de Door_return
        Portunusd->>-Cliente: Enviar respuesta HTTP
    fin

El objetivo principal de portunusd es facilitar la escala de aplicaciones de un solo subproceso. Según el modelo inetd , se crea un nuevo proceso para manejar cada solicitud. Al aprovechar las puertas, portunusd puede crear un nuevo hilo en el proceso de aplicación solo cuando se ha alcanzado una nueva marca de concurrencia de alta agua; De lo contrario, los subprocesos existentes se volverán a usar para manejar las solicitudes posteriores.

Declaración del problema

Queremos que nuestras aplicaciones orientadas a la red escala según la demanda del usuario. Queremos minimizar el costo de recursos de nuestras aplicaciones cuando están inactivos, y queremos mantener nuestros costos lineales en términos de demanda. Queremos minimizar el grado en que el desarrollador de aplicaciones es responsable de la gestión de recursos, y queremos retener (en la medida de lo posible) el entorno de desarrollo familiar de las herramientas de línea de comandos UNIX.

Recogiendo rieles como ejemplo, una aplicación Ruby on Rails en rieles puede manejar una solicitud de usuario a la vez. No se pueden manejar múltiples solicitudes simultáneas sin múltiples copias de la aplicación residente en la memoria (en intérpretes rubí separados). Este modelo consume una gran cantidad de memoria incluso cuando hay poca demanda de los usuarios, lo que dificulta que el host ejecute otras cargas de trabajo. Se producirán mucha paginación y resumen del disco.

Entornos como Node.js tratan este problema al hacer que la asynchronicity sea más transparente para el programador. Si bien puede ser útil adoptar la naturaleza asincrónica de las computadoras, también ha introducido cambios en los idiomas que lo respaldan; Este no es un mero cambio de sintaxis, sino también un cambio no trivial al modelo mental que uno usa para leer, escribir y comprender programas.

En el otro extremo del espectro, las aplicaciones CGI requieren un espacio de proceso y dirección único para cada solicitud. Estas aplicaciones pueden escalar linealmente con la demanda del usuario, incluida la reducción de uso de memoria cero / CPU cuando está inactivo, pero el costo de invocar execv(2) para cada solicitud puede obstaculizar el rendimiento.

El enfoque "sin servidor" posmoderno satisface estos criterios, pero a costa de abandonar el sistema operativo . Es un enfoque tremendamente desconocido para desarrollar software y descarta muchas herramientas que podrían usarse para observar y depurar la aplicación en tiempo de ejecución.

Tesis

Las puertas habilitan un nuevo modelo (¿antiguo?) De desarrollo de aplicaciones de red en el que los desarrolladores son responsables de mantener y comprender una tarea lineal y sincrónica, mientras que el sistema operativo + servidor web trabaja juntos en el problema de escala

Cuando una aplicación está inactiva, solo se necesita una sola copia de la memoria.
Cuando una solicitud ingresa al sistema, puede ser manejado por un hilo existente.
Se crean nuevos hilos solo cuando se alcanza un nuevo pico de concurrencia.

Estas cualidades nos permiten abordar nuestra declaración del problema desarrollando aplicaciones de red que se sienten como herramientas de línea de comandos de UNIX de un solo hilo, presenten un gasto mínimo cuando está inactivo y se escala linealmente en una granularidad por solicitud.

Por supuesto, las puertas por sí solas no manejarán la escala en el límite de una sola instancia del sistema operativo, pero una colaboración de estilo Relayd con el firewall podría facilitar esto, suponiendo que las copias de la aplicación estén disponibles en múltiples hosts. Aquí es donde entra portunusd .