AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Netzwerke Server-Antwort an mehrere Clients senden mit Indy
Thema durchsuchen
Ansicht
Themen-Optionen

Server-Antwort an mehrere Clients senden mit Indy

Ein Thema von Harry Stahl · begonnen am 16. Jun 2015 · letzter Beitrag vom 18. Jun 2015
Antwort Antwort
Namenloser

Registriert seit: 7. Jun 2006
Ort: Karlsruhe
3.724 Beiträge
 
FreePascal / Lazarus
 
#1

AW: Server-Antwort an mehrere Clients senden mit Indy

  Alt 16. Jun 2015, 21:25
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.
  Mit Zitat antworten Zitat
Benutzerbild von Valle
Valle

Registriert seit: 26. Dez 2005
Ort: Karlsruhe
1.223 Beiträge
 
#2

AW: Server-Antwort an mehrere Clients senden mit Indy

  Alt 16. Jun 2015, 23:44
"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.
Valentin Voigt
BOFH excuse #423: „It's not RFC-822 compliant.“
Mein total langweiliger Blog
  Mit Zitat antworten Zitat
Benutzerbild von Harry Stahl
Harry Stahl

Registriert seit: 2. Apr 2004
Ort: Bonn
2.561 Beiträge
 
Delphi 12 Athens
 
#3

AW: Server-Antwort an mehrere Clients senden mit Indy

  Alt 17. Jun 2015, 01:23
"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.

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.
  Mit Zitat antworten Zitat
Bambini
(Gast)

n/a Beiträge
 
#4

AW: Server-Antwort an mehrere Clients senden mit Indy

  Alt 17. Jun 2015, 09:51
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.
  Mit Zitat antworten Zitat
Benutzerbild von Valle
Valle

Registriert seit: 26. Dez 2005
Ort: Karlsruhe
1.223 Beiträge
 
#5

AW: Server-Antwort an mehrere Clients senden mit Indy

  Alt 17. Jun 2015, 13:51
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. ^^
Valentin Voigt
BOFH excuse #423: „It's not RFC-822 compliant.“
Mein total langweiliger Blog
  Mit Zitat antworten Zitat
Benutzerbild von Harry Stahl
Harry Stahl

Registriert seit: 2. Apr 2004
Ort: Bonn
2.561 Beiträge
 
Delphi 12 Athens
 
#6

AW: Server-Antwort an mehrere Clients senden mit Indy

  Alt 17. Jun 2015, 18:13
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).

[
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.
Angehängte Grafiken
Dateityp: jpg servertest.jpg (66,8 KB, 30x aufgerufen)
  Mit Zitat antworten Zitat
Benutzerbild von Harry Stahl
Harry Stahl

Registriert seit: 2. Apr 2004
Ort: Bonn
2.561 Beiträge
 
Delphi 12 Athens
 
#7

AW: Server-Antwort an mehrere Clients senden mit Indy

  Alt 18. Jun 2015, 10:58
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 = 'DisconnectClientthen 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?

Geändert von Harry Stahl (18. Jun 2015 um 11:10 Uhr)
  Mit Zitat antworten Zitat
Antwort Antwort


Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 04:02 Uhr.
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz