Cita:
Empezado por hgiacobone
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?  |
En principio sujerí que monitor fuese el servidor para simplificar la conexión pero eso requiere que los clientes pregunten al servidor cada cierto tiempo alejándose de la idea de que sea el Monitor el que envíe mensajes cuando le plazca a las instancias del 1r0.exe que deben estar a la escucha. Esto requiere que Monitor actúe como cliente y el resto como servidores a la escucha por el mismo puerto. Esta idea es la que, en principio, va en contra de la teoría que dice que "solo puede haber un servidor escuchando en un mismo puerto", que es cierta salvo alguna excepción como la que muestro.
Cita:
Empezado por hgiacobone
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?
|
La API
WinSock es una unidad estándar de windows. Los Sockets son la vía a bajo nivel que el S.O. nos brinda para manejar los paquetes en la red permitiéndonos enlazar la capa de aplicación con la de transporte. Son un estándar básico adoptado pos casi todos los S.O. por lo que te sirve para conectar con cualquier máquina en la red. Como es natural, Delphi y otros lenguajes, son capaces de manejar esa API. Los componentes de terceros para comunicación por red, usan winsock, como no podía ser de otra manera, para realizar sus propósitos.
Cita:
Empezado por hgiacobone
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? |
Como ya te digo, esos componentes no reemplazan, sino que usan internamente winsock. Para el uso concreto que se pide en este hilo, considero que la mejor forma (por poco usual) es trabajar a bajo nivel con sockets (winsock) para tener el control absoluto de lo que hacen y como se configuran (
setsockopt)
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.