schnelle Server Client Verbindung ohne Verluste

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

[Kas Ob.]

Zitat von 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)

I test the client only that you pointed to at https://www.delphipraxis.net/1547906-post56.html
As i have working and fixed server, and i had point the most critical problem in the server in earlier post i fixed one method and the server no more using high CPU and sending and reading right, although i mentioned there is so many problem with code...
anyway when i suggested a fix on the client then i used your client you pointed to in the same post https://www.delphipraxis.net/1547906-post56.html , now the client is receiving right and both works, although again there is so many problem in both ....

Anyway you server in https://www.delphipraxis.net/1547906-post56.html didn't adopt my fixes yet it is working, but by your broken design you should run server then client then click send ( the button) on the client then and only then you can click the button the server, the server is not logging anything by your code in the post mentioned https://www.delphipraxis.net/1547906-post56.html
but the client is receiving fine and looking at WireShark there is no problem whatsoever on in sending and receiving on both.

Your server is adopting broken way to send, as send to the last client, and so many problem as i pointed many of them..

My suggestions both are perfect fix for one and only one method, test them or adopt them, it is up to you but for sure i tested and confirm they fix your main problem which is send and receiving with minimum CPU usage.