[DELPHI] Applicazione client/server con Indy Components

[VaLvOnAuTa]

Salve.
Ho un problema con indy.

Ho delle librerie per delphi che possono pilotare dei telefoni ip. Ora vorrei mettere queste librerie (con relativo programma fatto da me) su un server in modo che tutto il sistema (log di telefonate etc) possa essere gestito centralmente. Contemporaneamente però ho bisogno di un programma client che possa inviare comandi al server.
Dato che non ho mai lavorato con i socket, qualcuno ha qualche indicazione/tutorial da darmi?

Il capo ha cambiato idea all'improvviso stravolgendo in buona parte il lavoro e la demo che sto preparando deve essere pronta tra 4 ore

[alka]

Quando installi i componenti Indy, ti vengono installati anche numerosi esempi con codice sorgente.

Ciò che devi approfondire è l'uso del client e del server TCP e crearti un miniprotocollo ad hoc.

Cerca tra gli esempi dove vengono utilizzati questi componenti.

Non ho ben chiaro ciò che devi realizzare, ma forse può esserti utile anche il demo ScreenThief, un'applicazione completa con sorgente che trasferisce da server a client l'immagine del desktop: è utile per apprendere l'uso dei metodi di cui sono dotati i componenti Indy per la comunicazione via TCP.

Per i tempi stretti, ahime, nessuno può farci nulla.

Ciao!

[VaLvOnAuTa]

Originariamente inviato da alka
Quando installi i componenti Indy, ti vengono installati anche numerosi esempi con codice sorgente.

Non li ho installati. Su delphi 7 sono già presenti

Originariamente inviato da alka
Ciò che devi approfondire è l'uso del client e del server TCP e crearti un miniprotocollo ad hoc.

Ci avevo già pensato, per questo ho trovato la soluzione del "client/server", solo che non sapevo quale evento gestisse la ricezione dei comandi (soluzione trovata grazie all'esempio da te postato)

Originariamente inviato da alka
Per i tempi stretti, ahime, nessuno può farci nulla.

Ciao!

Lo so, non era mia intenzione concentrare le attenzioni altrui sul mio problema

Solo una curiosità: Dato che il client potrebbe mandare al server un comando del tipo "alza la linea telefonica e chiama il numero xyz", per dare un comando del genere mi conviene fare un writeln del tipo "call:xyz" e poi splittare la stringa?
Dato che non ho mai creato un protocollo, non so se va bene in questo modo

[alka]

Originariamente inviato da VaLvOnAuTa
Solo una curiosità: Dato che il client potrebbe mandare al server un comando del tipo "alza la linea telefonica e chiama il numero xyz", per dare un comando del genere mi conviene fare un writeln del tipo "call:xyz" e poi splittare la stringa?

Non saprei dirtelo nel senso che, in fondo, si tratta di inviare/ricevere un comando: la forma di questo comando la implementi come sei più comodo tu ad interpretarla usando le funzioni di manipolazione delle stringhe in Delphi.

[VaLvOnAuTa]

Salve.
Riprendo questa discussione per porre una domanda.
Il server che ho creato deve gestire degli eventi e dovrebbe poter mandare dei comandi ai client ad essi connessi non appena tali eventi si verificano.
Mi spiego: il server controlla un centralino telefonico IP di un call center. I vari client appartengono agli operatori del call center. Ora non appena il server verifica una connessione in corso su un interno, deve controllare il numero chiamante su un database e avvisare l'operatore con un messaggio.
Ora il problema è che, suppongo, un server non possa inviare messaggi ai client connessi (od almeno non riesco a trovare sul client l'evento che gestisce la ricezione dei messaggi - forse perchè non c'è proprio ).

A sto punto ho pensato due soluzioni.
1- I client hanno un timer che ogni tot millisecondi chiede info al server
2- Ogni client ha un server in ascolto ed il server ha un client (solo che questa soluzione è quantomeno macchinosa).

C'è qualche altra idea economica e conveniente?

[alka]

Originariamente inviato da VaLvOnAuTa
[...]
A sto punto ho pensato due soluzioni.
1- I client hanno un timer che ogni tot millisecondi chiede info al server
2- Ogni client ha un server in ascolto ed il server ha un client (solo che questa soluzione è quantomeno macchinosa).

C'è qualche altra idea economica e conveniente?

Credo che tu abbia elencato le uniche due possibilità che hai a disposizione.

In fondo, se anche tu potessi inviare dati periodicamente dal server al client, non sarebbe nulla di diverso rispetto all'inoltrare semplicemente - attraverso un comando specifico - una richiesta da parte del client per ottenere l'informazione in esame.

Inoltre, questo potrebbe servirti a controllare dal lato server quali client sono ancora connessi e risultano non bloccati poichè continuano ad effettuare una specie di "ping" alla ricerca di eventi da gestire.

In sostanza, punterei - salvo restrizioni - sulla prima soluzione che hai proposto, ma non farei uso di un Timer, bensì dei thread, in modo che le richieste effettuate via socket non blocchino l'applicazione.

Ciao!

[VaLvOnAuTa]

Originariamente inviato da alka
In sostanza, punterei - salvo restrizioni - sulla prima soluzione che hai proposto, ma non farei uso di un Timer, bensì dei thread, in modo che le richieste effettuate via socket non blocchino l'applicazione.

Ciao!

Grazie per la risposta. Gentilissimo come sempre.

Scusa l'ignoranza... aggiungo un IdThreadComponent all'applicazione.. ma è temporizzabile la sua esecuzione?
Non ho mai gestito threads quindi non saprei se è facile gestirli quanto un timer

[alka]

Originariamente inviato da VaLvOnAuTa
Scusa l'ignoranza... aggiungo un IdThreadComponent all'applicazione.. ma è temporizzabile la sua esecuzione?
Non ho mai gestito threads quindi non saprei se è facile gestirli quanto un timer

Non è un componente, ma una funzionalità del sistema operativo che in Delphi viene racchiusa dalla classe TThread della quale è necessario creare un discendente per personalizzare il codice che verrà eseguito in modo asincrono e indipendente dal thread principale dell'applicazione che, normalmente, gestisce i messaggi in arrivo sulla coda (clic, tasti, refresh e così via).

Anche il TTimer funziona attraverso un messaggio: è proprio per questo che se esegui una routine dispendiosa in termini di tempo nell'evento OnTimer l'applicazione risulta bloccata: fino a quando il codice nell'OnTimer non ha concluso il proprio lavoro, il thread principale dell'applicazione non passa alla gestione del messaggio successivo.

Usando thread separati, puoi eseguire codice in parallelo (simulato, a meno che tu non abbia più di una CPU) lasciando il thread principale libero di gestire gli eventi; è ovvio che questa opportunità va comunque controllata attraverso apposito meccanismi.

Se vuoi approfondire, leggi questo tutorial davvero ben fatto.

Ciao!

[VaLvOnAuTa]

Ti ringrazio tantissimo.
Il tutorial è chiarissimo e molto ben fatto.

Però, un collega mi ha dato una soluzione meno macchinosa (ammesso che si possa fare).
Se il server sparasse l'informazione in broadcast su una data porta (in multicast non saprei come fare) ed i client (che avranno un server in ascolto su quella porta) processassero l'informazione solo se li riguarda?
Anzichè sparare n pacchetti (quanti sono i client attivi) sulla rete ogni x secondi sparerei un unico pacchetto broadcast solo al momento in cui si verifica un evento registrato dal server.
E' una cosa fattibile?

[alka]

I "broadcast" in generale mi puzzano sempre di pericoloso.

Inoltre, se devi tenere aperto un server su quella porta, tanto vale mantenere nel server centrale una lista dei client collegati ed inviare ai rispettivi componenti server di ciascuno il messaggio con l'informazione in questione, implementando così un meccanismo bidirezionale che devi attuare anche nel caso tu intenda fare il broadcast (per poter ricevere il messaggio e gestirlo).

Ciao!