Hallo zusammen

Was passiert genau wenn beim TServerSocket unter Last ganz oft SendText aufgerufen wird und der "Buffer" sich füllt? Also der zu sendende Text die maximale Grösse von 64k erreicht?
Stimmt diese maximale Grösse überhaupt?

Ich konnte in manchen Fälle feststellen, dass der Client (ReceiveText aufgerufen beim Event ClientSocketRead) dann am Schluss dieser 64k-Nachricht, welche aus mehreren Befehle (String, welches mit Sonderzeichen anfängt und aufhört und immer ca. 100 Zeichen lang ist) besteht, einen abgehakten Befehl erhält und erst mit der folgenden Nachricht (erneut ClientSocketRead) den Rest des Befehlt zu Beginn des String (ReceiveText) erhält.

Wann genau schickt der ServerSocket die NAchricht ab (mit SendText) und kann das sein, dass bei hoher Last (200 Mal SendText pro Sekunde) sich der Client aufhängt??

Das ganze habe ich auf XE5 festgestellt.

Du musst doch grundsätzlich davon ausgehen, das die Nachricht beim Empfänger nur happenweise ankommt. Das ist einfach so. Ergo muss dein Empfänger eine Puffer pflegen, d.h.
1. Hänge die gerade empfangenen Bytes an den Puffer an.
2. Wenn der Puffer nun eine vollständige Nachricht enthält, extrahiere die Nachricht und verarbeite sie.
3. Der Puffer kann nun den Anfang der nächsten Nachricht enthalten, oder auch die komplette nächste Nachricht.

Das liegt halt in der Natur des Protokolls. Für Delphi gibt es mit Indy und Synapse allerdings auch freie Bibliothek, die das Problem durch Verwendung eines Puffers umgehen. Der Clientaufruf blockiert dann zwar solange bis der gesamte gesendete Text empfangen wurde, aber bei Bedarf kann man den Aufruf in einem Thread unterbringen.

Oder man nimmt gleich die ICS von Francois Piette. Die sind Event getrieben und nicht blockierend.

Sherlock

Und auch da musst Du dich ums zusammensammeln selbst kümmern. Und auch bei den Indies musst Du das tun. Sie bieten dir imho nur die Möglichkeit, einen durch CR/LF terminierten String zu schicken und zu empfangen. DAS ist dann blockierend, weil die 'ReadLn' - Methode eben wartet, bis das CR/LF eingetrudelt ist.

Bei anderen Protokollen (Frame, Length encoding. Checksum etc.) muss man alles selbst machen. Die Routine zum Empfangen sieht im Prinzip so aus

markieren

Delphi-Quellcode:

Procedure TMyThing.OnReceive (Sender : TObject; Data: TBuffer; BytesReceived : Integer);
Begin
  myBuffer.Append (Data, BytesReceived);
  While myBuffer.ContainsFullMessage do
    ProcessMessage(myBuffer.ExtractMessage);

End;

Zitat von Dejan Vu:

Bei anderen Protokollen (Frame, Length encoding. Checksum etc.) muss man alles selbst machen. Die Routine zum Empfangen sieht im Prinzip so aus ...

Die Indy TIdIOHandler Klasse für den Socketzugriff bietet ein breites Sortiment an Read/Write Methoden, denen man auch sagen kann wie ein String terminiert, ist oder wie lang ein Stream, der gelesen werden soll. Auch Encodings und Timeouts lassen sich fein steuern. Wenn man den Puffer direkt anspricht, ist man schon viel zu low level. Daher ist Indy nach etwas Einarbeitung auch geeignet, komplexere Protokolle schnell abzubilden.

Oh, das wusste ich nicht. Ich hatte das immer selbst gebaut.