#NetCode - Custom Transport Pipelines

1 messages · Page 1 of 1 (latest)

true girder
#

Have you considered sending additional streams over the NetCode transport? As far as I can tell the Transport package itself supports it and it could be useful for sending additional data outside of networked ghosts / RPCs. (Voice being a good example.)

#

(At the moment, I think you can create custom pipelines by overriding driver creation - but NetCode handles all packets from all pipelines, so you can't send anything custom without it trying to read it.)

sleek geyser
#

We have not considered user defined packets so far since we have not really had any specific use-cases for it. In the case of voice we are recommending using a separate server for it rather than sending it through the game server - both to keep the server load down and to make sure voice still works when transitioning from a lobby to gameplay or loading new levels. In that case you need a separate connection for it anyway. If you have a good use-case for running voice chat on the game server we would be interested in hearing more about that.

true girder
#

We do have another use-case which is our inventory system. We want to have a reliable ordered stream of 'patches' which we use for synchronisation. The use-case is a little different from ghosts because we can do precise diffs and the data changes infrequently. We initially tried using RPCs but found that sending & receiving them with precise ordering was a little thorny. (Particularly if you use RPCs as components, the ordering appears to be entirely undefined.) We can't batch them into RPCs as they seem to have a relatively low maximum size.

barren mantle
#

To further Ricky's point: so far, sending precise inventory diffs over our own pipeline using custom packets has worked really well for us. Unfortunately we've now hit up against a limit where the underlying transport library seems to have no concept of queuing/quality-of-service in order to handle infrequent bursts of traffic. We're effectively having to create our own packet fragmentation & queuing logic 😦

wild elbow
#

Dumb question: is a tcp connection not an option? Or just having the client make periodic http requests?

true girder
#

We can, and it's one of the workarounds we considered, but a single-transport solution would be better as you can manage QoS among the streams (the TCP-suitable data is much lower priority in our case, for example). Also, managing multiple connections for a single 'logical' connection can wind up being a bit complex.

sleek geyser
#

Thank you for the use-cases. It would be good if RPCs can be improved so they can handle those cases, including QoS and bursts of data. I'll add those to the list of things to consider when we look at improving RPCs at some point in the future. It will unfortunately not be in 1.0 though. Ghosts generally deal well with static data, especially with the static optimization, what was the main issue with using ghosts for it? Was it bandwidth / CPU or did you need it to be sent also when not in game?

true girder
#

(Ideally we'd support some level of out-of-order processing at some point, but it's important that we don't show invalid states in-between.)

true girder
#

Just to give a bit of background - our inventory is currently a managed OO data-structure.

We initially had a go with ghosts, where we had an entity per inventory item. This was a while ago and we experienced a few issues:

  • It was hard to prevent ECS from adding transforms to our items (again, this was a while ago, I suspect we could avoid this now)
  • And following on, it was hard to stop NetCode from wanting to serialise the transform
  • It was hard to keep an index up to date: specifically we need to know frequently what the type of an item is (a scriptable object), and what its children are and parent is. We managed to implement this with a series of maps in a system, but it was only up to date at one point in the frame
  • We need to be able to traverse items to build our UGUI UI
  • Because of the UGUI UI, we wanted more granular change detection
  • We were seeing temporary illegal states due to ghost update ordering (part of this came from the fact that our inventory manipulation didn't necessarily line up amazingly as a pipeline, and we didn't want to repeat any systems)

It didn't seem an amazing fit with ECS in the end.

We tried RPCs and had similar issues with ordering. I think we blew a limit when we tried to add all of our queued updates to a single RPC and when we made several, they appeared out of order.