Programmazione della rete Delphi

Question

Ho un classico programma client/server (fat client e database) scritto in Delphi 2006.Quando nel client vengono soddisfatte determinate condizioni, devo avvisare molto rapidamente tutti gli altri client.Fino ad ora questo è stato fatto utilizzando le trasmissioni UDP, ma questo non è più fattibile poiché i client ora si connettono dall'esterno della LAN e la trasmissione UDP è limitata alla rete locale.

Sono a conoscenza delle librerie Indy ma non sono veramente sicuro di quali componenti utilizzare e di come strutturarli.Immagino che avrò bisogno di un server a cui si connettono i client che riceverà e distribuirà i messaggi...?Qualche campione là fuori per iniziare?

Ci sono altri set di componenti o tecnologie che dovrei considerare invece/anche?

Answer 1

La risposta semplice è che i protocolli standard disponibili in Delphi (e altri strumenti) non consentono la notifica inversa.Ho esaminato questo problema per un progetto in cui volevo utilizzare SOAP.Presumono tutti che il client chieda al server, il server risponde e basta.

Per me, la soluzione era RemObjects SDK.Ciò ti consente di inviare notifiche ai client e la notifica può contenere tutti i dati che desideri (proprio come dal client al server).Io stesso utilizzo la connessione SuperTCP, ma funziona anche con gli altri.Può comunque offrire un'interfaccia SOAP per i client che devono utilizzarla, ma per i casi in cui si ha il controllo sia del client che del server funziona estremamente bene.

Answer 2

Ci sono alcuni modi davvero semplici per farlo con Delphi, anche se sono sicuro che anche RemObjects SDK funzioni davvero bene.

1. Avere un server centrale che abbia un * TIdTCPServer in ascolto* su di esso.Quindi ogni cliente ha a TIdTCPClient su di essa.Si connettono al server e bloccare una lettura in attesa per il server per scrivere.Una volta che il server riceve una notifica tramite un socket di ascolto, esso trasmissioni a ciascuno dei clienti in attesa.Questa è praticamente una notifica immediata per tutti i clienti.
2. Avere un server centrale che abbia un file TIdTCPServer in ascoltog su di esso.Quindi ogni cliente ha a TIdTCPClient su di essa.Quei clienti possono "ping" il server per richiedere aggiornamenti a intervalli regolari (utilizzare un token di sessione per mantenere lo stato).La frequenza dell'intervallo determina la rapidità della notifica.Quando una volta uno dei client deve avvisare gli altri, avvisa semplicemente il server.Il server utilizza quindi a coda di messaggi per creare un elenco di tutte le sessioni client attive e aggiungere una notifica per ciascuna.Quindi la prossima volta che ciascuno dei client si connette, gli dà la notifica e lo rimuove dalla coda.
3. Mantenere un tavolo di seduta nel database in cui ogni client aggiorna regolarmente di avere una sessione attiva e si rimuove quando si disconnette.Avrai bisogno di un processo di manutenzione che rimuova le sessioni morte.Allora hai un tabella della coda dei messaggi su cui un client può scrivere un aggiornamento con una riga per ogni sessione attiva corrente.Quindi gli altri client possono eseguire regolarmente il ping di quella tabella per vedere se ci sono notifiche in sospeso per la sua sessione, se ce ne sono può leggerle, agire su di esse e quindi rimuoverle.
4. Una specie di peer to peer approccio in cui i client sono consapevoli l'uno dell'altro attraverso le informazioni nel database e quindi si connettono direttamente tra loro e avvisano o chiedono notifiche (a seconda delle configurazioni del firewall e NAT).Un po’ più complesso, ma possibile.

Ovviamente la scelta dell'implementazione dipenderà dalla vostra configurazione e dalle vostre esigenze.La messa a punto sarà necessaria per ottenere i migliori risultati.

I componenti necessari per questo sono i TIdTCPServer (ascoltatore) e TIdTCPClient (mittente).Entrambi sono nelle biblioteche Indy di Delfi.

Answer 3

Componenti ICS da http://www.overbyte.be sono grandi.a.) Migliore compatibilità rispetto a Indy b.) Postcard Ware Buoni esempi e supporto.Utilizza TClientSocket e TServerSocket

Answer 4

Il progetto FirebirdSQL utilizza il concetto di notifiche come connessioni server-client che inviano una stringa al client.Per questo, il server db utilizza un'altra porta.E richiedere al client di registrarsi è interessante ricevere un certo tipo di notifica tramite una chiamata API.

Potresti usare la stessa idea.

Answer 5

RabbitMQ dovrebbe adattarsi al tuo conto.Il server è gratuito e pronto all'uso.Hai solo bisogno di un lato client per connetterti, inviare/inviare messaggi e ricevere/ritirare messaggi di notifica

Server: http://www.rabbitmq.com/download.htmlFai una ricerca su Google per il cliente o implementa te stesso

Saluti

Answer 6

Dovresti essere in grado di utilizzare Multicast UDP per lo stesso scopo.L'unica differenza sarà l'adesione al gruppo multicast da ogni client.

http://en.wikipedia.org/wiki/IP_Multicast

http://en.wikipedia.org/wiki/Internet_Group_Management_Protocol

Modificare: Tanto per essere più chiari, il multicast permette di entrare a far parte di un dato "gruppo" associato ad un indirizzo IP multicast.Qualsiasi pacchetto inviato a quell'indirizzo raggiungerà ogni cliente che si è unito al gruppo

Answer 7

Puoi guardare il componente weonlydo wodVPN che ti consente di creare un robusto punching UDP e ottenere un port forwarding o una normale VPN (con un adattatore di rete fornito) in modo da poter connettere due PC dietro un NAT.

Sto usando questo controllo per il nostro programma di comunicazione e funziona molto bene.