Hallo!

Nehmen wir an, es gibt ein mittels TCPServerSocket aufgebautes Serverprogramm, das nach einem bestimmten Erreignis einen String an ca. 100 verbundene Clients senden soll. Hauptfunktion des Programms ist etwas ganz anderes, deswegen wird auf primitivste Weise gesendet:

markieren

Code:

...
sCount := ServerSocket1.Socket.ActiveConnections;
for i := 0 to sCount - 1 do
ServerSocket1.Socket.SendText('Passiert ist dies und das. Bla bla bla...');
...

Ich hatte bis jetzt mit Sockets nicht viel zu tun, weiß aber, daß im Fall TCP einen sicheren Kanal zwischen Client und Server bereitgestellt wird und beim Senden überprüfft wird, ob die Datenpakete ihr Ziel erreicht haben. Deswegen nehme ich an, dass bei dieser Schleife oben nach jedem Sendevorgang eine kurze in der regel kaum bemerkbare Pause entsteht und der Server erst dann an den nächsten Client sendet, wenn er eine Bestätigung bekommet hat. Bitte korigieren, wenn ich mich irre.

Und jetzt ist eine Beispielsiuation: Server geht über eine ziemlich schnelle Leitung ins Internet. Mehrere Clients sind zu dem Server verbunden. Die meisten benutzen DSL. Der Rest geht entweder über langsame DFÜ-Verbindungen oder sogar mobil über GPRS (was verdammt langsamm ist) ins Internet. Dann werden diese "schwarzen Schaffe" die ganze Schleife bremsen, oder?

Eigentlich brauche ich in meinem Fall keine Bestätigung des Klienten. Die Daten sollen blind zu den Gegenstellen gesendet werden, es ist mir absolut egal, ob die Daten dann ankommen oder nicht. Wichtig ist, dass sehr schnell gesendet wird. Was kann ich machen? Gibt es eine in meinem Fall sinvolle Alternative zu TCP? Wenn jamand einen einsetzbaren Code-Beispiel hat, werde ich mich sehr freuen.

Danke!

MfG,
Ralf

1. Möglichkeit:
Clients melden sich beim Server an und übermitteln ihre aktuelle IP, danach trennen sie sofort die Verbindung richten aber ihrerseits einen UDP Server ein. Der Server sendet nun an diese IP's UDP Packete mit den kurzen Nachrichten.

2. Möglichkeit:
Server wartet auf 2 verschiedenen Ports, jeder Port ist spezifisch je nach Geschwindigkeit der Clients. Clients mit DSL verbinden auf Port #1 und Clients mit GPRS auf Port #2.

3. Möglichkeit:
Server arbeitet asynchron und verschickt jedes Packet ohne auf dessen "Bestätigung" zu warten. Diese "Bestätigungen" kommen asynchrone rein als Events. Ob das mit ServerSockets so ohne weiteres geht weis ich nicht (nutze eigentlich nur Indy).

Gruß Hagen

Danke für schnelle Antwort!

Zitat von negaH:

Clients melden sich beim Server an und übermitteln ihre aktuelle IP, danach trennen sie sofort die Verbindung richten aber ihrerseits einen UDP Server ein. Der Server sendet nun an diese IP's UDP Packete mit den kurzen Nachrichten.

Bekomme ich dann Probleme, wenn ein Client hinter einem Router steckt?

Zitat von negaH:

Server arbeitet asynchron und verschickt jedes Packet ohne auf dessen "Bestätigung" zu warten. Diese "Bestätigungen" kommen asynchrone rein als Events. Ob das mit ServerSockets so ohne weiteres geht weis ich nicht (nutze eigentlich nur Indy).

Wie geht das denn?

Im Grunde mit Threads. Beim Indy Package spaltet der Server für jeden Client einen eigenen Thread ab, ergo kann ein Client nicht mehr die anderen Clients blockieren. Das geht auch im Windows API per Notifycallbacks, habe das aber nie selber bisher benutzt (warum auch wenn man mit Indy in 5 Minuten einen Server programmiert hat). Wichtig ist eben nur das der Clientcode im Server auch wirklich Threadorientiert ist und keine Synchronisationen mit dem Mainthread benötigt. Solche Fehler machen Anfänger gerne die im Server einen Fortschrittsbalken oder ähnliches einbauen wollen. Der Server sollte komplett ohne GUI->ergo Synchronisation auskommen und durchweg Threadbasiert arbeiten, dann gibts solche Probleme wie du sie hast nicht. Zudem dann der Server auch wirklich als echter Dienst laufen kann.

Tja, ob der Router oder die Firewall UDP's durchlässt hängt wohl erstmal nur von deren Konfiguration ab. Dazu muß der Client über dessen IP + Port freigeschaltet sein, das ist primär erstmal alles. Denn es macht technisch gesehen erstmal keinen Unterschied ob man über TCP/IP ein UDP oder HTML oder RPC oder sonstwas Prototoll fährt. Sekundär kann man aber die Router+Firewalls sehr wohl so einstellen das sie nicht nur IP's oder Port sperren sondern ganze Protokollklassen.

Ich persönlich hatte bei meinem Servern nie das Problem mit gemischten Clients (DSL+GPRS) und einem Performanceeinbruch dadurch. Allerdings nutze ich eben Indy -> ergo VCL und schei.e auf 700Kb mehr Codegröße.
Klar das A&O ist immer das Protokoll so zu bauen das man sehr kurze Verbindungszeiten hinbekommt. Fast alle meiner Server arbeiten sozusagen als Statemachines und benötigen keine permanente Verbindung zwischen Clients und Server. Gerade in Bezug auf Clients die über GPRS->Handy laufen ist dies sinnvoll da dort desöfteren die Abrechnung der verbrauchten Einheiten auch zeitgebunden ist. Hat man erstmal ein solches Statemachine-Protokoll implementiert ist es ein einfacher Compilerswitch um auf eine Permante Connection umschalten zu können. Auch dies ist manchmal erforderlich weil es eben auch GPRS Tarife gibt die teuer sind wenn man ständig neue Verdindungen aufbaut.

Aber dies ist ja schon offtopic und hilft dir nicht bei deinem konkreten Problem weiter.

Gruß Hagen

OK, wenn ich richtig verstehe, muss ich mich mit Indys um so was nicht kümmern, die Threads arbeiten unabhängig von einander, es kommt nicht zur Verzögerung. Eine andere Frage: die Haupfunktion des Server-Programms erledigen mehrere Threads, jeder von dennen verschiedene Informationen filtert und die Ergebnisse an alle Clients sendet. Manchmal wird die Sendeprozedur mehmals pro Sekunde aufgerufen. Ist das ein Problem? Wie gehe ich in diesem Fall richtig vor, so dass den Datenfluß durch Synchronisation nicht langsammer wird?

Also wenn ich dich richtig verstehe so erzeugt der Server Daten durch eigene Threads die dann an alle Clients gesendet werden müssen. Nun in der Frage steckt die Antwort. Zuerst erzeugen Threads Daten, schreibend und kein Client darf darauf Zugriff haben, wenn diese Threads fertig sind übergeben sie ihre Arbeit um sie an die Clients zu senden. Ab diesem Moment sind die Daten statisch unveränderlich und können readonly gemeinsam durch die Clientthread gelesen werden. Das wichtigste dabei sind also garnicht mehr die Daten ansich sondern die Laufzeit-Synchronisation zu den Daten -> Daten erzeugen durch separate Threads, readonly Daten durch Clientthreads lesen und verteilen. Es sollte eben nur zu den Daten ein Lebenszeitzähler verwaltet werden, d.h. beginnt ein Clientthread die Daten zu verteilen dann wird dieser Zähle inkrementiert ist er fertig dekrementiert er den Zähler. Die Synchronisation dieses Zähler ist der einzigst kritische Zeitpunkt und kann mit InterlockedIncrement() erschlagen werden. Nach einer gewissen Zeitdauer, bzw. wenn der Lebenszeitzähler auf 0 ist oder wenn neue Daten anliegen können die gemeinsammen Serverdaten freigegeben werden.

Von einer Vorstellung musst du dich gedanklich verabschieden: es kann keine Systeme geben die jedem Clienten zujedem Zeitpunkt die Daten in Echtzeit und mit realem Abblid liefern.

Gruß Hagen