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