UDP support

[namel]

This is a feature request.

Request to add support for UDP - which is a faster networking mechanism than the current TCP, and would probably be built on top of WebRTC.

[therealmikz]

This might be helpful: https://github.com/KordonBleu/enslavism

[namel]

interesting... does it have performance benchmarks, showing an advantage over socket.io ?

[therealmikz]

No idea, couldn't get it to run yet (I'm doing research for a project that I plan to start in 2-3 months). There's the issue I've created: https://github.com/KordonBleu/enslavism/issues/3 I hope you'll be more lucky than me :)

To elaborate a little more, I plan to create a multiplayer browser game with shared physics, I plan to implement it based on this article series: https://web.archive.org/web/20181108013418/https://gafferongames.com/categories/networked-physics/ (unfortunately the live version of this website is temporarily unavailable). Author suggests that using TCP for this kind of game is a bad idea, so I'm looking for a way to implement it using WebRTC.

[namel]

sounds promising. one clarification is needed though: enslavism may be addressing the peer-to-peer requirement, rather than the UDP requirement. The first requirement is for games with trusted clients only.

[therealmikz]

If I understand it correctly, it allows to provide multiple servers (slaves) with one supervisor (master) and all slaves are communicating with clients by WebRTC. I couldn't test it, so I might be wrong, but I believe that was the statement in the blog post describing this library (linked in readme).

[blockspacer]

This might be helpful: https://github.com/blockspacer/webrtc-datachannels

[smokku]

UDP is not inherently faster by itself. The reason it is better for real time multiplayer is that in case of network congestion, TCP is actively re-transmitting packets, the client is not interested anymore - it would rather process newer updates. But this requires changing the server-client synchronization method. Server cannot anymore just fire'n'forget update packets. It needs to actively track last ACKed state by client and send full deltas between ACK and NOW with each client update. (Until client ACKs new state.)

Just saying that simply replacing TCP/WebSocket by UDP will not help by itself.

[namel]

I'm not sure if I agree with the first statement - I think UDP is faster by itself, because it does much less work than TCP needs to do.

But the second statement is correct: switching to UDP will require some changes to the server logic, because some of the server events are critical (for example, the death of one player, the creation of another) and those events need to be confirmed, or at least the probability of loss reduced.

[bhgsbatista]

Does this help? https://github.com/Efoi/WebRTC-Server-Client-Datachannel

I'm interested in this technology, also in helping out the colyseus guys add an option to use UDP.

A properly configured server will support both reliable and unreliable UDP messages, allowing frameworks / games to decide what is reliably needed and what can be unreliable.

[dillydadally]

Here's another great project to reference when adding UDP support: https://github.com/geckosio/geckos.io#readme

This web article also has some details and shows the performance gains that can come from UDP in multiple tests: http://blog.brkho.com/2017/03/15/dive-into-client-server-web-games-webrtc/

As a side note, I'm considering utilizing Lance with the hope that it will one day have this specific feature and I can just plug it in later. Is Lance still actively being developed and is this feature looking pretty definite?

[neeh]

I agree with @smokku, TCP is not "slower" than UDP, the cost of the "checks" performed by TCP is insignificant compared to the massive latency spikes that are caused by packets waiting for another packet to be re-transmitted so that ordering is preserved. And some of those "checks" have to be manually implemented on top of UDP anyway, which might make it even "slower" in itself, but at least packets arrive as soon as possible, unordered.

There is this excellent talk from Glenn Fiedler about networking where he explains this with an example. The performance of TCP with 2% packet loss is awful. And it's really frustrating when you think that the next packets are probably here, waiting for the lost ones.

With regards to WebRTC, I've heard lots of bad thing about networking a client-server game using WebRTC, the things I usually read :

1. WebRTC is hugely complex (it includes a big pile of protocols)
2. WebRTC was made with streaming/P2P architecture in mind, not client-server
3. WebRTC does not use UDP but SCTP over DTLS (we cannot use UDP directly in the browser for security reasons)
4. WebRTC does not guarantee an unreliable connection

This comes from both Glenn Fiedler on this article on his website gafferongames.com and the creator of Agar.io, after trying to upgrade his C++ WebSocket server to WebRTC multiple times, and several other devs who tried to make the move from WebSocket to WebRTC (check this).

In his article, Glenn Fiedler lists the requirements for the ideal protocol that us, web game developers need, and provides an implementation : netcode.io, which seems promising. At the moment it's only available in Chrome and Firefox with this extension. But I guess providing a WebSocket server + an optional upgrade to netcode.io could be a viable model until things move. I'm planning to experiment it on my game.

[blockspacer]

@namel it is possible to create an RTCPeerConnection and use it to create a data channel that transmits via unordered, unreliable SCTP. Also DTLS can be disabled. See http://blog.brkho.com/2017/03/15/dive-into-client-server-web-games-webrtc/

Also you can find a lot of projects that can help to build and use webrtc, here is my draft for webrtc builds in Dockerfile with conanfile for easier usage https://github.com/blockspacer/conan-webrtc

[namel]

Thanks for the tips. I think we're looking for something like this: https://developer.chrome.com/apps/sockets_udp to be available on all browsers.

[meisterpeeps]

I’m currently working on a game that uses geckos.io. I came here with hopes that I could use lance to do client side prediction with my game. Currently I’ve tested it with around 10 clients and I don’t observe any significant lag. My testing is extremely rudimentary. I could possibly get away without even using client side prediction because the jitter is hardly noticeable but I wanted to see if I could reduce it even more and I don’t know how much it can currently scale. I’m using phaser as the game engine and matter as the physics engine. If anyone has any experience connecting phaser/matter, geckos io, and lance id appreciate any tips/guidance. My hope is that I could support around 50 clients in a single arena/map, although not necessarily all on the screen at once. And if anyone wants to try out my game as it is and get a feel for the performance let me know. It’s a top down space shooter inspired by Subspace Continuum.

[assofohdz]

It’s a top down space shooter inspired by Subspace Continuum.

This I have got to see ! Are you already on the Subspace Discord's ?

[yandeu]

I’m currently working on a game that uses geckos.io. I came here with hopes that I could use lance to do client side prediction with my game.

Hi @meisterpeeps, geckos.io now has a packages called Snapshot Interpolation which supports client side prediction.