TCP guarantees a reliable, ordered data transmission. If packets are lost, they are resent. However, as soon as the connection is interrupted (e.g. due to timeout or routing problem), TCP immediately detects this and terminates the connection.
UDP (QUIC) on the other hand is connectionless and tolerant of packet loss. The 4D database (or QUIC as a transport layer) tries to keep data streams running despite disruptions. This makes the system more robust against short network problems, but there is no 100% guarantee that all data packets arrive in the correct order or completely.
If, during a major network disruption under UDP
individual UDP packets are lost,
or packets arrive late or in the wrong order,
the state of client-server synchronization can become inconsistent.
Example:
The client requests record ID 123 .
The response packet is received partially or late.
QUIC tries to reconstruct, but parts of the stream are inconsistent.
The client receives data that looks formally correct (because it can be decoded), but no longer matches the expected request.
This can lead to the following behavior:
Click on record A → display of a different record.
The client "believes" it is synchronized with the server, but it is no longer.
Antivirus software can massively interfere with network traffic in terminal server or remote desktop environments and massively interfere with network traffic, and this particularly affects UDP/QUIC connections.
Many modern AV products (e.g. BitDefender, Kaspersky, ESET, Sophos, etc.) include network protection modulesthat:
intercept and inspect all network traffic, intercept and inspect,
possibly break and re-encrypt TLS/SSL connections,,
apply heuristics or "intrusion detection" apply,
and discard "abnormal" UDP packets if they do not fit the expected scheme.
This happens deep in the Windows network stack, often via:
NDIS drivers,
LSPs (Layered Service Provider),
or WFP filters (Windows Filtering Platform).
These hooks are located below the application layer, also below 4D.
This means: 4D does not notice that packets have been blocked, delayed, or altered.
UDP/QUIC is stateless and and time-critical..
If packets are delayed, blocked, or "re-sequenced":
the expected packet sequence is no longer correct,
internal streams of QUIC break asynchronously,
or certain sequence numbers "are missing."
This also leads to the phenomenon described above, where the client app continues to respond but delivers incorrect records or illogical search results.
TCP would be less susceptible here because TCP would detect and terminate a faulty transmission – UDP/QUIC, on the other hand, tries to "sneak through," and 4D continues to work with inconsistent data.
In terminal server environments, the following run:
many simultaneous 4D client instances,
over the same network interface,
often through the same AV monitoring layer.
This causes:
high latencies (because the AV driver checks every stream),
sporadic packet losses or blockages,,
and sometimes memory leaks or deadlocks in the filter drivers.
Especially with "security suites" that analyze network traffic in real time or activate "protection against suspicious connections," these phenomena occur.