Newsgroup: it.comp.programmare.win32
Titolo: come scambiare informazioni tra due processi indipendenti

ciao,
sto cercando un metodo per scambiare dati tra due applicazioni in VC, o 
anche VB-VC.
I metodi che adesso utilizzo sono:
1) socket TCP/IP: svantaggi: tutti i pr dello stack IP
2) atomi: GlobalAddAtom() e  GlobalFindAtom(): svantaggi: devi conoscere il 
nome dell'atomo per cercarlo
3) file intermedi: svantaggio:  lento
sto cercando il metodo migliore per passare ad esempio una stringa, o degli 
interi, tra due processi
in maniera molto veloce in termini di tempo di CPU,
faccio un thread di ricezione che polla "qualcosa" in attesa di dati?
cosa mi consigliate?
danke
GCL 

 wrote in
news:ckKVh.7091$
jy5....@tornado.fastwebnet.it
: 

Un blocco di memoria condivisa (CreateFileMapping), un evento con 
nome (per segnalare la modifica) e un mutex con nome (se lettura e 
scrittura contemporanei possonono essere un problema, e normalmente 
lo sono).
Oppure una pipe.
Esiste anche un meccanismo basato sui messaggi tra finestre 
(WM_COPYDATA), ma te lo sconsiglio.
Se invece che scambiare dati devi eseguire operazioni, allora puoi 
far sģ che il programma "controllato" implementi un'interfaccia COM.
-- 
Valter Minute
(the reply address of this message is invalid)
(l'indirizzo di reply di questo messaggio non č valido)

 (WM_COPYDATA), ma te lo sconsiglio.
sigh, era quello che avevo trovato sull'MSDN nuovo nuovo.. :-(
http://msdn2.microsoft.com/en-us/library/ms648710.aspx
grazie
GCL 

 
http://msdn2.microsoft.com/en-us/library/ms648710.aspx
Il problema č che si basa sui messaggi tra finestre che, se le due 
applicazioni scambiano messaggi nei due sensi, puň portare a un 
deadlock.
Preferisco sistemi piů "leggeri" e piů semplici da incapsulare in 
una classe o in una liberia di funzioni in modo che possano poi 
essere rimpiazzati (se si dimostrano poco efficienti) o riutilizzati 
in altri progetti (dove magari non hai un'interfaccia utente e 
quindi non puoi usare il WM_COPYDATA).


scusa, ancora una curiosita':
la CreateFileMapping(), ammesso di avere sufficientemente memoria RAM,
si appoggia ad un file di swap su disco o se riesce fa tutto in RAM?
I problemi sono due:
1) se usa il disco  potrebbe essere piu' lenta del mio attuale metodo con 
due socket TCP/IP
2) se lo uso su scheda PC (winCE)  con un DOM potrei fare troppi accessi 
alla flash del DOM e non
    so se questo e' positivo, magari eccedo il numero di scritture sulla 
singola cella...
grazie...
GCL 


Tipicamente le named pipes sono le più performanti (usate anche da WCF per 
colloquiare tra processi locali).
Il problema è più che altro architetturale. Se tra i due layer che vivono in 
due processi differenti non c'è un contratto ben definito (magari basato su 
qualche standard come wsdl) diventa più difficile da manutenere e meno 
espandibile. E scrivere il protocollo di comunicazione tra i due processi 
può non essere banale:
- deve essere una comunicazione sicura?
- necessiti di transazionalità?
- devi identificare l'altro processo per autorizzarne l'uso?
- devi poter accodare un messaggio nel caso in cui l'altro processo non sia 
disponibile o sia occupato?
Tutte queste cose sono gestibili anche a mano ma certamente richiedono un 
sacco di codice. Esitono invece una serie di normative WS-* che stabiliscono 
uno standard per questi problemi e WCF le implementa tutte rendendo semplice 
la loro gestione a livello applicativo.
Questo è il motivo per cui personalmente non scriverei più un sistema di 
comunicazioni strettamente basato su Win32.
Ovviamente non significa che non ci siano buoni motivi per usare Win32 
direttamente.
-- 
Raffaele Rialdi
Microsoft .NET MVP 
http://mvp.support.microsoft.com
 -
http://italy.mvps.org
 UGIdotNET - User Group Italiano .NET
http://www.ugidotnet.org
 Weblog: 
http://blogs.ugidotnet.org/raffaele

disponibile o sia occupato?
diciamo che il primo passo sarebbe mandare strighe lunghe a piacere tra due 
processi distinti,
i processi hanno un thread apposta che sta in polling in attesa dell'arrivo 
di una stringa dall'altro processo,
(e' quello che sto facendo con due socket TCP...)
poi sarebbe bello condividere una zona di memoria...
per semplificare potrebbero essere due spazi diversi per cui non c'e' 
neppure problema di un mutex...
ogni processo scrive nello spazio a lui dedicato...
GCL 

 ogni processo scrive nello spazio a lui dedicato...
Sotto "IPC" in msdn trovi l'elenco completo delle modalità di comunicazione 
inter-process.
Usando le primitive Win32 le cose cambiano molto se i due processi stanno 
sullo stesso PC o su pc differenti.
Le comunicazioni basate su TCP/IP sono comode ma anche tra le meno 
performanti.
Se vuoi restare su 'puro win32' e non hai i problemi che ho già elencato, 
userei le named pipes, che al contrario della memoria condivisa ti danno la 
possibilità di remotizzare su un altro pc uno dei processi.


 wrote in
news:R6kWh.2973$
281....@tornado.fastwebnet.it
: 

Nel caso di Windows CE il meccanismo non si può basare sullo swap 
file ed è in RAM, a meno di non forzarlo su file (cosa possibile 
solo dalla release 6.0).
Se devi passare informazioni tra due processi su CE puoi usare anche 
le point-to-point message queues, mentre non hai a disposizione le 
pipes.
Se sviluppi software che deve essere portato su CE, valuta bene se 
tutto quello che stai usando su Win32 è supportato su CE e quali 
sono le differenze.
Anche su Win32 se ti basi sullo swap e c'è RAM libera a sufficienza, 
il passaggio avviene in RAM.
-- 
Valter Minute
(the reply address of this message is invalid)
(l'indirizzo di reply di questo messaggio non è valido)