These are the docs for 13.3, an old version of SpatialOS. The docs for this version are frozen: we do not correct, update or republish them. 14.5 is the newest →

Transmitting component updates unreliably (“quality of service”)

In order to prevent a worker becoming overloaded, you can choose to transmit some component updates unreliably. This means they may be dropped if the network is congested, giving more bandwidth to messages that can’t be dropped.

You can configure which component updates are transmitted reliably and unreliably in the bridge settings of a worker configuration file.

When will an update be dropped?

A component update will be dropped (not sent to the worker) if the worker is not reading messages from the network quickly enough. This can happen if the worker is overloaded (it has too much work to do and is not able to keep up with processing all the updates it’s receiving) or if the network is overloaded.

What are the negative implications of updates being dropped?

The following implications of updates being dropped should be taken into account when considering unreliable component update delivery:

  1. There is no guarantee that the state of a component will be eventually updated to the last sent component update.
  2. The component may end up in an inconsistent state, rather than simply an out-of-date state. This is because component updates are represented as a set of fields to update on the component, not the new full state of the component. Therefore, dropping a subset of component updates which update independent fields may lead to a component appearing to have two fields set to values that never actually occurred together.

Why would I want to enable this?

If all component updates are transmitted reliably, your clients or managed workers may not be able to keep up with the rate of component updates being sent by SpatialOS. You might see this causing latency to increase in the system, leading to an unplayable game or (in extreme cases) memory leaks on a server which could cause the entire deployment to crash.

Which components should I enable unreliable transmission for?

In light of the above trade-offs, you should consider enabling unreliable transmission for components that are updated frequently, since these updates will be making up a good chunk of the network traffic and losing an update to one of these components should not cause the component to become very stale. You can find out which components are updated most often by looking at the Entities Grafana Dashboard.

Search results

Was this page helpful?

Thanks for letting us know!

Thanks for your feedback

Need more help? Ask on the forums