un sistema alternativo, che ti consiglio TANTISSIMO, è l'utilizzo di un'architettura VERAMENTE client server

Tieni in considerazione che:
- Il software client in realtà non è un software client ma un software standalone che si connette a un db remoto
- per il motivo esposto prima e possibile modificare il software e danneeggiare GRAVEMENTE il database
- idem ancora è possibile acquisire i dati di connessione interni del software e danneggiare GRAVEMENTE il database
- gestire gli aggiornamenti è parecchio rognoso
- potresti avere problemi con dipendenze o altro che magari vanno a mancare su tutti i client
- tanto altro ancora

Con un'architettura reale, con un protocollo a pacchetti basato su TCP-IP, magari byte-oriented, invece che string-oriented, ti darebbe la possibilità di eseguire operazioni multiple senza avere la necessità di avviare più connessioni TCP/IP magari applicando algorittimi di crittazioni varie in modo da rendere ancora più complesso un'eventuale sniffing, magari a chiave variabile in base al parametro e al comando

Un programma server che parte e si binda su una specifica porta e si occupi di:
- Rispondere alle richieste del client
- Eseguire le operazioni richieste
- Gestire gli Aggiornamenti
- Gestire i log
- altro

Un sistema simile all'RPC è molto comodo, ovvero un pacchetto contenente il comando da eseguire e i parametri del comando. Tutto ciò lo fai con estrema semplcità costruendo una libreria, classe, o altro ancora, che costruisca i comandi passando un nome o un'id ... il codice fa un lookup da una tabella, acquisisce la coppia di byte corrispondente al comando, impacchettare i comandi e spedire tutto tramite le socket, eventualmente crittando i parametri se richeisto dall'utente

Ad es una conversazione per il login potrebbe essere di questo tipo (le graffe indicano un byte specifico):
Server: {0}{0}123456780{255}
Client: {0}{1}0987654321{255}
Server: {0}{2}{255}
Client: {0}{3}username{254}password{255}
Server: {0}{4}{255}

in questo caso l'azione zero indica le operazioni di handshaking e autenticazione mentre le subazioni corrispondono, in sequenza:
- richiesta handshaking
- risposta handshaking
- richiesta autenticazione
- risposta autenticazione
- risultato autenticazione

Il byte 255 corrisponde al terminatore del comando mentre il 254 corrisponde al separatore del comando ... in questo modo il parser deve limitarsi a scomporre il comando e costruire un'array contenente i parametri ed in base all'azione/subazione richiamare il comando richiesto

Facendo cosi inoltre ti semplifichi la vita notevolmente, infatti creando una hashtable (una lista in pratica) puoi accoppiare ad ogni azione/subazione una callback da richiamare in modo da non dovre scrivere tonnellate di if e switch

A questo puoi aggiungere un sistema di gestione degli stati:
- Stato zero: in attesa dell'handshaking
- Stato uno: in attesa dell'autenticazione
- Stato due: in attesa del codice del protocollo
- Stato tre: verificato

So che magari ho corso un pelino però queste architetture sono estremamente flessibili e soprattutto sono sempre pronte per ulteriori utilizzi

Tieni in considerazione un'ultima cosa: il cliente deve SOLO richiedere informazioni ed inviare le richieste di esecuzione delle operazioni ... NULLA più ... deve essere il server ad eseguire le operazioni

Per finire ... nel comando conviene SEMPRE inserire un'identificatore di sequenza in modo che il modulo di gestione del protocollo sia in grado di identificare, ad esempio, quale finestra ha richiesto uno specifico comando e quindi di visualizzare le informazioni li [se ad esempio hai 5 istanze della stessa finestra il software non saprebbe dove restituire i dati, invece se quando ricevi la richiesta crei un'id e lo accoppi alla finestra ... sai, al momento della risposta, dove andare a restituire i dati]



probabilmente ti avrò confuso non di poco le idee