Mensajes Broadcast vía UDP entre varias instancias corriendo en una misma máquina
Cuanto tiempo sin aparecer por aquí !!! :o
Saludos a todos en primer lugar. Necesito de nuevo una ayudita. Mi aplicación funcionaba perfectamente en red local con varios ordenadores, basándome en comunicaciones con TIdUPDServer y TIdUPDClient para enviar mensajes e información de un puesto a otro. Necesito que sean comunicaciones UDP porque no necesito contestación obligatoria sino que lanzo (Broadcast) mensajes y los demás si lo escuchan, actualizan información que el puesto que envía el broadcast está informando que ha cambiado. Todo eso funcionaba perfectamente hasta que a algunos clientes se les está ocurriendo (para bien) montar la aplicación en servidores virtuales y accediendo con Escritorio Remoto. En este caso, tengo múltiples instancias de mi aplicación corriendo a la vez en la misma máquina, y no puedo abrir el puerto UDP que haya asignado en dos instancias diferentes DENTRO DE LA MISMA MAQUINA. Y ahí es donde empiezan mis problemas de comunicación entre aplicaciones .... Cómo se podría resolver elegantemente, teniendo en cuenta el hecho de que realmente no necesito comunicación TCP, ya que como indicaba, lanzo 'broadcast's' para que los programas que estuvieran activas pudieran tomar una actuación determinada ? Qué otra solución habría que no fuera utilizar los componentes de Indy y basarme en cualquier otra estructura ? Gracias una vez más a todos por vuestros comentarios. Saludos |
Cita:
No conozco la solución a tu duda :( |
Hola gluglu,
Te respondo de lo que encontré en internet. Al parecer podrias usar Named Pipes o Sockets Sockets: MultiCast Messages to multiple clients on the same machine Named Pipes: Named Pipes unit for Delphi Cita:
|
Cita:
Se supone que cada servidor virtual tiene su propia dirección IP, suponiendo que estemos hablando de vmware esx server o cosas así. Si en una misma maquina hay, por ejemplo, dos conexiones con escritorio remoto, cada una de ellas será a una maquina virtual distinta, con distinta ip, y eso no son instancias diferentes en la misma maquina, sino en distintas, aunque sean virtuales. Por tanto no necesitarías tocar nada de tu aplicación. A no ser que te refieras a otra cosa, claro. Un saludo! |
Gracias a todos por vuestras respuestas.
Movorack : Ya había visto todos esos links antes de postear aquí pero no me dan la solución que necesito. Julián : Efectivamente, eso pensaba yo también. Pero no es así. Cuando en una segunda instancia (o sucesivas...) el programa intenta de nuevo abrir el puerto que está configurado, me da error indicando que es puerto ya está en uso. Independientemente de que fuera un servidor virtual de una manera u otra, también tengo varias instalaciones funcionando así en Windows Server 2003/2008. Creo que esta última máquina virtual que comento estaba montada con Server 2008. En todos los casos, el error es el mismo. Además incluso, teniendo ya esta oportunidad, he configurado varias máquinas con Windows XP o W7 para acceso por escritorio remoto. El problema viene a ser el mismo. Puede haber dos o más instancias que se estén ejecutando a la vez, sobre el mismo servidor, con sesiones remotas, y no me permite abrir el mismo puerto en dos instancias diferentes simultáneas. El sistema que tengo montado, se basa (entre otras funcionalidades) que todo el mundo puede avisar a todo el mundo, sin que se establezcan protocolos TCP concretos, por eso utilizo UDP. Y además incluso hay dos programas diferentes (que pueden correr en la misma máquina) que también se comunican a través de UDP. Respecto de los dos programas diferentes lo tenía perfectamente resuelto con 2 puertos diferentes, y así no hay conflictos. Pero claro, esa es la cuestión. Que cuando es una misma máquina, sí que me aparecen conflictos. Gracias de nuevo |
A bote pronto se me ocurre que puedes usar memoria compartida (shared memory) para poner en ella "el mensaje". Y que las otras aplicaciones, mediante un temporizador (timer) o un hilo alterno (thread), consulten constantemente el contenido de ese bloque de memoria compartida.
Por cierto, ¿qué versión de Delphi usas? Fuera de tema: Es un gusto verte de nuevo en los foros gluglu. :) ^\||/ |
Gracias de nuevo también por los mensajes de satisfacción por verme de nuevo por aquí ! :rolleyes:
La solución de la "memoria compartida" también la he pensado pero tendría que hacer alguna consideración adicional para saber si en un caso debo de utilizar una opción y en otro caso, otra opción. Aun así, realmente tampoco es la solución definitiva porque incluso se podrían dar (y de hecho se dan) instalaciones con redes locales donde a uno de los equipos se conectan mediante escritorio remoto y ejecutan una segunda instancia, por lo que es complicado llevar el control de todo ello, compaginando ambas opciones de solución. Incluso había pensado en una solución más 'trivial' que es que cuando haya que mandar un mensaje por UDP, se lleve un 'control' (por ejemplo por la base de datos que es compartida) de los diferentes puertos UDP (uno por cada 'instancia') que están 'activos' y mandar el mismo mensaje en un bucle a todos los puertos UDP que estén configurados. De esta manera en una red local, cada puesto tendría el mismo puerto UDP, pero en una máquina con escritorio remoto, habría dos puertos UDP diferentes, y de esta manera, en realidad, el Broadcast sólo se haría a 2 puertos UDP. En la máquina virtual configurada con los problemas del inicio de este hilo, hay 10 usuarios remotos creados, por lo que se 'solucionaría' con 10 puertos UDP diferentes y un bucle que envíe broadcast a esos 10 puertos. Es una solución creo que 'chapucilla', por eso intentaba encontrar algo 'bien hecho'. También he visto por ahí la opción del SO_REUSEADDR, pero entiendo que esa opción de socket sólo está disponible para los clientes, y no para los servers, por lo que creo que tampoco me sirve realmente, porque tiene que haber varios servers, uno por cada instancia, para que cada uno esté igualmente escuchando. Ahora mismo estoy con Delphi XE2. ;) |
Alguien me podría ayudar con esta información, por favor ?
Ni sé cómo se podría aplicar el Patch que indican, ni sé cómo se podría actualizar a alguna versión de Indy que contenga las modificaciones que indica Remy Lebeau. Gracias Añado : Más Información |
Ese patch, creo puede ser de un sistema de versionamiento (git, mercurial, svn). si lo abres verás que es la información de como modificar un archivo del repositorio de Indy.
Podrías probar bajandote el fuente de los indy o desde el mismo SVN. |
Como indicaba en mi post anterior, aquí se indican las modificaciones a realizar en los fuentes de Indy.
Lo he hecho todo de acuerdo a lo indicado. Incluso aquí está la versión completa de IdUDPServer.pas, pero al intentar recompilar los componentes Indy, me lanza el error : [DCC Error] IdUDPServer.pas(153): E2147 Property 'ReuseSocket' does not exist in base class :( |
En el Patch, el código es correcto. En la página que indicaba en el último post, las indicaciones y el fichero IdUDPServer.pas no son correctos.
|
Bueno, .... pues tampoco.
La última versión de Indy10, como indica movorack, está en el link que adjunta. Observando ahí la unidad IdUDPServer.pas, el código sí que es el que se describía anteriormente. .... hay que ser un experto (al menos parece que yo no lo soy) para instalar la última versión se Indy (sustituirla por la que tengo actualmente). A ver si lo consigo .... cualquier ayuda es bienvenida ! |
... ni con esto me aclaro lo suficiente .... :(
|
Se me ocurre una solución ...
Crear una aplicación que se ejecute como un servicio de windows, de este modo solo habrá una instancia independientemente de los clientes que se conecten por escritorio remoto. Esta aplicación seria la que este a la escucha por un puerto UDP, y ademas tambien tendria que esperar conexiones por un puerto TCP. Su funcionamiento seria sencillo, los clientes se conectan por el puerto TCP y mantienen activa la conexión esperando a que llegue algún mensaje, por su parte cuando llega algun mensaje por el puerto UDP lo reenviamos a todos los clientes que estén conectados por TCP. Esta solución tiene varias ventajas:
Saludos |
Se me ocurre otra solución más :) ...
quizá aun mas sencilla de implementar. Volvemos a la idea de un servicio por equipo, pero ahora el servicio solo escucha por un puerto UDP (en un puerto predeterminado). Cada vez que recibe un mensaje, guarda la IP y el puerto de origen en una lista y luego reenvía el mensaje a todos los demás que se encuentren en esa lista y se encuentren en el mismo equipo. Tu aplicación solamente tendría que ponerse a la escucha por un puerto UDP (uno aleatorio que este libre) y desde ese mismo puerto enviar los mensajes a la dirección de broadcast, al puerto predeterminado, como hacia antes. El primer mensaje lo podemos enviar nada mas arrancar, solamente para darnos de alta en la lista, y a partir de hay recibiremos los siguientes mensajes que envíen los demás. Es importante que el servicio solo reenvíe los mensajes a las direcciones IP de su propio equipo, de lo contrario si tenemos el servicio en varios equipos podríamos encontramos en un bucle de mensajes broadcast de un equipo a otro. ... le seguiré dando vueltas ... puede que se me ocurra algo mas :D |
Buenas,
no hay mucha más vuelta que dar que la que indica WkaymQ48. Cuando abres dos sesiones en el mismo equipo vía terminal S, la primera instancia del equipo captura el puerto, y las siguientes se encuentran con el puerto bloqueado porque quieren utilizar el mismo puerto de la misma máquina. En este caso, cada sesión no tiene una ip propia, es la misma ya que las sesiones son en el mismo equipo. Si tuviesemos equipos virtualizados ( vmware, virtual server, ... ) sí funcionaría, ya que abrimos equipos completos aunque se ejecuten en la misma máquina. Cada uno de ellos tiene su propia ip y funcionaría. Por lo tanto, la solución pasaría por hacer un proceso, servicio o similar que se ejecute en cada equipo y que sea ése quien gestione los mensajes udp. Ahora, tendría que tener algún mecanismo para saber cuantas instancias de la aplicación tiene abiertas para que todas se enteren. Otra solución es la que has comentado, hacer una tabla de equipos y puertos y gestionar las comunicaciones vía tabla. Para eso puede ser más sencillo poner un timer y que lea la tabla para que cada aplicación sepa si tiene que refrescarse o hacer algo. Sigues teniendo el problema de que debes saber cuantas aplicaciones tienes abiertas por equipo ( ip + usuario por ejemplo ). Un saludo |
Amigo GluGlu, finalmente has encontrado alguna solución a esto?... Estoy por pasar por este mismo inconveniente.
Tengo una aplicación "MyApp.exe" donde cada usuario levanta una instancia de ella, con conexiones de Escritorio Remoto. Incluso, en la sesion del Administrador en el propio servidor (WinServer2008) ciertas veces existe tambien otra instancia en ejecución de dicho programa. Además de esto, un segundo ejecutable "Monitor.exe", está siempre en funcionamiento en la sesion del Administrador y realiza un proceso donde las distintas etapas del mismo deben ser notificadas a la/las instancias del programa "MyApp.exe" Actualmente lo tenía resuelto mediante el uso de Messages de Windows, esto es: Desde el programa "Monitor.exe" cada vez que se necesita notificar algo, se invoca la función SendAppMessage() que hace esto:
Por otro lado, el programa "MyApp.exe", siempre está "a la escucha" de esos mensajes mediante un evento que se dispara de forma automática cuando aparece un mensaje invocando al proceso RecibirAppAmessage() que es este:
Lo malo de esto es que, una vez que "MyApp.exe" "publica" el mensaje, lo toma la primera sesion abierta de "MyApp.exe" que logra mostrar el mensaje en su pantalla, pero el resto de las instancias no reciben nada. O sea, lo consume la primera instancia abierta y "se borra" para el resto. Debido a esto, estaba pensando en realizar mensajes UDP, pero me encuentro con el problema planteado aqui de las instancias de Escritorio Remoto y el problema de la apertura del PORT. Como has resuelto esto? |
El problema lo tienes porque usas FindWindow para localizar el Handle de la ventana donde enviarás el mensaje. Debes enumerarlas todas y enviar el mensaje a las que correspondan con tu App, normalmente las conocerás por el nombre de la clase de ventana. Revisa EnumWindows y GetClassName.
Saludos. |
Cita:
Todas las instancias de RDP levantan el mismo "MyApp.exe". En el ejemplo quedó el verdadero nombre, pero digamos que lo que se intenta con esa linea es enviar el mensaje a ese EXE y no a otro. Sería algomo como esto: Tal vez esto no sea la mejor solución con RDP y es por eso mi consulta, para saber si hay algo mejor.:D |
Cita:
Otra solución con sockets es implementar en MyApp un hilo con un cliente y que Monitor.exe sea un servidor. Si el protocolo es UDP no hace falta conexión previa u puedes enviar un datagrama UDP a la IP Broadcast con lo que todas las instancias de MyApp, lo recibirán. Previamente has de calcular la dirección Broadcast de tu red. Saludos. |
Cita:
Cita:
¿Entoneces es posible utilizar UDP aunque haya varias instancias RDP ? |
Es posible tener varios servidores escuchando en la misma máquina por el mismo puerto, no es una situación común pero no es un imposible. Para esto está el Multicast.
Te pongo un ejemplo de servidor socket multicast en un thread para poder compaginarlo con una app de ventanas:
Este servidor se pone a la escucha en el puerto 9090 y podemos tener varios en ejecución. Ahora el cliente debe enviar mensajes UDP al Broadcast por el puerto 9090, para ello debemos calcular esa dirección. Te pongo un ejemplo de cliente que envía un mensaje a todos los servidores a la vez, estén o no en la misma máquina:
Probado en Win10 y compilado con Delphi 7 Espero que resuelva tu duda y en general la duda que originó ente hilo. Saludos. |
Muchas, pero muchas, gracias a migo escafandra... pero esto es muy elevado para mi entendimiento :(
Primero, porque creo yo tengo un error de concepto: -En este caso, existe un pequeño ejecutable que monitorea un proceso. Llamemos a este "2do.exe" -Luego está la aplicacion principal, que cada usurario levanta mediante una conexion RDP (Windows). Llamemos "1ro.exe". O sea, hay varios "1ro.exe" y un solo "2do.exe" Entonces, el programa monitor (2do.exe) cada vez que realiza una operación, debería enviar a modo de mensaje de texto, ese resultado a cada instancia del programa (1ro.exe) y este, cuando lo reciba, lo mostrará en pantalla o como se prefiera. Yo pensaba que el monitor debería ser el Servidor y las otras aplicaciones los clientes, pero parece que es a la inversa, no? :confused: Segundo, observo que utilizas la unidad WinSock. ¿Es una unidad estandar de Delphi o solo si adquieres el paquete Indy de las versiones Archictect/Professional? Tercero: he instalado por sugerencia de varios, unos componentes "free" denominados Overbyte ICS que tienen infinidad de componentes de conexion TCP/UDP entre ellos: > OverbyteIcsWSocket.pas Winsock component - TCP, UDP, DNS,... > OverbyteIcsWSocketE.pas Register procedure and property editor for TWSocket > OverbyteIcsWSocketS.pas Winsock component for building servers > OverbyteIcsWSocketTS.pas Winsock component for building multithreaded servers > OverbyteIcsDnsQuery DNS lookup component - useful for getting MX records ...que aun no se ni cómo utilizarlos. ¿Supones que podría reemplazar los WinSocks por ellos o no es conveniente? |
Cita:
Cita:
Cita:
Ignoro como quieres que 1ro.exe trabaje con los mensajes recibidos, por eso en el ejemplo puse un MessageBox. Ten en cuenta que todo el código servidor está en un Thread, lo que significa que no puedes usar a las bravas la VCL desde él. Para sincronizar el hilo con el formulario debes usar el método Synchronize o mejor aún en este caso, mensajes Windows desde el hilo a la ventana del formulario que elijas, para ello basta con que al crear el hilo le pases el Handle de dicha ventana y uses SendMessage desde el hilo, cuando recibas un mensaje UDP (que viene de Monitor.exe). En tu formulario generas una función de tratamiento de esos mensajes personalizados y funcionará como un evento. Saludos. |
A modo de ilustración, te muestro el servidor modificado para disparar un evento al recibir un mensaje desde el cliente. En este caso, el formulario incorpora un TLabel donse se escribirá el mensaje de texto recibido. Uso un mensaje de Windows pero también podrías modificarlo para usar Synchronize.
Saludos |
Cita:
Ya generé ambos ejemplos, el cliente y el server, pero no pasa nada... Inicio primero el Server y luego el cliente, hago clic en el Button1 y nada.... Inicio primero el Cliente y luego el Server, hago clic en el Button1 y nada.... Mi LAN es 192.168.14.xxx y la funcion GetBrodcastAddress; está devolviendo correctamente 192.168.14.255 Probé otros Port y nada... que puede ser ? |
3 Archivos Adjunto(s)
Posiblemente dependa de la versión del delphi que uses.
La versión Cliente que he probado con delphi7 y Berlin es esta:
Ten en cuenta que el UNICODE juega malas pasadas. Subo un proyecto con fuentes y ejecutables compilados. |
Excelente aporte Escafandra!!!
|
Escafandra, te hago el siguiente planteo que difiere del expuesto hasta ahora.
Yo tengo actualmente un programa que actúa como servidor usando TServerSocket en modo nonblocking que envía cada 2 segundos registros con el método SendBuf a cada uno de los clientes (TClientSocket) que se hayan conectado. El tamaño de cada paquete comprimido puede ser algo mas de 8k. Como suelen ser varias pc's clientes, esto genera bastante trabajo del lado servidor que ademas tiene que ir recolectando y haciendo muchos calculos, luego volcar la información a sus respectivos registros, comprimirlos y luego enviar a cada cliente. Si esto quisiera hacerlo con UDP, como debería ser ya que de este modo haría un solo envío? Gracias. |
Cita:
2. Si quieres hacer un solo envío de un paquete vía Broadcast, debes hacerlo como en el ejemplo que público. Un sólo envio a la dirección Broadcast previamente calculada desde el servidor. El ejemplo permite varios servidores y varios clientes sin cambiar el código, pero si quieres que los servidores envíen puedes establecer un bucle de comunicación o simplemente implementar el procedimiento SendUDP en cada uno. Esto requiere que cada cliente tenga un rhread a la 3scucha, es decir, también son servidores. Si las maquinas van a ser distintas no es preciso usar SO_REUSEADDR. Ten en cuenta que todas las app pueden ser clientes y servidores a un tiempo si quieres y que en UDP no precisas una conexión previa lo que es bueno por una parte pero no asegura que el paquete sea recibido. Saludos |
Y como se puede lidiar con paquetes que no llegan o cuando se fragmenta en mas de uno?
|
Cita:
Saludos. |
Ok, entonces veo que es preferible seguir como hasta ahora con TCP.
|
Como sería esto mismo pero que el servidor envíe mensajes udp a clientes en distintas pc´s?
|
El esquema del ejemplo funciona con cualquier máquina en la Red con el mismo código. Un cliente que envía mensajes a servidores en red a través de la dirección BroadCast.
Saludos. |
La franja horaria es GMT +2. Ahora son las 15:27:58. |
Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi