Wo im Client auf Nachrichten vom Server warten?

[QuickAndDirty]

Ich will in einem TIDTCPClient Dauerhaft eine Verbindung zum TCPServer halten und auf Messages vom Server warten.
Wo mache ich das am besten?
Brauche ich dafür einen eigenen thread oder passiert das schon alles in IndyThreads?

Zurzeit Habe ich einen kleinen Handshake in OnClientConnect
der so aussieht.

Delphi-Quellcode:

procedure TFTAPPRCMain.OnClientConnected(Sender: TObject);
begin
  var ClientLeaseRequest :TClientLeaseRequestMessage;
  ClientLeaseRequest.Init;
  ClientLeaseRequest.LeaseKey := LEASEKEY;
  RClient.IOHandler.Write(ClientLeaseRequest.ToIdBytes);
  If RClient.IOHandler.InputBufferIsEmpty then
  Begin
    RClient.IOHandler.CheckForDataOnSource(1000);
    RClient.IOHandler.CheckForDisconnect;
    if RClient.IOHandler.InputBufferIsEmpty then
      Exit;
  end;
  var IDbytes:TidBytes;
  RClient.IOHandler.InputBuffer.ExtractToBytes(IDbytes);
  var ClientLeaseResponse :TClientLeaseResponseMessage;
  ClientLeaseResponse.LoadFromIDBytes(IDbytes);
  If (ClientLeaseResponse.MSGType = $0002 ) and
     (ClientLeaseResponse.MagicCookie = MagicCookie) and
     (ClientLeaseResponse.MSGVersion = 1) then
  Begin
    LeaseCode := ClientLeaseResponse.MSGReturnCode;
    TThreadedLog.LogD('ClientLeaseResponse ReturnCode ='+ClientLeaseResponse.MSGReturnCode.ToString);

    // Soll Ich hier ne "While Active" schleife mit
    // Sowas in der Art platzieren?
    (*
      While Active do
      Begin
        If RClient.IOHandler.InputBufferIsEmpty then
        Begin
          RClient.IOHandler.CheckForDataOnSource(1000);
          RClient.IOHandler.CheckForDisconnect;
          if RClient.IOHandler.InputBufferIsEmpty then
            Continue;
        end;
        var IDbytes:TidBytes;
        RClient.IOHandler.InputBuffer.ExtractToBytes(IDbytes);    
        Logik(IDBytes); // Oder TLogikthread.create(IDbytes).start; ??? 
      end;
    *)
    
  End;
end;

Oder sollte ich die Ganze Schleife zum warten auf Nachrichten in einen anderen Thread packen statt in OnClientConnected?
Passiert OnClientConnected im Hauptthread oder in einem Indy Thread?
Ich weiß, dass ich das alles durch Experimente rauskriegen kann...es wäre halt nur toll wenn einer das alles wüsste und ich es gleich richtig machen könnte.

[Neumann]

Eigentlich ist es einfacher wenn der Client nachfragt ob es was neues gibt.
Er kann ja z.B. alle 10s fragen oder auch wenn er neue Daten haben will.

[QuickAndDirty]

Es ist schon notwendig die Leitung offen zu halten, sonnst muss ich eine Speicherlösung für den Server bauen.
Es sollen interaktiv Daten weitergeleitet werden.

[jaenicke]

Du solltest generell nicht länger in OnConnected (oder anderen Events) bleiben. Du kannst dort aber einen Thread starten, diesem dein Indy-Objekt und eine Callback-Funktion für Antworten geben und im Thread dann in einer Schleife auf neue Daten prüfen, die dann die Callbackfunktion übergeben bekommt.

[Stolle58]

Auf Githup gibt es die Indy-Demos.

siehe hier.

[QuickAndDirty]

Zitat:

Zitat von jaenicke (Beitrag 1545511)

Du solltest generell nicht länger in OnConnected (oder anderen Events) bleiben. Du kannst dort aber einen Thread starten, diesem dein Indy-Objekt und eine Callback-Funktion für Antworten geben und im Thread dann in einer Schleife auf neue Daten prüfen, die dann die Callbackfunktion übergeben bekommt.

OK So mache ich das.
Also sind die Ganzen Indy Ereignisse alle im Hauptthread und IOHandler.Write und IOhandler.Read sind blocking und sollten besser in einem Nebenthread durchgeführt werden, nehme ich an.
Steht "OnWork" irgendwie ein bezug zu nicht blockierenden operationen ? Oder bin ich da wieder auf was ganz anderes gestoßen?

Zitat:

Zitat von Stolle58 (Beitrag 1545525)

Auf Githup gibt es die Indy-Demos.

siehe hier.

Danke, manche davon sind echt gut .

[jaenicke]

Generell:
Indy verwendet blockierende Sockets. Daher blockieren die darunterliegenden Funktionen immer. Du kannst stattdessen ICS mit nicht-blockierenden Sockets verwenden. Das funktioniert asynchron und eventbasiert deutlich schöner.

[stahli]

Falls es Dir hilft... https://www.delphipraxis.net/190482-...ockettest.html

[QuickAndDirty]

Vielleicht sollte ich das als eigens Thema eröffnen, aber :
Ist es möglich einen TIDTcpClient an einen ReadThread und an einen WriteThread zu übergeben und Kontinuierlich zu senden und gleichzeitig zu lesen?
Also NICHT abwechselnd:

Code:

ping pong ping pong ping pong

sondern parallel

Code:

Thread1: ping ping ping ping ping ping 
thread2:      pong pong pong pong pong pong

[jaenicke]

Grundsätzlich kannst du bei Indy zwei Threads verwenden, aber du kannst nicht genau parallel senden und empfangen. Diese Vorgänge selbst musst du z.B. mit TMonitor absichern.

Wenn du wirklich genau parallel senden und empfangen möchtest, empfehle ich ICS. Das funktioniert mit nicht-blockierenden Sockets und asynchronem I/O, ist aber nicht komplett threadsicher. Das bedeutet, soweit ich es verstanden habe, dass du bei TWSocket gleichzeitig in einem Thread SendStr und in einem ReceiveStr nutzen kannst, aber nicht mehrfach die gleiche Operation parallel.

[QuickAndDirty]

Ich bin so ein bisschen auf Indy eingeschossen.
Sprich... ich habe hier nen haufen Code für Indy geschrieben...
Also kann ein Lese-thread und ein Schreib-Thread in einem Indy-TCPClient nicht wirklich zeitgleich lesen und schreiben, sondern eben nur entweder oder?
Also muss ich das Scheduling mit Sleep(1) anstupsen und timeperiodBegin auf 1ms runtersetzen und kleinere chunks lesen /schreiben , damit es sich "kontinuierlich" anfühlt, während ich mit Tmonitor absicher das niemals lesen und schrieben gleichzeitig in einem Client stadtfinden?

Es ist quasi das selben wie mit einem einzige thread in dem abwechselnd gelesen und geschrieben wird in einer Terminate-Schleife?

[jaenicke]

Zitat:

Zitat von QuickAndDirty (Beitrag 1545771)

Es ist quasi das selben wie mit einem einzige thread in dem abwechselnd gelesen und geschrieben wird in einer Terminate-Schleife?

Solange du in dem Thread nicht auf die nächsten Daten wartest, sondern immer nur schaust, ob etwas da ist und sonst ggf. schreibst, ist das am Ende das Gleiche, ja.

ICS hat noch andere Vorteile, unter anderem dass eine aktuelle OpenSSL-Version verwendet wird.

[mjustin]

Zitat:

Zitat von QuickAndDirty (Beitrag 1545771)

Ich bin so ein bisschen auf Indy eingeschossen.
Sprich... ich habe hier nen haufen Code für Indy geschrieben...
Also kann ein Lese-thread und ein Schreib-Thread in einem Indy-TCPClient nicht wirklich zeitgleich lesen und schreiben, sondern eben nur entweder oder?

Lesen in Thread A und Schreiben in Thread B auf der gleichen TIdTCPClient-Instanz ist threadsafe möglich. Ein einfaches Beispiel in Indy ist die TIdTelnet-Komponente.
Sie liest aus derselben Connection in einem separaten Thread eingehende Nachrichten vom Telnet-Server, und und im Hauptthread schreibt sie ausgehende Nachrichten an ihn.
Das geht natürlich nur, wenn das Protokoll nicht auf Request/Response basiert. Telnet ist nicht Request/Response-basiert.

[Mavarik]

Gleichzeitig senden und empfangen?
Aber nicht zum gleich Ziel, oder?
Das klingt mir nach 2 Verbindungen.

Wenn es das selbe Ziel ist - kann das den der Server?

Ein bisschen mehr Background könnte helfen.

Mavarik

[QuickAndDirty]

Ich mein TCP handelt doch immer einen Port for die eine richtung und einen für die andere, das richtung aus oder?
Also müsste ich doch einen Empfangsthread

Delphi-Quellcode:

  If Client.IOHandler.InputBufferIsEmpty then
  Begin
    Client.IOHandler.CheckForDataOnSource(1000);// vielleicht nur 10 ms pro durchlauf?
    Client.IOHandler.CheckForDisconnect(False);
    if Client.IOHandler.InputBufferIsEmpty then
      Exit;
  end;

  var IDbytes:TidBytes;
  Client.IOHandler.InputBuffer.ExtractToBytes( IDbytes );

und einen Sendethread betreiben können.

[Mavarik]

Naja ich frag nochmal:

Was willst Du erreichen?

[QuickAndDirty]

Das ist in etwas die Architektur

Code:

Legende:
Client -> Server
Server <- Client

Achritektur:
Peer/TCPClient  -> RelayServer <- RelayClient -> Server/TCPServer

Peer sendet Kontinuirlich Messages in "TCP+Proprietär" oder HTTP-SOAP je nach setup.
Peer erwartet Antworten.
Es geht mit um den RelayClient, er muss kontinuirlich TCP traffic egal wie er geformt ist in beide Richtungen in verarbeiteter Form durchleiten.
Verarbeitung ist notwendig da Peer-Informationen an den Daten hängen die von RelayServer an RelayClient gehen und wieder zurück.
Ich arbeite gerade am RelayClient.