schnelle Server Client Verbindung ohne Verluste

[Kas Ob.]

Zitat von AJ_Oldendorf:

Ich muss gestehen, der Umgangston lässt leider nach.

Ich habe in procedure TForm1.Log(aStr : String); UND procedure TForm1.UpdateTimerTimer(Sender: TObject); jeweils ein Exit an erster Stelle eingebaut. Trotzdem wird der Write-Aufruf nur genau 5x durchlaufen und beim 6ten Mal hängt dieser. Es hat nichts mit der VCL zu tun und ich würde mich über einen netteren Umgangston wieder freuen

Edit:
Am besten mal hier ein Breakpoint machen und gucken, wie oft er rein kommt obwohl die Liste 100 Einträge hat

Data.Context.Connection.IOHandler.WriteDirect(Data.Daten);

Tariff it is !

Seriously, using or lets rephrase it, touching VCL of any kind is wrong, so Log method should be somewhere else not in any kind of TForm, also running the code a see the server is sending fine !

The problem is client is not receiving, it is not performing a real read over socket, the buffer is client side, and here i mean the TCP socket receiving buffer is full, and that after window sliding, hence an ACK is not received by server to continue sending (send over socket), at low level you poll the state of the socket and send only if the socket sate is ready to send, this is not happening on server side, due the accumulation of the data on client side.
That is the server write/send problem with above code.

in other words you must ensure to empty the buffer as soon as possible.

[Kas Ob.]

Here how you can spot it on WireShark
2025-04-08 16_47_40-_Adapter for loopback traffic capture.jpg

[Kas Ob.]

Better screenshot to point the values and the how the receiving window shrank with each recv
2025-04-08 16_47_40-_Adapter for loopback traffic capture.jpg

Notice the server has adjusted its receiving window to the exact received length after the client performed the full send, this is one perk of the Windows TCP stack, dynamically resize, even it wasn't needed, but taking it as this socket had received this then it can handle it again, on other side the window size sent by the client in the ACK, was shrinking until depletion, so server stopped sending and put the socket in not ready to send state, and it will wait until something from the client namely ACK ( being alone or combined with packet) to resume the socket state.

Also this behavior in the screenshot is on loopback, and it is different in few details when the NIC (Network Adapter and its driver) involved.

[AJ_Oldendorf]

Danke Kas Ob., habe ich verstanden.
Ich kümmere mich erstmal um den Empfang im Client.

Kann mal jemand auf die letzte Variante schauen?
Im Client läuft der TReceiveThread.Execute die ganze Zeit aber der InputBuffer ist immer leer. Irgendwie sehe ich das Problem gerade nicht, der Server schickt die Daten ja ab mit dem Write-Befehl

[AJ_Oldendorf]

Noch eine Anmerkung:
Wenn ich vom Server nicht TIdBytes verschicke mit Write/WriteDirect, sondern ein einfachen String mit WriteLn,
wird es vom Client in dem ReceiveThread mit ReadLn auch empfangen.
Ich will aber vom Server TIdBytes senden und im Client TIdBytes empfangen.
Jemand eine Idee, was da falsch sein könnte?

Edit:
Mit der Version habe ich zuletzt getestet:
https://www.delphipraxis.net/1547906-post56.html

[jaenicke]

Zitat von AJ_Oldendorf:

Im Client läuft der TReceiveThread.Execute die ganze Zeit aber der InputBuffer ist immer leer. Irgendwie sehe ich das Problem gerade nicht, der Server schickt die Daten ja ab mit dem Write-Befehl

Ich bin gestern nicht dazu gekommen und konnte eben auch nur einen kurzen Blick auf den Code aus deinem letzten Beitrag werfen, aber ich sehe nicht, wo du den Context in deinen Daten zuweist. Du setzt das in Button1Click auf nil und dann auf den Context aus LastRecData, aber wie soll der denn da reinkommen, wenn er immer nur nil war?

Ich gehe also davon aus, dass das Senden an dieser Zeile scheitert:

Delphi-Quellcode:

        if Assigned(Data.Context) and Assigned(Data.Context.Connection) then
        ...

Das solltest du aber doch sofort im Debugger sehen, wenn du da zeilenweise durchgehst.

[AJ_Oldendorf]

Ich habe den Code nochmal aktualisiert aber ich arbeite mit LastContext (wird sich beim Empfang gemerkt).
Das mit dem Context in dem Record, habe ich nur vorbereitet wenn mehrere verschiedene Clients sich anmelden.
Im Debugger wird das .Write auch aufgerufen, er bricht also vorher nicht ab.
Ich behaupte, es liegt am Client.
Sende ich im Server nicht mit .Write sondern alternativ mit WriteLn, reagiert der ReceiveThread im Client auch darauf mit ReadLn. Ich will ja aber TIdBytes verschicken

[Kas Ob.]

The problem is checking or polling on IOHandler.InputBuffer.Size in TReceiveThread.Execute;
if FParent.FParentClient.IOHandler.InputBuffer.Size > 0 then Try it this way, the right one

Delphi-Quellcode:

procedure TReceiveThread.Execute;
var
  Buffer : TIdBytes;
  RecData : TDataRec;
begin
  while not Terminated do
  begin
    if Assigned(FParent) and Assigned(FParent.FParentClient) and FParent.FParentClient.Connected then
    begin

      FParent.FParentClient.IOHandler.ReadBytes(Buffer, -1, False); // blocks and wait, no need to Ssleep()

      if Length(Buffer) > 0 then
      begin
        RecData.Daten := Buffer;
        RecData.Context := Nil;
        FDataQueue.Enqueue(RecData);
        Inc(Anz, Length(Buffer));

        TThread.Queue(nil,
          procedure
          begin
            TForm1(FParent.FForm).Log('Received ' + Length(Buffer).ToString + ' bytes');
          end
        );
      end;
    end;
  end;
end;

This will fix reading and client is reading everything now, this is a right fix but really the whole code should be refactored better.

About Nagle and it is important : you don't need it if you are sending huge buffers !, just in case sending small packets at very short times frequently, so it will not have an impact on you performing client/server.

[AJ_Oldendorf]

Danke Kas Ob. für die Korrektur des Codes allerdings funktioniert auch dieser nicht.
Hast du den Code getestet von dir?

Ein Breakpoint auf if Length(Buffer) > 0 then reicht aus, dort kommt der Debugger nämlich nie an.
Der Server ruft das Write auf (dort lande ich wie bereits gesagt, 5x im Debugger)