Delphi-PRAXiS
Seite 1 von 2  1 2      

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Object-Pascal / Delphi-Language (https://www.delphipraxis.net/32-object-pascal-delphi-language/)
-   -   Delphi Kommunikation zweier Instanzen im Lan (DB-Polling vs. TCP)! (https://www.delphipraxis.net/147804-kommunikation-zweier-instanzen-im-lan-db-polling-vs-tcp.html)

TheMiller 16. Feb 2010 19:21


Kommunikation zweier Instanzen im Lan (DB-Polling vs. TCP)!
 
Hallo,

ich stehe vor einem Problem :cry:

Ich habe ein Programm geschrieben, mit dem in einem Netzwerk ca. 10 Leute arbeiten. In diesem Programm ist eine Benutzerliste mit dem Online/Offline-Status und die Möglichkeit, den Usern Nachrichten zu schreiben.

Da einige Leute auch via VPN über einen SurfStick ins Lan kommen, würde ich gerne verhindern, ständig die MySQL-Datenbank nach Änderungen des BenutzerStati und neuen Nachrichten zu fragen.
Problem ist, dass das ganze Programm dann lahmt.

Deshalb wollte ich diese Sachen auf TCP (IdTCPServer/Client) umstellen. Doch hier ist das Problem, dass die User nicht immer die selbe IP haben (echte Lan-IP, VPN-IP mehrere Netzwerkkarten etc).

Ich brauche mal eure Entscheidungshilfe. Es geht also um TCP-Kommunikation vs MySQL-Polling.

Die SQL-Abfragen könnte ich in Threads packen. Damit würde das Programm nicht mehr lahmen. Nachteil wäre, dass nervige Fehlermeldungen kommen, wenn der Server nicht erreichbar ist/wird.

TCP ist direkt, geht schnell und nur dann, wenn man es braucht. Ich würde, wenn User C online kommt, allen anderen Usern eine TCP-Message wie "/updateOnlineUser" senden und die würden dann die Datenbank abfragen und sich die neuen Stati holen.
Nachteil hier ist die wechselnde IP-Adresse. Dagegen habe ich gearbeitet, indem ich zu jedem User bei Programmstart in der DB alle IP-Adressen speichere und dann, eine nach der anderen durchgehe und schaue, welche richtig ist. Diese speicher ich dann im User-Objekt (User.IP). Doch das hin-und-her von TCP-Messages, UpdateCommandos etc nimmt bei vielen Usern viel Zeit in Anspruch (gerade über VPN).

Ich bräuchte - wie gesagt - eure fachliche Meinung, Vor- und Nachteile oder ganz und gar andere Lösungen.

Vielen Vielen Dank im Voraus

s.h.a.r.k 16. Feb 2010 21:46

Re: Kommunikation zweier Instanzen im Lan (DB-Polling vs. TC
 
Einfach ein Broadcast via UDP, um alle Clients um Netzwerk herauszufinden. Diese melden dann ihre IP zurück. Es gibt auch einen Thread dies bzgl irgendwo, hab den aber noch nicht gefunden.

TheMiller 16. Feb 2010 22:40

Re: Kommunikation zweier Instanzen im Lan (DB-Polling vs. TC
 
Hm ja, udp war auch mein erster Gedanke. Habe dann aber gesehen, dass udp-Broadcasts nicht ohne Weiteres durch einen VPNTunnel wollen. Die UDP-BC müsste man erst in ein raw-Packet umwandeln, via TCP senden, Checksums berechnen und wieder umwandeln...

Das ginge also auch nicht.

alzaimar 17. Feb 2010 06:16

Re: Kommunikation zweier Instanzen im Lan (DB-Polling vs. TC
 
Du brauchst also ein Chat-Programm? Na das sollte nicht so schwer zu finden sein.

TheMiller 17. Feb 2010 10:52

Re: Kommunikation zweier Instanzen im Lan (DB-Polling vs. TC
 
Nein, ich brauche kein Chat-Programm ;)

Also. Das Programm ist modular aufgebaut und hat momentan ca. 11 Plugins. Unter anderen Kalender und Telefonnotizen. Im Hauptprogramm befindet sich eine Übersichtsseite und die Userliste. Diese Bereiche sind immer sichtbar. AUf der Übersichtsseite befindet sich eine kleine Liste mit den heutigen Terminen, Aufgaben und Tel-Notizen.

Nun möchte ich die Übersichtsseite und die User-Liste (On/Off) aktuell halten. Derzeit verwende ich dazu die db-polling Technik, indem ich einen Timer alle x Sekunden die db abfragen lasse. Der Chat (eher im SMS-Style gehalten) ist sekundär.

Ich wollte eigentlich bei Änderungen bei den gebieten "Neue Tel-Notizen, heutige Termine, Neue Aufgaben, User online gekommen, User offline gegangen" über TCP Strings schicken (eine Art Kommando) und bei Empfang dieses String die spezielle Aktualisierungs-Methode aufrufen

"if (s = "/updateTasks") then UpdateTasks"

Aber da das durch die VPN-Geschichte etwas kompliziert ist, weis ich nicht, ob sich dieser Aufwand lohnt. UDP durch VPN ist ja auch so eine Sache...

Für weitere Vorschläge oder Pro- und Contras bin ich dankbar.

franktron 17. Feb 2010 11:02

Re: Kommunikation zweier Instanzen im Lan (DB-Polling vs. TC
 
So was ähnliches hab ich auch gerade.
Das ist ganz einfach im OnConnect vom idTCPServer die IP des Client in einer TList speichern und beim Diesconnect wieder löschen und schon sieht man wer gerade online ist.

P.S. man kann auch Daten in die TList schreiben z.b. Username

chaosben 17. Feb 2010 11:54

Re: Kommunikation zweier Instanzen im Lan (DB-Polling vs. TC
 
Oder (wenn das eine Option ist) du nimmst eine (vernünftige ;) ) Datenbank, die Events unterstützt ... z.B. Firebird.
Da lässt du die DB ein Event an alle angemeldeten Clients schicken, das sich was geändert hat. Und die gucken dann nach, was los ist und zeigen den aktuellen Stand der Dinge an.
So machen wir das.

TheMiller 17. Feb 2010 13:04

Re: Kommunikation zweier Instanzen im Lan (DB-Polling vs. TC
 
Ja, habe gestern auch gelesen, dass FB sowas kann. Aber nein, das ist keine Option. Leider.

sirius 17. Feb 2010 13:26

Re: Kommunikation zweier Instanzen im Lan (DB-Polling vs. TC
 
Also wenn du keine vernünftige Datenbank (wie Oracle) hast, dann baust du dir eben einen TCP-Server auf den Datenbankrechner, und alle anderen Clients verbinden sich dahin.

mjustin 17. Feb 2010 16:15

Re: Kommunikation zweier Instanzen im Lan (DB-Polling vs. TC
 
Zitat:

Zitat von DJ-SPM
Ja, habe gestern auch gelesen, dass FB sowas kann. Aber nein, das ist keine Option. Leider.

Ein zweistufiges Polling wäre noch eine Alternative.

Dazu benötigt man eine kleine Tabelle in der Zeitstempel für Ereignisse eingetragen werden. D.h. wenn ein neuer Termin erfasst wird, aktualisiert das Programm in dem der Termin erfasst wird die ZEIT-Spalte der Zeile für 'Neuer Termin':

EREIGNIS ZEIT
Neuer Termin 2010-02-15 08:01:00 <-- Update
Neue Aufgabe 2010-02-15 08:04:00
Neue Notiz 2010-02-15 07:01:00
...

Jeder interessierte Client fragt diese Tabelle in kurzen Zeitabständen ab und vergleicht den Zeitstempel mit dem zuletzt gelesenen Wert. Erst wenn dieser Wert sich ändert, wird das eigentlich Select ausgeführt, das zu höherer Last führte.

Vorteil: keine weiteren Ports oder Chatserver erforderlich, arbeitet auf der bestehenden Basis. Nachteil: je nachdem wie schnell man die Ereignisse erkennen muss, muss auch diese Eventabfrage in entsprechend kurzen Zeitabständen erfolgen - mit Nachteilen für Netz- und DB-Belastung, aber deutlich weniger als bei einem Voll-Polling

Viele Grüße,


Alle Zeitangaben in WEZ +1. Es ist jetzt 05:07 Uhr.
Seite 1 von 2  1 2      

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz