schnelle Server Client Verbindung ohne Verluste

[Kas Ob.]

> Please test this code 1:1 and tell me where the problem is with the receive. I've implemented the function in the receive thread exactly as you described. However, the server only calls FParent.LastContext.Connection.IOHandler.WriteDire ct(Data.Data); five times (I know because the client's buffer is full), and the client receives nothing.

Yes this one and i tested 1:1 and well... i have to few lines due to inline varibales !! my IDE doesn't support them and i don't have one super duper likes yours.

The result it is not working, server send the the client still not reading ! as it is not reading at all, and my diagnosis is still standing and right the server send and stop sending when the client is not receiving.

Now, what is the problem ?
The problem is you still missing the use of simple copy and paste, compare your pasted client and see for your self, you missed the critical protection against performing blocking recv on no fully connected socket !

So once you change this line
    if Assigned(FParent) and Assigned(FParent.FParentClient) then // ,
To this line
    if Assigned(FParent) and Assigned(FParent.FParentClient) and FParent.FParentClient.Connected then // ,
It will work like charm !

Performing recv will block forever on non ready socket (also will not receive anything), keep that in mind and you will left with 99 problem to solve.

[Kas Ob.]

Just remembered something ReadLn should be blocking too, didn't check, in theory it should and if it is then the same missing check for connected state is the root failure in your original code, this doesn't mean this demo should not be re-written, but it should be re-written with right threading handling.

[AJ_Oldendorf]

Danke Kas Ob., ich habe die Änderung and FParent.FParentClient.Connected then wirklich übersehen gehabt.
Mit dieser Änderung geht es!
Ich werde jetzt, nachdem die Grundarchitektur funktioniert, dies wieder in mein Hauptprogramm einpflegen (keine Angst, ohne VCL Zugriffe etc ) und prüfen, ob ich damit auch die Probleme mit den Zeitverzögerungen beim Schreibbefehl habe. Das war ja eigentlich der Hauptgrund warum ich dieses Testprojekt zusammengeschustert habe

[Kas Ob.]

Zitat von AJ_Oldendorf:

Danke Kas Ob., ich habe die Änderung and FParent.FParentClient.Connected then wirklich übersehen gehabt.
Mit dieser Änderung geht es!
Ich werde jetzt, nachdem die Grundarchitektur funktioniert, dies wieder in mein Hauptprogramm einpflegen (keine Angst, ohne VCL Zugriffe etc ) und prüfen, ob ich damit auch die Probleme mit den Zeitverzögerungen beim Schreibbefehl habe. Das war ja eigentlich der Hauptgrund warum ich dieses Testprojekt zusammengeschustert habe

Really happy for you, and good luck !

In any case if there is still a delay, then please share to figure out a delay fix.

[AJ_Oldendorf]

Da bin ich mal wieder

Folgendes Phänomen:

Client baut eine Verbindung zum Server auf und der erste Empfang auf Client Seite sieht so aus:

Empfangsbuffer wird im Thread gelesen wie in den Beispielen oben drüber.
Auswertung macht ein separater Thread.
Length Eingangsbuffer am Client -> 226

Byte-Array Inhalt beim Client sieht wie folgt aus:
(0, 143, 0, 158, 0, 99, 0, 102, 0, 102, 0, 0, 0, 1, 0, 1, 0, 21, 0, 138, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0)

158 = 9E (=4te Byte, sagt die Paketlänge welche der Server vor dem Versand beschreibt)
Der Server schickt auch ein Paket mit 158 Länge.
Das nächste Telegram vom Server hat eine Länge von 52 Bytes. (sieht man im Wireshark auch so eintreffen)

Länge wird aber mit 226 übermittelt beim Einlesen im Thread, lauter Nullen nach den eigentlichen 158 Zeichen im Client.

Wireshark zeigt eine Length von 212 vom gesamten Paket an, in den Daten steht allerdings die richtige Anzahl von 158 Bytes. An 4ter Stelle steht die 9E -> 158 Bytes

Das nächste eintreffende Paket vom Server wird mit einer Länge von 106 Bytes im Wireshark angezeigt wobei eigentlich nur 52 Bytes mit Daten belegt sind.

Das zweite Telegramm beginnt auch nicht mit lauter Nullen sondern mit 0090 0034...

Daher meine Frage, was sind das für Nullen am Ende des ersten Paketes?