Server-Antwort an mehrere Clients senden mit Indy

[Valle]

Zitat:

Zitat von Bambini (Beitrag 1305386)

Zitat:

Zitat von Harry Stahl (Beitrag 1305357)

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:

Zitat von Valle (Beitrag 1305436)

Zitat:

Zitat von Bambini (Beitrag 1305386)

Zitat:

Zitat von Harry Stahl (Beitrag 1305357)

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:

Zitat von Valle (Beitrag 1305436)

[
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?

[Harry Stahl]

Zwar kann man mit der Clietkomponente senden, aber nicht gleichtzeiig was zurücklesen, weil das der wartende ReaLn-Thread abfangen würde.

Das ist doof, weil man dann inderekt alles über den wartenden Thread machen müsste.

Das geht hier also nicht, während der ReadLn-Thread (siehe oben) wartet:

Delphi-Quellcode:

  With AClient do begin
    if Connected then begin
      IOHandler.DefStringEncoding := IndyTextEncoding_UTF8;
      try
        Temppassw := gns ('Password', FileInfo);
        IOHandler.WriteLn (FileInfo); // FileInfo contains the File to load
      except
      end;

      Tm:= TMemoryStream.Create;

      //sleep (1000); // Let the Server time to read the file

      try
        //while connected do begin
        InSize := IOHandler.ReadLn.ToInteger;
        IOHandler.ReadStream (TM, InSize, false);
        //end;
      except
      end;
  end;
end;

Hier gibt es eine Exception und der wartende ReadLn-Thread fängt mir hier das ReadLn ab (kriege also nicht den Wert von Insize).

[Valle]

Leider kann ich dir mit Indy nicht weiterhelfen. Meine Delphi-Zeiten sind schon länger vorbei. :oops:

Üblicherweise bekommst du von einem Serversocket pro Verbindung ein eigenes Socket-Objekt. Die Methode nennt sich accept(). Die zurückgegebenen Sockets repräsentieren dann eine Verbindung zu einem Client. Man händelt also (Anzahl Clients + 1) Sockets in einem Server. Lesen und Schreiben auf solchen Sockets geschieht über read() und write() Methoden (meist blockierend).

Wie das mit Indy geht; keine Ahnung. Dazu gibt es aber doch sicherlich Beispiele? Google meint, es gibt sogar Thread-Pool Komponenten, die dir einen großen Teil der Arbeit abnehmen. Alternativ kannst du dich ja auch mit low-level Sockets befassen, wenn du Lust hast. Man lernt sicher einiges dazu. :thumb:

[Harry Stahl]

Zu diesem Thema gibt es anscheinend kaum Informationen im Netz.

Bei einem kurzen Implementierungstest zeigen sich mehrere Probleme. Ich lass das daher erst mal.

Habe mit der beidseitigen Kommunikationslösung (Client ist gleichzeitig auch Server) eine gut funktionierende Lösung gefunden will daher jetzt nicht mit allzu vielen Unbekannten quasi noch mal von vorn anfangen.

Aber dennoch vielen Dank für die interessanten Informationen und Denkanstöße.