Puedo puedo recibir y redirigir http con Free Pascal bajo Linux ?

[rolandoj]

Hola,

Gracias por los datos complementarios.

Con respecto a las máquinas virtuales, ese es exactamente el esquema que se va a implementar. Concretamente, tendremos 2 máquinas físicas y 4 virtuales usando VMWare. 3 de ellas con Linux y la otra con Windows Server

Lo de CGI, la verdad me asaltan serias dudas. Bajo Windows, aún cuando reconozco que es un mecanismo más robusto contra fallas, lo deseché desde un principio porque cargar y descargar programas cada vez que haya que ejecutar algo es muy ineficiente. Por eso siempre he usado ISAPI.

En nuestro caso, el paso por Linux es conceptualmente muy simple; pero, el número de usuarios, si bien no es notable, tampoco es trivial (arrancaremos con más de 40 y probablemente estaremos cerca de los 100). Cada petición en sí, tampoco lo sería; ya que a muy a menudo contendrán estructuras grandes y complejas, en especial, aparte del manejo normal de registros de tablas de Bases de Datos, se espera fuerte tráfico de documentos completos, que deben almacenarse y leerse desde el servidor, y desde locaciones remotas. Agregale a esto que toda llamada pasa por un proceso de encriptamiento.

Lo de depurar, la verdad tampoco me preocupa mucho. El Linux es solo un preprocesamiento con un algoritmo corto; probablemente ni siquiera necesite depurar. Ahora, hablando en general; yo uso ISAPI con Delphi 2007 en Windows y la verdad salvo una que otra cosa, más que todo cuando estaba haciendo mis primeros experimentos con esas tecnologías, nunca he tenido problemas para depurar.

De todas formas, veo que se ha levantado el interes por el tema, así que espero que sigamos intercambiando información. Creo que el uso directo de http con Lazarus puede ser un recurso muy potente para explotarse con Linux. De momento, debido a metas de producción, no puedo dedicarle mucho tiempo; pero, ya lo tengo en la mira.

Saludos

[mamcx]

Empezado por rolandoj

Lo de CGI, la verdad me asaltan serias dudas. Bajo Windows, aún cuando reconozco que es un mecanismo más robusto contra fallas, lo deseché desde un principio porque cargar y descargar programas cada vez que haya que ejecutar algo es muy ineficiente. Por eso siempre he usado ISAPI.

Ese es un mito muy comun. Pues resulta que fastcgi y demas es lo mismo (se lanzan procesos por cada request, aunque normalmente se reciclan procesos y todo eso y se tiene un limite). La gracia de los módulos en proceso (dll) es mas evidente en los lenguajes interpretados (php, python, .net) ya que hay que cargar el run time y ademas procesar la petición, o para soportar un pool de conexiones a una BD. Pero un lenguaje compilado, procesamiento directo? No tanto.

Cualquier OS, windows incluido, maneja de forma eficiente todo eso. Windows no carga todos los bytes d elso exe que se cargan frequentemente, hay optimizaciones para todo eso. Pa rematar lo que comentas parece que es un proceso tan simple que la carga & descarga seguramente sera muy rapido (y posiblemente mas en linux).

Ahora si como dices lo tuyo es tan simple pues si, puedes hacerlo como un modulo si asi lo deseas. Da igual.

[rolandoj]

Hola,

Interesante lo que dices; pero, me entran dudas porque, al menos aparentemente, la valoración del aspecto principal no coincide con la información que tengo desde hace mucho. Para claridad de cualquier otro que consulte este hilo, detallo lo que sé;

En Windows, la idea de la tecnología ISAPI (y de NSAPI, su contraparte Netscape) es que el DLL se carga en memoria cuando su efectua una primera petición de sus servicios. De ahí en adelante, el DLL permanece en memoria; de tal forma que cualquier nueva petición no implica leer otra vez el DLL desde disco. El DLL solo será descargado automáticamente de memoria bajo 3 circunstancias:

1. Cuando ocurra un error realmente crítico

2. Cuando el tiempo de inactividad transcurrido (tiempo sin recibir una nueva petición), exceda un límite de tolerancia establecido

3. Cuando se descargue el servidor (IIS, Apache, etc)

Este es el esquema más rápido posible en términos de consumo de recursos por parte del aplicativo en sí. Su debilidad es la posibilidad de que, por errores de programación, una petición con errores provoque un desastre mayor ya que los recursos se están compartiendo (por ejemplo, que una petición no libere recursos; con el tiempo puede agotar los disponibles). Las versiones más nuevas de IIS han incorporado mecanismo de aislamiento de procesos para atacar esa debilidad

En el caso de los lenguajes interpretados, que se apoyan en tener un DLL ISAPI para su interpretación, como bien dices, hay un paso extra, ya que primero les toca traducir los comandos. La conclusión es que enviando el comando directamente a un ISAPI propio compilado, tiene que ser más rápido. Por ello, no entiendo porque tu duda al decir :

Pero un lenguaje compilado, procesamiento directo? No tanto.

Ahora. en el caso de los CGI, la idea es que la respuesta a la petición la brinda un ejecutable. El ejecutable se carga en memoria cuando se recibe la petición y se descarga cuando esta termina. Ciertamente, en términos de seguridad es mejor esquema, ya que cada petición queda completamente aislada y sus recursos se liberan enseguida.

Sin embargo, en términos de efeciencia es muy pobre comparada con la solución anterior, ya que el consumo de recursos, aún con el apoyo del caché, es mucho mayor, especialmente con conexiones a bases de datos, ya que en cada carga se inicializa sesión. Por supuesto, depende de las capacidades del hardware disponible y del tamaño del sistema que se desee emplear. En sistemas pequeños y con un buen hardware de respaldo, no se notarán mayores diferencias.

En mi opinión, el CGI se justifica como alternativa segura. También, en el pasado, como un mecanismo más facil de depuración; pero, con las herramientas más modernas de Delphi 2007, no le veo mayor peso, ya que depurar los DLLs ISAPI es facil