28/05/2004, 09:43
|
| O_O | | Fecha de Ingreso: enero-2002 Ubicación: Santiago - Chile
Mensajes: 34.417
Antigüedad: 22 años, 3 meses Puntos: 129 | |
| Si te fijas como es la estructura de tu aplicación veras que tienes:
1 Servidor N clientes conectados a el ... El servidor es el que recibe "peticiones" y este entrega el resultado de la petición al cliente que lo pide .. Por lo mismo, todo está "centralizado" en el "Servidor" y . .si deseas propagar un dato a tus clientes conectados -debes- hacer que estos "lo pidan" (refrescando automáticamente sus clientes: navegadores en este caso).
La técnica del "Remote Scripting" no es más que el típico "refresco" pero con el "truco" de usar iframe's ocultos y mucho javascript por médio para "devolver" el dato a la página "padre" que en teoría es quien lo pide (a traves de ese "iframe" y el juego que se hace con javacript)...
Ahora .. En tu servidor ... puedes llevar el control de los clientes "conectados" (por IP) y si esos clientes tienen algún software que "escuche" en cierto puerto (y bajo su IP) .. podrías enviarle un dato desde el servidor (a cada "petición" .. generárías el envio de datos a esos "IP's" puertos) .. Todo esto por "sockets" (desde PHP: fsockopen() y funciones afines) .. Pero esto depende de la parte "en el cliente" que supongo que se podrá implementa con un Applet java o bien con algún ActiveX (tal cual lo hacen los clientes IRC basados en Applet Java). De esta forma .. el "tráfico" de datos sería el dato en sí .. no tanto como una página completa (caso de refresarcala) o bien algo menos si usas "remote scripting" .. pero el hecho de tener que estar "pidiendo" constantemente para simular una "espera" de datos no es lo recomendable.
Un saludo, |