Stabile TCP-Verbindung mit ICS, ich kriegs nicht hin...

[idontknow]

Vielen Dank für die weiteren Ideen.

Ich habe mittlerweile einen Workaround gefunden, es lag daran, daß ich vom VCL-Thread aus über den ClientSocket gesendet habe, der ja dem TClientThread gehört.

Ich habe jetzt von TSslWSocket eine neue Klasse abgeleitet, mit der Möglichkeit, sich aus dem ThreadContext des ClientThreads "zurückrufen" zu lassen.

In dem Callback kann dann sauber gesendet werden. Damit habe ich jetzt keine Probleme mehr.

Ich habe die Lösung in der englischsprachigen DP gepostet, siehe https://en.delphipraxis.net/topic/32...wsocketserver/

@Michael II: Das Weglassen das Loggings sorgt nur dafür, daß das Problem nicht so häufig auftritt, aber nach einigen zehn/hundertausend Paketen tauchte es bei mir auf...
Ich verwende Send/Receive, weil ich eigentlich ein binäres Protokoll verwenden will, keine Strings.
Fehlerbehandlung ist in dem Testprogramm noch kein bisschen drin... Ich wollte ja, das es crasht, wenn es Probleme gibt.

@Delphi.Narium: Vielen Dank für deine ausführlichen Ideen. Im Testprogramm lese ich einfach nur die Bytes, zähle sie und schmeiße sie weg, in der richtigen Anwendung schreibe ich die gelesenen Bytes in einen Ringpuffer, die MTU ist somit egal. Das Protokoll ist so aufgebaut, das erst ein paar "Magic Bytes" kommen, dann die Nutzdatenlänge (Int64, 8 Bytes hintereinander weg) und dann die eigentlichen Daten. Der Ringpuffer hat eine Statemachine, die sich entweder im Zustand WarteAufMagic, WarteAufDataLen oder WarteAufNutzdaten befindet. Das geht schön schnell...

[Michael II]

Zitat von idontknow:

Vielen Dank für die weiteren Ideen.

Ich verwende Send/Receive, weil ich eigentlich ein binäres Protokoll verwenden will, keine Strings.

... die MTU ist somit egal.

OK super, hat's geklappt.

Wenn du binäre Daten senden willst, dann teste doch mit #0#1#2#3....#255 und nicht mit ABC...Z .

Ich sehe (wie Angus) keinen Gewinn durch die Verwendung von Threads [aber wir sehen ja auch nur einen Test und nicht das fertige Produkt]. Hast du mal gemessen, wie der Datendurchsatz mit deinem Threads Konstrukt und wie er ohne ist?

MTU ist zwar für dein Beispiel mit grossen Paketen egal. Wenn du aber auch sehr kleine Datenpakete (<MTU Wert) immer sofort senden musst/willst (zum Beispiel bei einem Spiel oder Börsensoftware), dann lohnt sich ein Blick auf ComponentOptions -> wsoTcpNoDelay. Aber das weisst du ja sicher bereits .

[Delphi.Narium]

Programmintern mag die MTU egal sein.

Sie ist für die Kommunikation der Rechner untereinander (auf Netzwerk- / Protokollebene) von Bedeutung. Und wenn die Kommunikation dort nicht sauber läuft, kannst Du in Deinem Programm Workarounds machen, soviel Du willst. Solange der Netzverkehr nicht sauber und stabil läuft, erreichst Du allenfalls eine Verschiebung / Verzögerung / Verlagerung des Problems.