TCP garantiert eine zuverlässige, geordnete Datenübertragung. Wenn Pakete verloren gehen, werden sie nachgesendet. Sobald aber die Verbindung unterbrochen ist (z. B. durch Timeout oder Routingproblem), merkt TCP das sofort und beendet die Verbindung.
UDP (QUIC) dagegen ist verbindungslos und tolerant gegenüber Paketverlusten. Die 4D Datenbank (bzw. QUIC als Transport-Layer) versucht, Datenströme trotz Störungen am Laufen zu halten. Das macht das System robuster gegenüber kurzen Netzwerkproblemen, aber es gibt keine hundertprozentige Garantie, dass alle Datenpakete in der richtigen Reihenfolge oder vollständig ankommen.
Wenn bei einer größeren Netzwerkstörung unter UDP
einzelne UDP-Pakete verloren gehen,
oder Pakete verspätet bzw. in falscher Reihenfolge ankommen,
kann der Zustand der Client-Server-Synchronisation inkonsistent werden.
Beispiel:
Der Client fragt Datensatz ID 123 an.
Das Antwortpaket wird teilweise oder verspätet empfangen.
QUIC versucht zu rekonstruieren, aber Teile des Streams sind inkonsistent.
Der Client bekommt Daten, die formal korrekt aussehen (weil sie decodiert werden können), aber nicht mehr zu der erwarteten Anfrage passen.
So kann es zu folgendem Verhalten kommen:
Klick auf Datensatz A → Anzeige eines anderen Datensatzes.
Der Client „glaubt“ also, mit dem Server synchron zu sein, ist es aber nicht mehr.
Antivirus-Software kann in Terminalserver- oder Remote-Desktop-Umgebungen massiv in den Netzwerkverkehr eingreifen, und das betrifft insbesondere UDP/QUIC-Verbindungen..
Viele moderne AV-Produkte (z. B. BitDefender, Kaspersky, ESET, Sophos usw.) enthalten Netzwerkschutzmodule, die:
sämtlichen Netzwerkverkehr abfangen und inspizieren,
ggf. TLS/SSL-Verbindungen aufbrechen und neu verschlüsseln,
Heuristiken oder „Intrusion Detection“ anwenden,
und „anormale“ UDP-Pakete verwerfen, wenn sie nicht ins erwartete Schema passen.
Das geschieht tief im Windows-Netzwerkstack, oft über:
NDIS-Treiber,
LSPs (Layered Service Provider),
oder WFP-Filter (Windows Filtering Platform).
Diese Hooks liegen unterhalb der Anwendungsebene, also auch unterhalb von 4D.
Das bedeutet: 4D merkt nicht, dass Pakete blockiert, verzögert oder verändert wurden.
UDP/QUIC ist zustandslos und zeitkritisch.
Wenn Pakete verspätet, blockiert oder „re-sequenziert“ werden:
stimmt die erwartete Paketfolge nicht mehr,
interne Streams von QUIC brechen asynchron ab,
oder bestimmte Sequenznummern „fehlen“.
Auch dies führt zu dem vorgehen beschriebenen Phänomen, dass die Client App weiter reagiert, aber falsche Datensätze oder unlogische Suchergebnisse liefert.
TCP wäre hier weniger anfällig, weil TCP eine fehlerhafte Übertragung erkennen und beenden würde – UDP/QUIC versucht dagegen, sich „durchzuschummeln“, und 4D arbeitet weiter mit inkonsistenten Daten.
In Terminalserver-Umgebungen laufen:
viele gleichzeitige 4D-Client-Instanzen,
über die gleiche Netzwerkschnittstelle,
oft durch dieselbe AV-Überwachungsschicht.
Das erzeugt:
hohe Latenzen (weil der AV-Treiber jeden Stream prüft),
sporadische Paketverluste oder -blockaden,
und manchmal Memory-Leaks oder Deadlocks in den Filtertreibern.
Gerade bei „Security Suites“, die Netzwerkverkehr in Echtzeit analysieren oder „Schutz vor verdächtigen Verbindungen“ aktivieren, treten diese Phänomene auf.