schnelle Server Client Verbindung ohne Verluste

[Papaschlumpf73]

Von IPWorks gibts auch eine kostenlos nutzbare (leider auch etwas eingeschränkte) Delphi-Edition über GetIt.

[AJ_Oldendorf]

NSoftware : IP Works / IP Works SSL muss ich mir mal angucken, auch was es da über GetIt gibt.

Aktuell sieht es so aus:

Server:

Delphi-Quellcode:

IdTCPServer.DefaultPort  := PipePort;
IdTCPServer.OnConnect    := IdTCPServerConnected;
IdTCPServer.OnDisconnect := IdTCPServerDisconnected;
IdTCPServer.OnException  := IdTCPServerException;
IdTCPServer.OnExecute    := IdTCPServerExecute;
IdTCPServer.Active       := True;

procedure IdTCPServerExecute(AContext: TIdContext);
begin
  if IdTCPServer.Active then
  begin
    AContext.Connection.IOHandler.CheckForDataOnSource(10);

    if not AContext.Connection.IOHandler.InputBufferIsEmpty then
    begin
      InData := AContext.Connection.IOHandler.ReadLn('#~#*' + EOL, 100, -1, IndyTextEncoding_UTF8);
      if InData <> '' then
      begin
        //mach irgendwas
      end;
  end;
end;

Im IdTCPServerConnected, IdTCPServerDisconnected und IdTCPServerException sind nur Protokollierungen. Die sind aber auch nicht zu sehen, kommen also nicht (außer natürlich das 1x Connect, da ein Client sich verbindet).

Client:

Delphi-Quellcode:

IdTCPClient1.OnConnected    := IdTCPClientConnected;
IdTCPClient1.OnDisconnected := IdTCPClientDisconnected;
IdTCPClient1.OnStatus       := IdTCPClientStatus;
IdTCPClient1.Host := aServerIP;
IdTCPClient1.Port := aPort;

procedure TMyThread.Execute;
begin
  while not Terminated do
  begin
    IdTCPClient1.IOHandler.CheckForDataOnSource(10);

    if not IdTCPClient1.IOHandler.InputBufferIsEmpty then
    begin
      InData := IdTCPClient1.IOHandler.ReadLn('#~#*' + EOL, 100, -1, IndyTextEncoding_UTF8);

      if InData <> '' then
      begin
        //mach irgendwas
      end;
  end;
end;

Im IdTCPClientConnected, IdTCPClientDisconnected und IdTCPClientStatus sind nur Protokollierungen. Die sind aber auch nicht zu sehen, kommen also nicht (außer natürlich das 1x Connect, da der Client sich verbindet).

Natürlich ist noch mehr Quelltext drum herum aber das ist die Implementierung von Server und Client.
Wie gesagt, der Server schickt im Durchschnitt 60 Datensätze (unterschiedlicher Inhalt) pro Sekunde mit einer Länge von 13 Byte bis max 61000 Byte

[Papaschlumpf73]

Stefan meinte wohl das hier im .Execute

Delphi-Quellcode:

      if InData <> '' then
      begin
        //mach irgendwas
      end;

Hier sollten die Daten nur weggespeichert und ggf. durch einen anderen Thread verarbeitet werden. Sonst kann hier ein Flaschenhals entstehen.

[fisipjm]

Darf ich dazu mal eine "blöde" Frage stellen?
Was für Daten möchtest du denn Übertragen? Was bedeutet denn Datensätze?
Ich würde es mir an deiner Stelle nicht so kompliziert machen. Um Daten von einem Server zu einem Client zu Übertragen schlägt man sich normalerweise nicht mehr mit TCP und dem ganzen geraffel herum.

Best-Practice wäre aus meiner Sicht folgendes:
1.) Auf der Server Seite setzt du dir einen kleinen Webserver auf. Minimale Lösung z.B. Horse. (Bei der Gelegenheit kann man sich auch gleich mal mit Boss auseinandersetzen, vom Grundprinzip sowas wie der Packagemanager nvm nur für Delphi). Wenn du dann auch noch jwt als middleware nutzt, hast du auch gleich noch etwas das sich brauchbar um die Verschlüsslung deiner Kommunikation kümmert.
2.) Deine Datensätze Packst du in Klassen. Wenn du mehrere Datensätze auf einmal Schicken willst packste dir die Klassen in ein Tarray<MyClass> und lässt es danach mit TJSON.ObjectToJSONStr serialisieren. (oder du nimmst gleich irgend ein ORM, oder, oder, oder)


Vorteile:
Aus meiner Sicht kommst du damit locker an die von dir angesprochenen ca. 3,5 MB pro Sekunde (61000Byte x 60(Pakete/s) / 1024 / 1024) hin.
Du brauchst dich nicht mehr um die Reihenfolge kümmern.
Du brauchst dich nicht mehr um das ganzen TCP/IP Connection Zeug kümmern.

Nachteil:
Overhead des HTTP layers, aber wie gesagt, deine Datenrate solltest du damit dicke schaffen.

Ansonsten kannst du die auch mal Websocket zu diesem Thema anschauen. Das ist aber eine ganze Ecke komplizierter.

vG
PJM

[AJ_Oldendorf]

Zitat:

Stefan meinte wohl das hier im .Execute

Also ich habe jetzt jeweils nach dem Senden und Empfang keiner weiteren Aktivitäten mehr, der Client hängt trotzdem hinterher (wesentlich!).

Ein Versuch wäre noch, beides mal wirklich in kleine separate Threads auszulagern, jetzt ist noch ein wenig Overhead drum herum was vielleicht ein Problem sein könnte. Ich werde dazu berichten.

Zitat:

Darf ich dazu mal eine "blöde" Frage stellen?

Also im Endeffekt sind das codierte Strings die dann irgendwelche Commands enthalten und irgendwelche Werte / Signale.

Zitat:

Ich würde es mir an deiner Stelle nicht so kompliziert machen

Naja, das TCPIP Connect/Disconnect geht ja prinzipiell. Dein Vorschlag mir Server und irgendeiner Middleware und JSON etc hört sich aus meiner Sicht erstmal kompliziert an, da davon bei uns aktuell 0 existiert und man sich damit von Grund auf neu beschäftigen müsste. Das andere ist ja da und muss nur implementiert werden. Nicht falsch verstehen, ich bin gerne offen für eine andere Lösung aber wenn dazu erst noch dies und das eingerichtet/gehostet werden muss, ist das nicht praktikabel in unserem Fall. Es soll am Ende nur von einer Windows Anwendung zu einer anderen Windows Anwendung Daten übertragen werden. Diese läuft jeweils auf einem anderen Rechner. Server schickt dem Client was, Client kann dem Server antworten. Das ist das Grundprinzip

Zitat:

Vorteil wäre das man damit das dann auf Geschwindigkeit optimieren kann, wo TCP systembedingt langsamer sein muss.

Genau das habe ich auch schon versucht mit UDP und habe eine Sequenz eingebaut. Wenn man diese mit einbaut, ist es im Prinzip wieder so schnell/langsam wie TCP, da der Client jedes Telegram beantworten muss (damit der Server feststellt, dass es angekommen ist) und der Server muss es wiederholen, falls es vom Client nicht quittiert wurde. Und ohne Sequenz kann man UDP vergessen, da Telegramme verloren gehen können oder sich überholen. Fällt dahe raus

[Bernhard Geyer]

Zitat von AJ_Oldendorf:

Genau das habe ich auch schon versucht mit UDP und habe eine Sequenz eingebaut. Wenn man diese mit einbaut, ist es im Prinzip wieder so schnell/langsam wie TCP, da der Client jedes Telegram beantworten muss (damit der Server feststellt, dass es angekommen ist) und der Server muss es wiederholen, falls es vom Client nicht quittiert wurde. Und ohne Sequenz kann man UDP vergessen, da Telegramme verloren gehen können oder sich überholen. Fällt dahe raus

Wenn der Server ein Packet bestätigt haben will bevor er das nächste abschickt bringt UDP nix.
Der Server muss dann mehrere Packete auf die Reihe schicken und wenn ein Packet nach Zeit x nicht bestätigt wird nochmal senden.
Oder auch der Client bestätigt die Packete "im Block", oder....

[mjustin]

Zitat von AJ_Oldendorf:

Server schickt dem Client was, Client kann dem Server antworten. Das ist das Grundprinzip

Das ist ein Protokoll das nicht so ganz zu HTTP (siehe Vorschlag weiter vorher) passt. Der Client muss hier nun warten, bis Daten vom Server kommen, diese verarbeiten, und dann wieder warten. (und eventuell eine Antwort zurücksenden).

Dieses Kommunikationsmuster habe ich mit Indy mal in in einem kleinen Demoprogramm als 'umgekehrte request-response' (Anfrage/Antwort) umgesetzt.

https://mikejustin.wordpress.com/202...ocket-library/, Code ist auf https://github.com/michaelJustin/ind...equestResponse

Die Oberfläche erlaubt wahlweise, dass der Client eine Anfrage an den Server sendet, oder umgekehrt, der Server eine Anfrage an den Client sendet.

Es fehlt zwar etwas Fehlerbehandlung - zum Beispiel Prüfung auf ReadLnTimeout nach Readln - aber es zeigt, dass auch der Server die erste(n) Nachricht(en) senden kann, nachdem die Verbindung hergestellt ist.

Der clientseitige Code läuft in einem Thread und sein Betriebsmodus wird durch ein Flag gesteuert. Entweder wird ein Request gesendet und dann auf die Antwort gewartet, oder auf einen Request gewartet und eine Antwort gesendet.

Delphi-Quellcode:

while not Terminated do
begin
  if Send then
  begin
    // send request to server and receive response
    Send := False;
    Request := 'REQ:' + FClientRequestHolder.Text;
    TCPClient.IOHandler.WriteLn(Request);
    repeat
      Response := TCPClient.IOHandler.ReadLn(IndyTextEncoding_UTF8);
    until Response <> '';
    LogInMainThread(Request, Response);
  end
  else
  begin
    // receive request from server and send response
    Request := TCPClient.IOHandler.ReadLn(IndyTextEncoding_UTF8);
    if StartsStr('REQ:', Request) then
    begin
      Response := 'from client ' + ReverseString(Request);
      TCPClient.IOHandler.WriteLn(Response);
    end;
  end;
end;

An diesem Beispiel fällt die Abwesenheit von CheckForDataOnSource auf. Dieses wird nicht benötigt, da ReadLn solange wartet, bis eine Zeile aus dem Socket gelesen wurde, oder es zu einem Timeout kommt.

[Kas Ob.]

Hi,

@AJ_Oldendorf, there is so much can be written about this, yet don't know where to start, so i will start with what thoughts come to mind (logically ordered or not)
1) You said a lot of data between 20 and 80 packet, ( assuming packet and telegram are the same with in the translation !), see i wrote many servers and they are tested and running in real production, working with more than 400k packet per second saturating almost %50 of the 2.5Gbps connection, yet the CPU never goes above %6, some of traffic is done on MySQL, simple insert and delete but mostly update,
so can TCP solve you need ?, absolutely yes.

2) In older thread you tried to get the MTU and its 1500b effect on the speed, before you go that way, i suggest lets fix you problem by understanding it, which i will try below, but going after low level is white rabbit hole, as yes it is 1500 most the time, yet it will never be like that as this is isolated by the network adapter/driver, and every OS has many option/setting that will affect this behavior, yet it will stay 1500, but you user mode software will handle it differently, i suggest to not care about these deep and low level for now, as they are not your problem, forget about tweaking low level stuff for now, don't waste your time while you problem is in different place.

3) Indy is not slow or slower of any other, all other are exactly like that, the same, all of them will serve you at the same speed, the difference will manifested in aspects you will not need, not in this case/scenario, so no matter what you will use it will serve you well.

4) Once i saw ReadLn and WriteLn, i know for sure this can't perform s***, the server will send line by line and the client will read line by line, this is a huge bottleneck in the code.

5) I see this code

Delphi-Quellcode:

IdTCPClient1.IOHandler.CheckForDataOnSource(10);

if not IdTCPClient1.IOHandler.InputBufferIsEmpty then
begin
  InData := IdTCPClient1.IOHandler.ReadLn(' #~#* ' + EOL, 100, -1, IndyTextEncoding_UTF8);

  if InData <> ''  then
  begin
    //do something with it
  end ;
end ;

and i know for sure this can't be perform (like 4), mixing lines with process in place, you can do this only if you send data very rarely, here you combined most worse approaches in one loop.

What is happening here ? let me give you an example how these act as sticks in wheel:
1) Server send line after line, here Nagle (if enabled) will matter, but in not much as will see below.
2) Client notified to receive
3) Client Read One Single Line, in most and slowest possible way, that handle char by char.
4) Client proceed to process One Single Line.
5) When client extracted one line from the received buffer .. well this part is important, the extraction happened in a buffer in user space owned by you own process because you received it, it could be one line or more than one, it could be one or more MTU splitting many lines, well this fact is not important as the important part is what is happening on the network at this exact moment, when you application issued read line for the first time, read all what it could from the network using API like recv, Indy with ReadLn will only process and grab from the network new recv if there is no new lines in the already received and memory loaded buffers, so in other words and shorter way...
When you are handling line by line the network buffers could be filled from the peer (server here) and this will trigger stop sending ACK, so the server will stop sending lines/buffers, your application handle more and more lines and then request one buffer no matter how much in size, it will read from the network driver/provider..., triggering sending an ACK to server server will send one and wait new ACK, and you client server now locked in very slow recv-process-request, extremely slow.

Suggestions:
1) start with removing WriteLn/ReadLn with something useful and performant, in fact, any other method is faster.
2) Send the data in bulk as much as you can.
3) Read as much as you can on each and every read from the socket, provide a buffer lets say 16kb buffer perform read for 16kb or 64kb, even 8kb will be fast enough as it is default for most applications, the point is when read is needed read what you can and as much as you can, not as much you need.
4) Try ICS may be you will like it, there is an obsession with old and outdated practices like this case with readln/writeln, heck.. i was shocked that TFile is still used by many, it is slow as turtle, use modern practices.
5) I saw another code above like this one by mjustin

Delphi-Quellcode:

while not Terminated do
begin
  if Send then
  begin
    // send request to server and receive response
    Send := False;
    Request := ' REQ: ' + FClientRequestHolder.Text;
    TCPClient.IOHandler.WriteLn(Request);
    repeat
      Response := TCPClient.IOHandler.ReadLn(IndyTextEncoding_UTF8);
    until Response <> '';
    LogInMainThread(Request, Response);
  end
  else
  begin
    // receive request from server and send response
    Request := TCPClient.IOHandler.ReadLn(IndyTextEncoding_UTF8);
    if StartsStr(' REQ: ', Request) then
    begin
      Response := ' from client ' + ReverseString(Request);
      TCPClient.IOHandler.WriteLn(Response);
    end ;
  end ;
end ;

Will comment on that one line "LogInMainThread(Request, Response);" what do you think the network stream behavior will be while the application is synchronizing with main thread, i explained above, it trigger full stop send on server, depleted socket window for this socket and many others, lost the sending momentum that build up with TCP between peers(unlike UDP which start with maximum), this behavior you see when downloading huge files, the first few seconds the speed is low then gradually build up to saturate the allowed bandwidth, as the server start to send more and more without waiting for ACK.

Hope that helps.

[Sinspin]

Nen extra Server aufsetzen ist wie Kanonen und Spatzen. Direkt TCPIP is schon die smarteste Lösung für so kleine Sachen.

Zitat von AJ_Oldendorf:

Aktuell sieht es so aus:

Server:

Delphi-Quellcode:

IdTCPServer.DefaultPort := PipePort;
IdTCPServer.OnConnect := IdTCPServerConnected;
IdTCPServer.OnDisconnect := IdTCPServerDisconnected;
IdTCPServer.OnException := IdTCPServerException;
IdTCPServer.OnExecute := IdTCPServerExecute;
IdTCPServer.Active := True;

<...>

Ich hatte eher gemeint was für Einstellungen für Timeouts, connection handing (keep alive, etc)
Du nimmst die default Einstellungen der Komponente?
Solchen Problemen ist immer schwer beizukommen. Indy Sourcen sind aber mit dabei. Da mal versucht duchzusteppen?

Delphi-Quellcode:

IdTCPClient1.IOHandler.CheckForDataOnSource(10);
<...>
InData := IdTCPClient1.IOHandler.ReadLn('#~#*' + EOL, 100, -1, IndyTextEncoding_UTF8);
<...>

Ich habe jetzt die Quelltexte nicht da um zu prüfen was ReadLn macht, aber eventuell ist die Kombination aus "CheckForDataOnSource" und "ReadLn" das Problem. Was passiert wenn du "CheckForDataOnSource" weglässt?

[AJ_Oldendorf]

Zitat:

Ich hatte eher gemeint was für Einstellungen für Timeouts, connection handing (keep alive, etc)

Ich habe gar keine Timeouts oder keep alive gesetzt.
Die Einstellungen der Komponenten sind im Anhang.

Zitat:

Was passiert wenn du "CheckForDataOnSource" weglässt?

Das könnte ich generell mal beim Client versuchen.

Beim Server wurde es im "IdTCPServerExecute" gebraucht, da sonst die CPU Last auf knapp 6% hoch ging. Der Tipp kam von Jaenicke hier https://www.delphipraxis.net/1546974-post25.html