Foro - Perl en Español

Hola... bueno pues trato de hacer una aplicación web que al conectar el cliente con el servidor mande X información como si el cliente fuera un sistema multiplexado, es decir que mande mucha información al mismo tiempo:

Pero no será el único mandar() puesto que siguen otros mandar() que se hacen en tiempos diferentes y se tienen que hacer simultáneamente. En otras palabras, multitreading, pero TODO tiene que hacerse en una misma conexión, no se puede abrir otra, es decir, no se puede iniciar otra conexión desde sockets, tiene que ser la misma.
¿Alguna idea?
¿Se puede hacer con fork?

Multiplexar y Concurrencia son conceptos diferentes, que si bien pueden ser aplicados en conjunto son diferentes en esencia.

Sí, con fork puedes hacerlo, cada proceso hijo, haz que chierre todos sus FH's y entonces crea tus conexiones y envía lo qeu tengas que enviar.

Saludos,

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.

Multiplexar y Concurrencia son conceptos diferentes, que si bien pueden ser aplicados en conjunto son diferentes en esencia.

Anoto eso

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.

Bueno, estamos tratando con cliente/servidor de transporte de datos, no sólo archivos también referencias que suceden en tiempo real (literalmente es un controaldor remoto) uso el termino aplicación (depronto con mal uso si se toma literal) por unos libros (uno literatula, el otro del arte del exploit aunuqe realmente mucho sobre redes y no tanto de seguridad).

¿cómo sabrá el servidor a qué fork se corresponde cada petición que le llegue?

Pues... se trabaja con objetos, cada conexión tiene un identificador y cada conexión se trabaja por separado en el servidor, tiene funciones dadas y diferentes.

¿Cómo evitaremos que le lleguen al servidor peticiones mezcladas?

No se hace, es la idea, estoy trabajando una unidad (Je, je unidad que ironico) poco usual, tal como decís se programa más en el cliente que en el servidor en cuanto a red, mi idea del "protocolo" es:
se crea un conexion (clieta a servidor).
En el cliente se transmite multiples comandos Cliente--<>-Servidor.
Nótese: llamo a comando un par de palabras claves para identificar acciones, no comandos de programas
Se fectua una acción.
--------------------------

Se ve muy elemetal pero es que no se como explicar, se tiene que hacer en "multiples conexiones" ya que se harán diferentes cosas al mismo tiempo como pasar archivos y mandar datos de programas corriendo.
La cosa es que la conexión en si es una, el "connect(Socket, ....)' es uno, un filehandle, un puerto pero multiples peticiones.
Cuando me trato de imaginar solo veo una petición esperando a que la otra termine.
Quizá no me expresé bien, realmente es una conexión que manda muchos "deseos".