IdTCPServer/IdTCPClient: Performance und Latenzen verbessern, UseNagle deaktivieren?

[romber]

Hallo!

Ich habe einen Server, der die Messdaten mehrerer Sensoren an die Clients weiterleitet. Die Kommunikation erfolgt mittels IdTCPServer/IdTCPClient. Aktuell sendet der Server die Daten in größeren Paketen mit Abständen von 0,5-3 Sekunden, so dass ich mir bis jetzt keinen Kopf über die eventuellen durch die TCP-Protokoll verursachten Verzögerungen machen musste. Nun sollen demnächst die ältere Sensoren durch neue ersetzt werden mit neuen Steuerungs-APIs. Die neuen Sensoren werden bis zu 300 mal pro Sekunde kleinere Datenpakete bereitstellen, die dann in real-time an die Clients verschickt werden sollen.

Nun stelle ich mir die Frage, ob TCP-Protokoll in diesem Fall das richtige für diese Aufgabe ist oder ich am besten auf UDP umsteigen soll. Das letztere würde ich gerne vermeiden, angesichts der bakannten Nachteile, die UDP-Protokoll mit sich bringt. Daher habe ich einige Fragen an die Experten in diesem Forum:

- Gibt es irgenwelche bestimmte Maßnahmen oder Techniken, um allgemeine Performance und Latenzen bei der Übertragung der kleinen und mittleren Datenpakete mittels TCP zu verbessern (vielleicht speziell für Indy TCP Client/Server)?

- Würde die Deaktivierung des Nagle-Algorythmus spürbare Verbesserungen mit sich bringen?

- Soll ich für mein Vorhaben am Besten doch auf UDP umsteigen?

Für ganz viele Antworten und Vorschläge bedanke ich mich im Voraus

P.S. Wenn ich Nagle deaktiviere, reicht es wenn ich dies serverseitig mache (z.B. in OnConnect) oder muss ich UseNagle := false auch noch clientseitig setzen?

[BUG]

Zitat von romber:

P.S. Wenn ich Nagle deaktiviere, reicht es wenn ich dies serverseitig mache (z.B. in OnConnect) oder muss ich UseNagle := false auch noch clientseitig setzen?

Es muss auf jeder Senderichtung auf der entsprechenden Seite einzeln gesetzt werden. Den Artikel fand ich ganz interessant zu dem Thema.
Nagle zu deaktivieren kann sich recht deutlich auf die Latenz auswirken.

Abgesehen von 300 Messungen pro Sekunde: wie viele Sensoren hast du so?
Außerdem wäre es für die UDP-Frage ganz interessant, welche Anforderungen du außer einer niedrigen Latenz sonst noch hast. Musst du jedes Messergebnis bekommen?

Im Allgemeinen würde ich versuchen, mit TCP so lange auszukommen, wie es ohne größere Verrenkungen geht.

[romber]

Vielen Dank für die schnelle Reaktion und den Artikel!

Zitat von BUG:

Abgesehen von 300 Messungen pro Sekunde: wie viele Sensoren hast du so?
Außerdem wäre es für die UDP-Frage ganz interessant, welche Anforderungen du außer einer niedrigen Latenz sonst noch hast. Musst du jedes Messergebnis bekommen?

Es sind insgesamt 4 Sensoren, davon 3 sind permanent aktiv, der 4. nur wenn sich bestimmte Muster aus den Daten der anderen drei erkennbar machen.
UDP kommt für mich infrage, weil tatsächlich nicht jedes Ergebnis wichtig ist. Die Reheinfolge ist aber sehr wichtig, im Fall UDP werde ich die Pakete sortieren müssen. Deswegen würde ich UDP gerne vermeiden.

Viele meinen, durch Deaktivierung von Nagle kommt man latenzmässig schon auf die UDP-Niveau. Ist das so?

[Memnarch]

Zitat von romber:

Viele meinen, durch Deaktivierung von Nagle kommt man latenzmässig schon auf die UDP-Niveau. Ist das so?

Ich würde mal behaupten man kommt näher ran, aber nie ganz. TCP hat halt einen leicht höheren Traffic(Größerer Header, je nach Paketgröße wirkt sich das anders aus), sowie das hin und hersenden von ACK-Paketen. Aber es könnte sicherlich von Vorteil sein, dass ganze einfach auszuprobieren. Du kannst ja letztenendes selber messen ob es für dich reicht.

Oder du könntest nen Hybrid ansatz wählen(Ich weiß ja nicht wie du deine Daten verarbeiten musst bzw visualisieren musst). Damit meine ich, du setzt die Echtzeitdaten per UDP ab und jede(oder jede zweite)Sekunde ein TCP paket. Aber das ist abhängig davon, was du mit den Daten machst. Das hab ich bisher nicht gelesen

[Union]

Hast Du das schon mal simuliert bzw. gemessen? Ich bin der Meinung, dass Du bei den geringen Datenmengen und -Strömen gar keine Pobleme haben wirst. Ich hatte mit einem Kollegen einmal eine Fernbedienung ähnlich RDP programmiert. Die übertrug Bildschirm-Diffs, Mausposition, Tatstaturbetätigungen usw. und das sogar noch über TCP und die Daten in verschlüsselten http und über VPN.

[TiGü]

Könntest du die Daten auch sammeln und mit Zeitstempel den Clients senden?
Also anstatt bspw. 300 mal pro Sekunde ein Messwert, lieber drei mal in der Sekunde ein Paket mit 100 Messwerten.
Da würde auch das Verhältnis zwischen Header und Nutzdaten günstiger ausfallen.

[romber]

Zitat von Memnarch:

...Oder du könntest nen Hybrid ansatz wählen(Ich weiß ja nicht wie du deine Daten verarbeiten musst bzw visualisieren musst). Damit meine ich, du setzt die Echtzeitdaten per UDP ab und jede(oder jede zweite)Sekunde ein TCP paket. Aber das ist abhängig davon, was du mit den Daten machst. Das hab ich bisher nicht gelesen

Zitat von TiGü:

Könntest du die Daten auch sammeln und mit Zeitstempel den Clients senden?
Also anstatt bspw. 300 mal pro Sekunde ein Messwert, lieber drei mal in der Sekunde ein Paket mit 100 Messwerten.
Da würde auch das Verhältnis zwischen Header und Nutzdaten günstiger ausfallen.

Die Datenpekete werden nach Sensoren-Zugehörigkeit sortiert und an die Verarbeitungsroutinen weitergegeben. Ein Teil der Daten wird visualisiert, wenn bestimmte Messdatenmuster erkennbar werden. Die Anforderungen an die Client-Software sind dermassen gestiegen, dass über 95% der Daten Echtzeitdaten sind bzw. sein müssen. Deswegen werden auch neue Sensoren eingesetzt.

Zitat von Union:

Hast Du das schon mal simuliert bzw. gemessen? Ich bin der Meinung, dass Du bei den geringen Datenmengen und -Strömen gar keine Pobleme haben wirst. Ich hatte mit einem Kollegen einmal eine Fernbedienung ähnlich RDP programmiert. Die übertrug Bildschirm-Diffs, Mausposition, Tatstaturbetätigungen usw. und das sogar noch über TCP und die Daten in verschlüsselten http und über VPN.

Ich denke auch, dass es keine Probleme geben wird. Ich muss das ganze aber auf jeden Fall umfassend simulieren und messen, mit und ohne Nagle, und auch mit UDP.
Gibt es außer Nagle noch was, was die Performance und Latenzen noch weiter verbessern könnte?