Tecnica migliore per input dati da prg esterno

sabato 21 aprile 2007 - 09.13

denis.basei Profilo | Senior Member

Salve a tutti!
Devo preparare una applicazione di supervisione in vb net con database sql server express 2005. L'impiego sarà per la gestione del carico, scarico di un magazzino automatico. La gestione che mi riguarda ha inizio con l'input fornito da un altro programma del codice articolo in ingresso al magazzino. So quasi per certo che il programmatore che mi deve fornire questa informazione non lo vorrà fare su un tabella del db sql perchè non lo sa fare e vorrà scrivermi questa informazione in un file sequenziale. Non mi piace l'idea di aprire e leggere questo file ogni 10 secondi per controllare se c'è un nuovo articolo. Quali altre alternative posso avere che non siano troppo complesse visto che chi deve fornire il dato usa tecniche di programmazione piuttosto obsolete?


Grazie a chi mi darà qualche idea.

alextyx Profilo | Expert

Bah....non oso proporti un socket, visto che il tuo corrispondente potrebbe spaventarsi, ma potresti implementare una comunicazione via seriale RS232. Io ho fatto una cosa simile per comunicare con una applicazione ottenuta con LabView e ci scambiamo datti diverse volte al secondo. Oltretutto, avresti il vantaggio di reagire ad un evento e non essere neppure costretto ad un periodico controllo, come nel caso del file. Anche se...pure con il file potresti usare il filesystemwatcher e reagire ad un evento anche in quel caso!

denis.basei Profilo | Senior Member

I tuoi input sono interessanti, ci do un'occhiata e poi ci risentiamo....

denis.basei Profilo | Senior Member

Mi piace provare nuove soluzioni e magari quelle più complesse ma maggiormente funzionali e fra quelle che mi hai proposto sembra che sia tale la comunicazione con socket.
Nel mio caso c'è una applicazione A, sviluppata da un altro programmatore che mi deve passare un codice man mano che un pezzo viene imballato in una linea produttiva. La mia applicazione B legge questo codice ed esegue delle elaborazioni per far proseguire il pezzo.
Ti chiedo: meglio socket sincrono o asincrono? Il server socket deve essere implementato nell'applicazione A e quello client nell'applicazione B?

Grazie

denis.basei Profilo | Senior Member

... continuando il messaggio precedente ed acquisendo qualche info forse ho sbagliato, il server socket è la mia applicazione. Giusto?
Con questa tecnica sono costretto ad eseguire periodicamente un controllo socket.accept(). L'applicazione A come fa a sapere che il primo codice è stato letto e quindi può scrivere il secondo? Se l'applicazione B non avesse ancora letto il primo codice e viene scritto il secondo perderei il primo... scusa il giro di parole e la mia ignoranza in merito ai socket!

alextyx Profilo | Expert

L'applicazione SERVER è la tua.
Per una comunicazione sicura devi usare un protocollo orientato alla connessione, come il TCP/IP.
Il Client verrà a sapere che il messaggio è stato ricevuto in quanto la comunicazione è bidirezionale e il server, se sollecitato dal client, acquisisce il dato e ne dà conferma di avvenuta 'elaborazione' e di poterne quindi ricevere di nuovi.
Nelle pochissime applicazioni in cui ho usato i socket, non avevo problemi ad attendere i dati, ma sicuramente deve esserci un evento che ti comunica l'arrivo dei dati.
Prossimamente dovrò implementare un socket (però UDP) per interagire con una applicazione diagnostica di terzi, scritta in C++, in cui dovrò semplicemente ricevere e salvare i dati che arrivano, anche accettando di perderne qualcuno (UDP non dà garanzie, è leggero ed è usato x inoltri di tipo broadcast) e magari avrò modo di rivedere la cosa, anche se, pure in quel caso, in realtà, non credo che avrò necessità di gestire un evento.
Ma non garantisco sui tempi e sul risultato.
Partecipa anche tu! Registrati!
Hai bisogno di aiuto ?
Perchè non ti registri subito?

Dopo esserti registrato potrai chiedere
aiuto sul nostro Forum oppure aiutare gli altri

Consulta le Stanze disponibili.

Registrati ora !
Copyright © dotNetHell.it 2002-2024
Running on Windows Server 2008 R2 Standard, SQL Server 2012 & ASP.NET 3.5