Visualizzazione dei risultati da 1 a 10 su 10
  1. #1
    Utente di HTML.it L'avatar di VaLvOnAuTa
    Registrato dal
    Jun 2002
    Messaggi
    2,047

    [delphi] Applicazione client-server

    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

  2. #2
    Moderatore di Programmazione L'avatar di alka
    Registrato dal
    Oct 2001
    residenza
    Reggio Emilia
    Messaggi
    23,904

    Indy e client/server TCP

    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!
    MARCO BREVEGLIERI
    Software and Web Developer, Teacher and Consultant

    Homepage | Blog | Delphi Podcast | Altri link...

  3. #3
    Utente di HTML.it L'avatar di VaLvOnAuTa
    Registrato dal
    Jun 2002
    Messaggi
    2,047

    Re: Indy e client/server TCP

    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

  4. #4
    Moderatore di Programmazione L'avatar di alka
    Registrato dal
    Oct 2001
    residenza
    Reggio Emilia
    Messaggi
    23,904

    Re: Re: Indy e client/server TCP

    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.
    MARCO BREVEGLIERI
    Software and Web Developer, Teacher and Consultant

    Homepage | Blog | Delphi Podcast | Altri link...

  5. #5
    Utente di HTML.it L'avatar di VaLvOnAuTa
    Registrato dal
    Jun 2002
    Messaggi
    2,047
    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?

  6. #6
    Moderatore di Programmazione L'avatar di alka
    Registrato dal
    Oct 2001
    residenza
    Reggio Emilia
    Messaggi
    23,904
    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!
    MARCO BREVEGLIERI
    Software and Web Developer, Teacher and Consultant

    Homepage | Blog | Delphi Podcast | Altri link...

  7. #7
    Utente di HTML.it L'avatar di VaLvOnAuTa
    Registrato dal
    Jun 2002
    Messaggi
    2,047
    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

  8. #8
    Moderatore di Programmazione L'avatar di alka
    Registrato dal
    Oct 2001
    residenza
    Reggio Emilia
    Messaggi
    23,904
    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!
    MARCO BREVEGLIERI
    Software and Web Developer, Teacher and Consultant

    Homepage | Blog | Delphi Podcast | Altri link...

  9. #9
    Utente di HTML.it L'avatar di VaLvOnAuTa
    Registrato dal
    Jun 2002
    Messaggi
    2,047
    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?

  10. #10
    Moderatore di Programmazione L'avatar di alka
    Registrato dal
    Oct 2001
    residenza
    Reggio Emilia
    Messaggi
    23,904
    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!
    MARCO BREVEGLIERI
    Software and Web Developer, Teacher and Consultant

    Homepage | Blog | Delphi Podcast | Altri link...

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
Powered by vBulletin® Version 4.2.1
Copyright © 2020 vBulletin Solutions, Inc. All rights reserved.