@cjohnson I am curious to why QUIC or a protocols like QUIC aren't implemented in the delivery of packets. To optimize network preformance, I would make the suggestion that Quick UDP Internet Connection be adopted in future releases of the game. Unfortunately, the technology is still new to me, but I can say that it is Open Source and would contribute to the network stability of the game. Over the last couple of days I have noticed loss connection issues while attempting to stream. To greatly increase the playability of the game it would be something to look into. I was wondering what The Devs think about it. Are network problems an issue to any of the players? Is glitching through objects because of lag an issue to players? I just started playing this game about 2 weeks ago and I enjoy it, and I want to see this game fully realized in the state that it should be played in, but it will take some work. I am willing to put in my 2 cent where and when I can.asked by Johny_Blackhand

I hadn't heard of QUIC so thank you for bringing it up here as I'm always interested in learning about new (to me) network protocols.

Having quickly read through the IETF draft I don't think QUIC would be suitable for our needs because it is a stream-based protocol and provides full reliable transport of all stream data. When a connection is suffering from high packet loss, reliable stream transport can lead to head-of-line-blocking causing high latency due to the receiver needing to process all packets in the order they were sent, and any lost packets having to be re-sent before the receiver can continue processing the stream. QUIC addresses this by allowing a connection to simultaneously have multiple independent streams. The hope is that packet loss will work out in such a way that head-of-line-blocking will only affect a small number of those streams at any one time, allowing the other streams to continue without additional latency.

We have our own custom transport protocol layered on top of UDP. Like QUIC it provides end-to-end encryption, error detection, and is designed to mitigate various kinds of attacks. Unlike QUIC our protocol is message-based rather than stream-based and supports both fully reliable as well as semi-reliable messages. Semi-reliable means that the receiver will send an acknowledgement (ACK) back to the sender when it receives one of these messages, or a no-acknowledgement (NACK) when it detects a message is missing. This allows the sender to keep track of what the receiver has received. In fact we keep track of this information per entity and per connection. The sender then uses this information to only send incremental delta updates about the current state of game entities. If the sender knows that the receiver hasn't received a previous change then it will re-send that data along with any new changes. In other words, semi-reliable transport allows us to only ever send the latest minimal set of changes to an entity's state. Effectively every entity has its own stream and head-of-line-blocking isn't possible. Now, we do also support fully reliable messages and these can suffer from head-of-line-blocking but these messages are very much the minority and are prioritised above the semi-reliable ones so when a problem does occur it is usually resolved very quickly.

Our protocol has been thoroughly tested and has been shown to be stable, efficient, and have low latency overhead, in even the worst network conditions. Telemetry data backs this up with the vast majority of our clients having very low pings. That said, we're always looking to improve it. All reliable messages are currently treated as a single stream per connection but we are considering ways of breaking this up into multiple independent streams similar to QUIC. Congestion control, flow control, better support for WiFi connections, improved security and compression, and general performance improvements, are all areas we are looking at.

So the other part of your question is about where the current latency and connection issues come from. I'm afraid there isn't a single answer for that. The most common connection issues are the 30000 disconnection pop-up and infinite loading screens. The 30k happens when the client loses connection with the server. Although this can be caused by network issues it most frequently occurs when the server crashes. Infinite loading screens happen when either the client or the server is waiting for some event to happen or some process to complete but it doesn't for some reason. Both happen due to bugs in the code and we prioritize fixing these above all other issues. However since the game is still in development we are always writing new code and unfortunately that means we're always creating new bugs. We take great pains to avoid creating new bugs and finding any that are created as soon as possible but some always slip through the net. Likewise, latency issues can have multiple different causes and some issues that may seem like they would be caused by network latency can actually be caused by other factors such as server frame-rate, backend services issues, streaming delays, or excessive filtering. As with all issues it is important to, 1) report it, 2) be as precise as possible when describing the issue so we can figure out where exactly the problem is.

Sorry for the long-winded reply and thanks for your support. I hope you continue to enjoy the game. And Happy New Year!