Breakout session on Networking in games

This breakout session was part of the Workshop on Web games. Minutes taken by Seth Hampson.



Kris: Limits on WebSocket are painful.

Peter: What things?

Kris: Reliability & packet ordering. Big delay then a big batch comes in and it’s hard to time sync it. Currently use a timestamp and estimate what every client’s time is. Is this being prototyped?

Peter: No, best we can do is when data arrived. We don’t solve clock synchronization.

Kris: I haven’t used WebRTC data channel

Peter: Hope is over time as support for QUIC becomes more widespread and we build the client/server version of the API it will be easy to deploy a server that speaks to the browser QUIC API.

Kris: What’s held us back with WebRTC data channel is cross platform support. I know there were problems with iOS.

Dom: Can you use…?

Peter: You’re limited on the data protocol you’re using. That’s good to know about client library support being important across platforms.

Dom: Curious about fallback for using the WebTransport.

Victor: I have a plan for simulating QUIC over WebSockets. This API is fully compatible, and in some cases you might want to use WebSocket because UDP is blocked by firewalls.

Bernard: Problem is that SCTP transport can’t be polyfilled because you can’t solve the backpressure problem.

Peter: You’d have to do what the plan is for WebSockets with your own framing down below.

Dom: Reason I”m asking is because you have a catch 22 where you need both client and server deployment. So having this fallback allows deploying the client API with server support.

Peter: One way is to make a polyfill fallback for WebSocket in JS. If you want to change it to use the WebTransport API it would help for the actual API implementing the fallback. This way your code is capable of taking advantage of unreliability even if the API isn’t implementing this.

Victor: The fallback currently isn’t public and there’s two ways to fallback and this is being discussed (TBD).

Edgar: My use case is I want to understand if this can be used for VR streaming. We need a certain level of believability from the consumers and this is where we start looking at streaming. This is similar to Stadia and I’d like to get inputs from you if this is something we should start toying with. For discoverability the web can be the best platform for us. We are focused more on content than development. We probably wouldn’t do a custom solution for our use case, we are looking to reuse what other people use. We are early adopters of tools but not core technologies. We have a 2nd use case of virtual experience in VR where we need to synchronize different pieces. We’re having trouble with downloads, performance in the canvas and also synchronizing videos.

Peter: I don’t know how suitable this is for VR.

Bernard: In the retail context people are more tolerant with delay.

Victor: What type of delay are we talking about?


Peter: For inputs you need unreliable & you have two options. WebTransport or WebRTC data channel. The WebTransport will eventually be easier to deploy. For synchronizing I’m not sure of the solution.

Bernard: Basic issue is you need metadata with the video itself. You could do this with QUIC by just adding this additional metadata.

Peter: With WebCodecs you’re the one choosing your synchronization. If you want to synchronize multiple things you could do that.

Edgar: So I have access to these multiple pieces and can just control this myself?

Peter: Yes.

Bernard: This is a very common VR/AR use case so it should get solved.

Peter: Also for the low latency streaming this is very common.
*Worth noting a benefit of WebCodecs is synchronizing multiple things*

Edgar: When we have product customization which can expose things like the cut of the fabric we don’t want people to easily download these things. Could this help with asset obfuscation?

Peter: Not clear. If you were pushing them down in a custom way this might be more difficult than otherwise.

Victor: Usual Web obfuscation model. Ultimately the browser gets hit.

Bernard: If the issue is protecting the video itself not the asset then you could do some content protection (encryption). Depends on how assets at getting stolen.

Edgar: Downloading 3d models, and also doing dynamic things like how we render patterns. Font files are also proprietary and don’t want to make this easily accessible.

Peter: Any talk P2P interest?


Ted: Web fonts do have some licensing and protection built into the browser.

Edgar: We’re doing our own custom font handling.

Peter: What about voice during games?

Kris: We would absolutely be interested in this.

Peter: Voice & video?

Kris: Just voice with a group. Possibly using a server due to amount 30-50 people.

Edgar: Toying with the idea with locally two people seeing each other.

Peter: Position data is a lot like audio data where you want it very low latency. WebRTC problem is audio/video & data is in two separate worlds including different congestion control contexts and speaking different protocols. We’re addressing this by using QUIC to send all 3.

Bernard: Natively this is solved by shoving everything in the RTP stream.

Bernard: We’ve had a question about a stream with partial reliability. Would anybody be interested in this?

Kris: What we care more about is just unreliability with datagrams. Our messages are lightweight so in our use case unreliable messages aren’t as important.

Kris: Anything specific about faster asset streaming?

Peter: I mentioned HTTP/3 over QUIC by itself would make things much faster. There isn’t really any good server push API in the web. WebSockets works but then it has other performance issues. One of the versions of the WebTransport is built on top of HTTP/3Transport. Connection you already have to your server on HTTP.

Victor: Since this is multi streamed you can have your WebTransport API on top of this. Also worth pointing out that you don’t have to pay any setup cost.

Bernard: Question - What are thoughts on prioritization between streams/datagrams/etc.? Is this important to you?

Edgar: I could see using this to prioritize transmission of different data in VR.

Steve: But if you added audio to your game it would change this.

Bernard: + pulling assets.

Dom: Is this there right now?

Peter: Not yet

Victor: Priorities are a difficult problem. You have to find a way to express them declaratively and there are a lot of strong opinions on how this should be done. This was debated for HTTP/3 and had issues.

Steve: This comes up in WebRTC where you have multiple streams and you at least want to get your low quality streams.

Peter: We would likely create something that prioritizes across streams & datagrams.

Dom: What about pluggable congestion control?

Peter: There’s a discussion on github about this right now. There’s alternatives that can be used for different use cases - BBR, GCC, etc. One solution is you choose which congestion control you want. Another solution is browser has some top threshold you can’t exceed, but you can do your own congestion control, for example, keeping your congestion control low. This gives the application the ability to run your own congestion control but you can never fully trust the application to do this, so there’s still a top cap. This is advanced but some people are interested in having a tight control over media upload. For client/server this is only for client side sending (server can do what it wants). The reason we can do this is because the algorithm is running in user space.

Kris: More information on rollout of QUIC?

Victor: QUIC library is almost read. November 2019 is current goal but expectation is more towards 2020 for a Chrome origin trial on the client/server WebTransport API.

Seth: P2P (RTCQuicTransport) Chrome origin trial out now until the end of July (until version 76).