Server-Antwort an mehrere Clients senden mit Indy

[Namenloser]

Eine andere Möglichkeit wären non-blocking Sockets. Da braucht man nicht für jeden Client einen Thread.

Eigentlich macht auch erst dann ein Thread-Pool Sinn. Wenn z.B. jede Operation eine Sekunde blockt, dann kannst du mit blockierenden Sockets selbst mit einem Threadpool mit 8 Threads nur mickrige 8 Operationen pro Sekunde machen, während du mit non-blocking Sockets in der gleichen Zeit vielleicht locker 1000 Operationen schaffen würdest, sogar völlig ohne Multithreading.

Also wenn man schon blockierende Sockets verwendet, dann muss man auch für jede Verbindung einen eigenen Thread haben.

[Valle]

"einen eigenen Thread mit eigener lokalen TidTCP-Komponente"? Ich hatte dich da wohl etwas falsch verstanden bei deiner Beschreibung. Kannst du nochmal erklären was genau dein Vorgehen jetzt ist?

Erstellst du von den Clients aus immer eine zweite Verbindung zum Server?
Oder öffnet der Server eine neue Verbindung zum Client (und der Client ist damit auch ein Server)?

Mein Gedanke ging mehr in die Richtung, die Namenloser andeutete. Alles geht über eine Verbindung. Wenn du Indy verwendest, dann nimmst du pro Verbindung einen Thread. Mit einer Queue kannst du die Menge an Threads minimieren. Über diese eine, einzige Verbindung pro Client gehen alle Daten.

Non-blocking ist gerade sehr in Mode und bietet deutliche Performance-Vorteile. node.js ist ein populär Vertreter für ganze non-blocking Frameworks. Das war auch mein Gedanke, als ich oben von "Designwechsel" sprach. Allerdings ist es bei Servern mit wenigen hundert Clients bei ordentlicher Implementierung noch gar kein Problem, egal welche Methode du verwendest.

[Harry Stahl]

Zitat von Valle:

"einen eigenen Thread mit eigener lokalen TidTCP-Komponente"? Ich hatte dich da wohl etwas falsch verstanden bei deiner Beschreibung. Kannst du nochmal erklären was genau dein Vorgehen jetzt ist?

Erstellst du von den Clients aus immer eine zweite Verbindung zum Server?
Oder öffnet der Server eine neue Verbindung zum Client (und der Client ist damit auch ein Server)?

Der Client fragt beim Server, nach einer Information, oder ob er irgendetwas tun darf. Mit der gleichen Verbindung erhält der Client die Rückantwort.

Wenn der Client aber dem Server neue oder geänderte Daten übermittelt, dann muss der Server die anderen Clients davon unterrichten, bzw. diesen die Änderungen mitteilen. Nur in diesen Fällen öffnet der Server auch eine Verbindung zu den Clients (und insofern arbeiten die Clients dann als Server).

Wenn 10 User im Netz 10 Änderungen machen, muss der Server 90 Nachrichten an die Clients versenden.

Und diese Übermittelung an die Clients habe ich nun in einzelne Threads ausgelagert. Allerdings in eine pro Client angelegte TThreadList, welche die Nachrichten nach dem FirstIn / FirstOut Prinzip abarbeitet. Arbeitet nach erstem Augenschein schnell und zuverlässig.

Zitat von Valle:

Non-blocking ist gerade sehr in Mode und bietet deutliche Performance-Vorteile. node.js ist ein populär Vertreter für ganze non-blocking Frameworks. Das war auch mein Gedanke, als ich oben von "Designwechsel" sprach. Allerdings ist es bei Servern mit wenigen hundert Clients bei ordentlicher Implementierung noch gar kein Problem, egal welche Methode du verwendest.

Das werde ich gerne mal ansehen, wenn ich ein wenig mehr Zeit habe. Da bei meinen Programmen i.d.R. max. 50 Anwender im Netz gleichzeitig mit einer DB arbeiten, dürfte das mit Indy noch lange Zeit reichen.

[Bambini]

Zitat von Harry Stahl:

Wenn der Client aber dem Server neue oder geänderte Daten übermittelt, dann muss der Server die anderen Clients davon unterrichten, bzw. diesen die Änderungen mitteilen. Nur in diesen Fällen öffnet der Server auch eine Verbindung zu den Clients (und insofern arbeiten die Clients dann als Server).

Dies werden die Firewalls auf den Clients erst mal nicht erlauben.

[Valle]

Zitat von Bambini:

Zitat von Harry Stahl:

Wenn der Client aber dem Server neue oder geänderte Daten übermittelt, dann muss der Server die anderen Clients davon unterrichten, bzw. diesen die Änderungen mitteilen. Nur in diesen Fällen öffnet der Server auch eine Verbindung zu den Clients (und insofern arbeiten die Clients dann als Server).

Dies werden die Firewalls auf den Clients erst mal nicht erlauben.

Jop, sehe ich auch so. Die Lösung ist denke ich eher sub-optimal.

Versuche alles über die bestehende Verbindung zu machen. Du hast doch bereits je eine Verbindung zu den Clients offen (oder?), dann kannst du die Daten doch über diese schicken?

Was das non-blocking angeht: Wenn es dich interessiert, dann will ich dich nicht aufhalten. Aber von einer Notwendigkeit würde ich hier nicht sprechen. ^^

[Harry Stahl]

Zitat von Valle:

Zitat von Bambini:

Zitat von Harry Stahl:

Wenn der Client aber dem Server neue oder geänderte Daten übermittelt, dann muss der Server die anderen Clients davon unterrichten, bzw. diesen die Änderungen mitteilen. Nur in diesen Fällen öffnet der Server auch eine Verbindung zu den Clients (und insofern arbeiten die Clients dann als Server).

Dies werden die Firewalls auf den Clients erst mal nicht erlauben.

Jop, sehe ich auch so. Die Lösung ist denke ich eher sub-optimal.

Dafür habe ich den Netzwerkverbindungstest entwickelt, welche die Anwender erst mal nutzen können, um die aus- und eingehende Verbindung zu testen und die Firewall entsprechend einzustellen (siehe anliegenden Screenshot).

Zitat von Valle:

[
Versuche alles über die bestehende Verbindung zu machen. Du hast doch bereits je eine Verbindung zu den Clients offen (oder?), dann kannst du die Daten doch über diese schicken?

Voraussetzung wäre dann, dass ich die Verbindung immer offen halte. Bislang habe ich nach jedem Server-Connect auch anschließend ein Disconnect durchgeführt.

Wenn ich aktiv mit dem Server was senden will, wie mache ich das? Ich habe gesehen, der Server hat eine Contexts-List. Nutze ich die, um an die Clients zu senden?

Und wie empfängt der Client die Daten? Die Client-Komponente hat doch gar kein On-Execute Event oder etwas vergleichbares.

[Harry Stahl]

Also dazu habe ich hier ein entsprechendes Thema gefunden:

http://stackoverflow.com/questions/5...nt-delphi-indy

Ich könnte dementsprechend einen Thread machen, der prüft, ob Eingänge vorliegen:

Delphi-Quellcode:

procedure TCommThread.Execute;
var
  Msg: String;
begin
  try
    while (AClient.Connected) do begin
       AClient.IOHandler.DefStringEncoding := IndyTextEncoding_UTF8;

       Msg := AClient.IOHandler.ReadLn;

       if Msg = 'irgendwas...' then begin
         Sychronize (dasOderdas);   
       end;

       if Msg = 'DisconnectClient' then begin
         break; // Thread beenden
       end;
    end;
  except
    on E:Exception do
      ErrorMsg := 'Error! ' + E.ClassName + '||' + E.Message;
  end;
end;

Nach ReadLn pausiert der IndyThread solange, bis eine Nachricht vom Server vorliegt.

Aber offesichtlich ist dann die Komponente solange auch nicht für das Senden von Nachrichten ansprechbar, oder?

Wenn ich versuchen mit der Componente etwas zu senden, kommt beim Server nur ein leerer String an (er sendet zwar, aber ohne Inhalt?).

EDIT: Korrektur: War mein Fehler, hatte beim Senden vergessen eine Kommandokennung zu setzen, geht also doch!!

Es ginge also tatsächlich mit nur einer Client-Server-Verbindung sowohl aktives Senden und Empfangen vom Client aus, so wie vom Server aus zu ermöglichen. Oder könnte sich da etwas ins Gehege kommen, wenn die Clientkomponente gleichzeitig wartet und gleichzeitig sendet?