Mensajes Broadcast vía UDP entre varias instancias corriendo en una misma máquina

[[gluglu]]

Cuanto tiempo sin aparecer por aquí !!!

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

[Casimiro Notevi]

Empezado por gluglu

Cuanto tiempo sin aparecer por aquí !!!
Saludos a todos en primer lugar.

Saludos, tanto tiempo

No conozco la solución a tu duda

[[movorack]]

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

A named pipe is a named, one-way or duplex pipe for communication between the pipe server and one or more pipe clients. All instances of a named pipe share the same pipe name, but each instance has its own buffers and handles, and provides a separate conduit for client/server communication. The use of instances enables multiple pipe clients to use the same named pipe simultaneously.
Any process can access named pipes, subject to security checks, making named pipes an easy form of communication between related or unrelated processes.
Any process can act as both a server and a client, making peer-to-peer communication possible. As used here, the term pipe server refers to a process that creates a named pipe, and the term pipe client refers to a process that connects to an instance of a named pipe. The server-side function for instantiating a named pipe is CreateNamedPipe. The server-side function for accepting a connection is ConnectNamedPipe. A client process connects to a named pipe by using the CreateFile or CallNamedPipe function.
Named pipes can be used to provide communication between processes on the same computer or between processes on different computers across a network. If the server service is running, all named pipes are accessible remotely. If you intend to use a named pipe locally only, deny access to NT AUTHORITY\NETWORK or switch to local RPC.
For more information, leer mas

[Julián]

Empezado por gluglu

Cuanto tiempo sin aparecer por aquí !!!

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 ....

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!

[[gluglu]]

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

[[Al González]]

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.

[[gluglu]]

Gracias de nuevo también por los mensajes de satisfacción por verme de nuevo por aquí !

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.

[[gluglu]]

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

[hgiacobone]

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:

Código Delphi [-]
type
    TMonitor1: class(TForm)
    ...
    private
    function SendAppMessage(mensaje:string):Boolean;
    ...
end;
///--------------------------------------
function TMonitor.SendAppMessage(mensaje:string):Boolean;
var
 CopyDataStruct : TCopyDataStruct;
 hReceptor: THandle;
 Respuesta: integer;
begin
  Result:= False;
  CopyDataStruct.dwData := 0; //utilizado para identificar el contenido del mensaje
  CopyDataStruct.cbData := Length( mensaje )+1;
  CopyDataStruct.lpData := PChar( mensaje );
  // Comprobamos si existe el receptor
  hReceptor := FindWindow( PChar('CORE') , nil );
  if hReceptor = 0 then
  begin
   {ShowMessage( 'No se ha encontrado al receptor.' );}
   Exit;
  end;
  // Enviamos el mensaje
  Respuesta := SendMessage( hReceptor, WM_COPYDATA, Integer( Handle ),
   Integer( @CopyDataStruct ) ) ;
// si nos interesa recogemos la respuesta del receptor
  {if Respuesta = 1 then ShowMessage( 'El mensaje ha sido recibido satisfactoriamente.' );}
  Result := (Respuesta = 1);
end;

//Ejemplo:
    if (sTime='18:00') then SendAppMessage('Happy Hour... vamos por una cerveza fría !');

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:

Código Delphi [-]
type
    TForm1: class(TForm)
    ...
    procedure RecibirAppMessage( var Msg: TWMCopyData ); message WM_COPYDATA;
    ...
end;
///------------------------
procedure TForm1.RecibirAppMessage( var Msg: TWMCopyData );
var
  s1:string;
begin
  s1:= PChar( Msg.CopyDataStruct.lpData );
  if bShowMessage 
    then ShowMessage( s1 )
    else StatusBar1.Panels[3].Text := s1;
  Msg.Result := 1; //como respuesta que se ha recibido el mensaje
end;

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?

[[escafandra]]

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.

[hgiacobone]

Empezado por escafandra

El problema lo tienes porque usas FindWindow para localizar el Handle de la ventana...

Gracias por responder escafandra, pero sucede que el Handle es unico, me refiero que es un unico EXE.
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:

Código Delphi [-]
hReceptor := FindWindow( PChar('MyApp') , nil );

Tal vez esto no sea la mejor solución con RDP y es por eso mi consulta, para saber si hay algo mejor.

[[escafandra]]

Empezado por hgiacobone

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.

Cuando envías un mensaje lo haces a un thread o a una ventana, no a un ejecutable. Cuando tienes varias instancias de un ejecutable, cada una con ventanas, los Handles no son los mismos. Una forma de enviar un mensaje a todas las ventanas es usar como Handle HWND_BROADCAST, pero entonces tendrás que tener un filtro en MyApp

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.

[hgiacobone]

Empezado por escafandra

...Cuando tienes varias instancias de un ejecutable, cada una con ventanas, los Handles no son los mismos...

Ah, ok.... o sea, Windows tomará un ID diferente aunque sea el mismo EXE?

Empezado por escafandra

...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...

Entiendo, pero lo planteado en este foro hizo que dudara por el uso del port.
¿Entoneces es posible utilizar UDP aunque haya varias instancias RDP ?