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

[Delphi.Narium]

Zitat:

Gleichzeitiges Web-Browsen führt schneller zum Problem. Wenn ich mir irgendwelche Webseiten anschaue dauert es meist keine halbe Minute bis zum Problem.

Das lässt darauf schließen, dass Du kein (Programmier-/Delphi-/Software-)Problem mit Deiner Client-/Server-Verbindung hast, sondern eher ein allgemeines.

Das Stichwort könnte TcpNumConnections sein. Bitte mal die Suchmaschine Deiner Wahl damit füttern.

Als Ansatz hier mal ein paar Links zu den Suchergebnissen:

Configuring the Windows registry: Specifying TCP/IP settings (Windows Server 2003)
Tipps - TCP/IP - Maximale Anzahl gleichzeitig geöffneter Verbindungen
Fix for Windows 10 exhausted pool of TCPIP ports
TcpNumConnections TCP/IP Limitierung.
Beschleunigung / Einstellungen von TCP/IP Netzwerken

Das "Problem" zieht sich quer durch alle Windowsversionen, beginnend spätestens bei Windows NT.

Schau Dir bitte auch mal die Einstellungen für die MTU (Maximum Transmission Unit) an, sie sollte auf Client und Server gleich sein, damit sie einheitlich große / kleine Pakete verschicken. (Das sind die Datenpakete, in die Deine 128 kb zwecks "Versand über die Netzwerkleitung" aufgeteilt werden.)

Über ein Ping vom Client auf den Server kannst Du das recht einfach herausfinden:

Code:

ping -n 1 -l 2000 -f www.delphipraxis.net

Ping www.delphipraxis.net [138.201.18.17] mit 2000 Bytes Daten:

Paket müsste fragmentiert werden, DF-Flag ist jedoch gesetzt.

Ping-Statistik für 138.201.18.17:
    Pakete: Gesendet = 1, Empfangen = 0, Verloren = 1 (100% Verlust),

Den Wert hinter dem Paramter -l verkleinerst Du, bis die Ausgabe von Ping in etwa so aussieht:

Code:

ping -n 1 -l 1472 -f www.delphipraxis.net

Ping www.delphipraxis.net [138.201.18.17] mit 1472 Bytes Daten:

Antwort von 138.201.18.17: Bytes=1472 Zeit=20ms TTL=55

Ping-Statistik für 138.201.18.17:
    Pakete: Gesendet = 1, Empfangen = 1, Verloren = 0 (0% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 20ms, Maximum = 20ms, Mittelwert = 20ms

Statt www.delphipraxis.net nimmst Du natürlich den Namen oder die IP des Servers.

Prüf' bitte auch, ob bei allen (oder zumindestenst einem Teil) der Clients die Ergebnisse übereinstimmen.

Die MTU kannst Du auch über die Registry "vereinheitlichen": Tipps - TCP/IP - Maximale Paketgrösse (MTU) der Datenübertragung festlegen Sie beträgt die per Ping ermittelte Paketgröße + 20 Byte für den "Verwaltungheader", wäre bei der Kommunikation zwischen meinem Rechner und dem Server der DelphPraxis also mit 1492 Byte anzusetzen.

Deine 128 kb Daten werden, bei einer MTU, wie in diesem Beispiel, auf 128 kb (-> 128 * 1024) / 1472 = 89,043478260869565217391304347826 Pakete, also 90 Pakete aufgeteilt.

Wenn die Größe von 128 kb je Paket nicht zwingend ist, kannst Du sie so anpassen, dass sie immer ein Vielfaches der oben ermittelten Paketgröße (hier also 1472 * x) enthalten. Dadurch wird der "Aufwand" für den Datenaustausch zwischen Client und Server verringert. Aber das fiele dann implementierungstechnisch eher unter "Chromleiste", könnte aber dabei helfen, das Problem zu verkleiner, bestenfalls zu verhindern.

Das Ganze hier muss also jetzt nicht zwingend "die Lösung" des Problems sein, kommt aber eventuell der Quelle des von Dir beobachteten "Phänomens" etwas näher.

[Michael II]

Ich glaube nicht, dass bei deinem geposteten Beispiel MTU oder TcpNumConnections eine Rolle spielen.

Du baust ja eine 1:1 und lokale Verbindung auf => MTU Wert ist so ziemlich egal und die eine tcp Verbindung, welche du aufbaust sprengt - ausser vielleicht bei Uralt Win 3.1 - kaum TcpNumConnections.

Wenn ich dein Programm laufen lasse und die Verbindung aufbaue, anschliessend dein Fenster rumschubsen will, dann reagiert es bereits nach kurzer Zeit nicht mehr wie es sein sollte. (Ruckeln)

Das deutet auf ein Problem mit der Windows Warteschlange hin.

Du knallst mit deinem WM_LOG die Windowswarteschlange zu.
Kommentiere mal in lib_simplelog.info() Zeile
// PostMessage(LogHandle, LogMessage, wParam(Logline), 0); aus.

Wenn ich das bei mir tue, dann reagiert das Fenster wie es sein sollte und ich kann 100'000+ Pakete übertragen, ohne irgendwelche Probleme festzustellen.


Zum Code: Du weisst ja sicher, dass ICS auch SendStr und ReceiveStr/ReceiveStrA kennt. Wahrscheinlich hast du bewusst send(), receive() gewählt.
Du reagierst noch nicht auf mögliche Fehler. Bei einer direkten Verbindung ist in den meisten Fällen wohl "Neuaufbau und weiter..." der beste Weg.
Spannend wird es, wenn dein Netzwerk von vielen Beteiligten aufgespannt wird und Daten über mehrere Wege von A nach B fliessen.

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