[OT]: Struttura client/server basata su MySQL

[artedelcorpo]

Salve,

Premessa:
Per applicazioni client/server al lavoro ho sempre utilizzato 4th dimension (per esigenze di sistemi eterogenei win+mac). Un tool che mette a disposizione un applicativo server in grado di distribuire l'applicazione ai client.
Con 4D io non mi curo di nulla. Devo soltanto scrivere l'applicativo "stand-alone" e darlo in pasto al server che ne gestisce accessi sul DB (proprietario), concorrenza, ecc... e lo rende disponibile ai vari client.
# Spero di essermi spiegato #

Domanda:
Ora mi sto avvicinando, grazie agli studi universitari, al mondo Linux e alla programmazione su tale piattaforma.
Ho intenzione di scrivere un gestionale client/server con Python+GTK+MySQL.
Il dubbio è:
>>> MySQL è il mio server (come il server 4D) o soltanto il mio DB?
Caso 1 (MySQL è il mio server):
- Devo scrivere in Python solo un applicazione client che interroga il DB e andrò a installarla su tutte le macchine client.
Caso 2 (MySQL è soltanto il mio DB)
- Devo scrivere in Python un applicazione server che interroga il DB per conto dei client e ne gestisce accessi e risposte.
# Anche qui spero di essermi spiegato #

Attendo le vostre risposte.

[MItaly]

Semmai le due possibilità saranno "MySQL risponde a richieste remote" o "MySQL non risponde a richieste remote". Dato che MySQL risponde a richieste remote (ovviamente bisogna configurare adeguatamente il firewall) devi solo scrivere l'applicazione client.

[daniele_dll]

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

[artedelcorpo]

grazie di cuore...
dire che la risposta è esaustiva non è dire nulla.
è molto interessante e stimolante.
scrivere un protocollo "proprietario" di comunicazione tra client e server...
handshaking, ack... mi sembra di essere tornato all'esame di reti 2

[daniele_dll]

se ti serve una mano sulla progettazione del tutto ci possiamo sentire via gtalk se vuoi

[artedelcorpo]

Grazie di cuore ma, ammesso che intraprenderò questa avventura, sarà per diletto durante l'estate. Magari di notte durante le ferie.

[billiejoex]

Solo qualche considerazione.

Tieni in considerazione che:
- Il software client in realtà non è un software client ma un software standalone che si connette a un db remoto

Se si connette ad una macchina remota sempre di _client_ trattasi.

- 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

In che senso, scusa?

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

Che significa "un protocollo byte oriented invece che string oriented"? Perchè dovrebbe avviare più connessioni TCP? Lo stesso server sql (che, premetto, non ho mai usato) utilizzerà un proprio protocollo simile al sistema da te descritto. Perchè non affidarsi a lui, quindi?
Ben venga la crittografia.

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

I primi tre passaggi cosa rappresenterebbero? L'Handshaking? In tal caso è il client che lo inizia, non il server. Inoltre a lui non credo interessi dato che del 3whs se ne occupa gia la socket API in maniera trasparente.
A mio parere, cmq, se la struttura che lui vuole creare non è qualcosa di eccessivamente complesso farebbe bene ad implementare da sè un semplice protocollo simile a quello da te descritto. Tra l'altro Python, gia nella libreria standard include diversi moduli di interfacciamento a db.

Saluti

[artedelcorpo]

Non ho ben capito tu cosa mi consigli di fare?
Client che si interfacciano diretti al DB o Client che comunicano con il server che si interfaccia al DB?

Grazie

[daniele_dll]

Originariamente inviato da billiejoex
Se si connette ad una macchina remota sempre di _client_ trattasi.

Si ma non è un sistema client/server a pieno ^^

In che senso, scusa?

parlava di sviluppare il software in python ed essendoci il codice sorgente (quello "compilato" e facilmente disassemblabile) è possibile recuperare le pass che usa interne di mysql e far danni.

Che significa "un protocollo byte oriented invece che string oriented"? Perchè dovrebbe avviare più connessioni TCP? Lo stesso server sql (che, premetto, non ho mai usato) utilizzerà un proprio protocollo simile al sistema da te descritto. Perchè non affidarsi a lui, quindi?
Ben venga la crittografia.

Condividere la connessione tra più finestre non è propriamente una bella idea ... se percaso in una finestra avvii a fare un'operazione lunga sei costretto a bloccare l'intero software per evitare che da qualche altra finestra vengano eseguite operazioni che creino problemi

I primi tre passaggi cosa rappresenterebbero? L'Handshaking? In tal caso è il client che lo inizia, non il server. Inoltre a lui non credo interessi dato che del 3whs se ne occupa gia la socket API in maniera trasparente.
A mio parere, cmq, se la struttura che lui vuole creare non è qualcosa di eccessivamente complesso farebbe bene ad implementare da sè un semplice protocollo simile a quello da te descritto. Tra l'altro Python, gia nella libreria standard include diversi moduli di interfacciamento a db.

L'handshaking è solo un sistema di convalida del client, nel senso che validando l'handshaking il software che si connette, dovrebbe, essere quello che è stato sviluppato appositamente ... dovrebbe ^^
Lo inizia il server o lo inizia il client è perfettamente indifferente ed è una scelta progettuale ... io preferisco farlo iniziare al server in modo da inviare un tot di dati da validare

Ripeto, interfacciarsi direttamente al db è sicuramente la cosa più comoda ma anche estremamente pericolosa ... recuperare le password usate dal programma per accedere al db per poter fare danni è sufficentemente semplice, e nel caso non fosse crittato basterebbe un semplice sniffer

[pgm]

scusate se mi intrometto. anche a me serve questa discussione

secondo voi, fare un'applicazione web accessibile da browser non è contemplata?

voglio dire, non è una buona soluzione?