Foro - Perl en Español

Aplicación web tiene hoy en día muchos significados. Anteriormente quería decir que el cliente hacía una solicitud y el servidor se la daba. De hecho, eso es lo que sigue ocurriendo en la inmensa mayor parte de los casos, cuando pedimos una página web.

Cuando dices que se conecte el cliente al servidor y éste mande mucha información, eso no servirá para los servidores actuales del protocolo HTTP, que sólo están preparados para servir una única conexión cada vez. Incluso si el servidor tiene activa la opción 'keepalive', seguirá sirviendo todos los ficheros en ese conexión a medida que vaya recibiendo peticiones, pero desconectará al cabo de unos segundos en cuando se terminen esas conexiones.

Supongamos que no estamos hablando de un servidor web, sino que se trata de una aplicación en el lado del cliente que se conecta a un servidor preparado por nosotros.

Ahora viene otro problema. Si usamos fork para crear varios threads, los cuáles van a compartir las salidas y entrada estándares (entre ellas las asociadas al objeto Socket si lo estamos usando), ¿cómo sabrá el servidor a qué fork se corresponde cada petición que le llegue? ¿Cómo evitaremos que le lleguen al servidor peticiones mezcladas? Es necesario un protocolo y un árbitro, sobre todo desde el lado del cliente. Y aún así será difícil llevar un control de los buffers de entrada y salida del socket.

Hay algunas situaciones en las que es necesario un cliente de este tipo. Pensemos en el caso de un usuario que se conecta a una página web y se baja un applet de Java. Éste abre una conexión socket con el servidor, en otro puerto distinto al 80, donde estará escuchando el servidor apropiado para esto. El usuario comienza a interactuar con el cliente. Dentro del cliente, hay procesos que se inician por petición del usuario pero además hay otros procesos que se originan por término de ejecución de procesos arrancados antes o por haber terminado un temporizador. Por ejemplo, una aplicación gráfica. El usuario pide descargar una imagen y esto lleva un tiempo. Cuando termina, informa al usuario, pero mientras tanto le permite seguir interactuando con el resto del programa. O mandar procesar una imagen ya bajada, etc. etc.

El diálogo con el servidor hay que realizarlo mediante un protocolo para que los mensajes que pide el usuario no se mezclen. La mayor parte de las veces se resuelve mediante un sistema de buffer de mensajes. El usuario da órdenes al cliente y éste convierte alguna de estas órdenes en un mensaje que hay que enviar al servidor más una retrollamada que hay que ejecutarse cuando ese mensaje sea procesado y/o terminado. El mensaje primero se almacena en el buffer de mensajes y luego, otro procedimiento que es el que habla directamente con el servidor, se encarga de enviar esos mensajes uno a uno, y de recoger las respuestas. Es algo así como el funcionamiento de un FTP. Se encarga además de repetir el comando si se ha recibido mal o ha habido un corte en la transmisión. El usuario siempre tiene a la vista una serie de iconos o minicaja de diálogo informándole de los procesos y mensajes pendientes. Yo he manejado algunos programas así, el año pasado, hechos por la agencia espacial europea.

Otra forma de resolverlo es parecido a como lo resuelve el FTP: hay un diálogo entre cliente y servidor para la ejecución de comandos, pero cuando se trata de enviar ficheros, se hace una petición nueva al puerto ftp-data. El servidor responde con una nueva conexión socket y se realiza la transmisión por ese nuevo medio.

La forma más fácil sigue siendo haciendo múltiples peticiones a un determinado servidor, en un puerto. Algo así como lo que han sido siempre los cgi, y como es ahora toda la tecnología Ajax. Pero por cada petición hay una nueva conexión socket.