Hola, tengo un par de aplicaciones que quiero que se comuniquen entre ellas. Ambas aplicaciones corren al mismo tiempo en la misma maquina y he pensado en utilizar sockets para realizar la comunicacion, pero no se si es muy correcto el uso de sockets ya que las dos aplicaciones como dije, se encuentran en la misma maquina.
He pensado tb hacerlo a traves de un fichero, pero me parece un poco cutre.
Tengo el dia un poco espeso y no se me ocurre otra forma de hacerlo.. ¿Alguna idea?
Gracias
http://es.wikipedia.org/wiki/Comunicaci%C3%B3n_entre_procesos y por cierto, lo de los sockets es perfectamente correcto aunque sea entre procesos de la misma máquina. Elegir una u otra forma depende básicamente de qué quieras que se manden y quién quieras que pueda mandar.
Hablo de POSIX, aunque muchas cosas se pueden hacer tb en Windows:
Si quieres que cada proceso esté a su bola, pero de repente alguno quiera avisar al otro de algo -> SEÑALES
Si quieres que cada proceso esté a su bola, pero de repente alguno quiera enviar al otro DATOS -> señal (para avisar) + (memoria compartida ó fichero mapeado en memoria para leer/escribir la información).
Si quieres que cada proceso esté a su bola pero llegado a un punto uno "se pare" porque necesite datos del otro (y ese otro tb sabe que cuando tenga los datos tiene que pararse y enviarlos) -> sockets o pipes
Etcétera...
Salu2 
PD: los sockets/pipes, NORMALMENTE son bloqueantes, pero siempre puedes usar threads...
Hola, gracias a todos por responder. Las dos aplicaciones correran en windows, y ambas son aplicaciones .NET. Lo hare por sockets.
Gracias!
Respecto a lo q dice #3 y sabiendo q usas .NET, usa sockets asíncronos. Te quitas problemas de tener q usar threads.
La comunicación entre procesos como te indican es con Sockets, mediante puertos
http://www.codeguru.com/dbfiles/get_image.php?id=12219&lbl=TCP03_GIF&ds=20060629
Sockets cuando estamos en la misma máquina???... es una opción, porque no. Pero las hay más sencillas, robustas y menos problemáticas. Aunque todo esto depende de qué datos quieras pasar entre las dos aplicaciones. Si sólo se trata de despertar procesos, datos simples, creo que lo mejor es usar la API de Windows que para eso está.
Funciones como RegisterWindowMessage y SendMessage van de lujo. Sobre todo en .NET donde la subclasificación es pan comido (no como en VB6) ya que puedes redefinir funciones de Ventana ocultas hasta ahora. Con GlobalAddAtom puedes dejar en memoria strings para luego recuperarlos con la otra aplicación. En el fondo, toda comunicación desde los inicios de Windows hace uso de estas funciones para su comunicación. Lo mejor de todo: más testeado no puede estar después de casi 30 años de historia. Incluso el protocolo DDE de toda la vida al final del todo hace uso de la API.
También está el tema ActiveX, aunque si estás en .NET, los componentes son totalmente de distintos. Pero bien planteados puedes pasar de todo entre 2 aplicaciones. Lo malo: El registro, las versiones y su puta madre en bata... Putos componentes xD. Con la API te ahorras todo esto. Defines tu función y a tirar millas.
También puedes hacer la cutrez de dejar un archivo de texto plano en un carpeta para que otro lo lea. Pero esta mierda la suele hacer uno cuando empieza y no tiene ni zorra. Aunque en esto de la programación ya se sabe: Si funciona, no peta y va rápido, da igual que sea poco académico. Ahora, no te recomiendo esta solución.
Insisto, creo que con la API te sobra. Lo de los sockets me parece correr un riesgo innecesario.
Llevo muchos años programando en un Framework o RAD bastante antiguo y sin las prestaciones de .NET. Y claro, he tenido que buscarme la vida para hacer cosas como comunicarme con excel, encajar una ventana excel en la aplicación, incorporar (y programarlos la mayoría de las veces) ActiveX en la aplicación. Y de este tema sé bastante por lo que me ha tocado sufrir.
Si quieres explicarnos algo más, quizás podamos sugerirte la solución más óptima.
