Nice! Can you please give a bit more detail about differences between websockets and WebRTC? (unless they are the same, I’m kinda ignorant with networking. I just recall Colyseus framework used ws:// for real-time communications and HTTP for ordered updates.)
2 Likes
The big difference between WebSockets and WebRTC is that
- WebSocket runs on top of TCP
- WebRTC’s DataChannel runs on top of UDP
What this can mean for you multiplayer game, you can watch here.
I just saw that there is one related open issue and one that got closed. Maybe they will add it someday. Maybe I could write to them and help them add it. I have no idea what their plans are 
6 Likes
Good job, I believe it will help me a lot in my mmorpg project, I had doubts about the websocket and you touched on an important point, UDP or TCP, thanks for sharing!
1 Like
This is sick! Never thought that the web will ever support UDP. This is going to fix all those lags we have in those fun little web games. Amazing work!!
2 Likes
Yes, if it (or something similar over quic (HTTP/3)) becomes widely available, I will integrate it and use WebRTC only as a fallback 
2 Likes
Awesome showcase! You should definitely put it up on geckos.io readme, showcasing the difference between UDP and TCP (or between geckos.io and socket.io). Nothing is quite as convincing as a clear visualization
7 Likes
Done 
2 Likes
This is fantastic work!
Out of curiosity, what kinds of conditions would cause significant packet loss?
Living in the Netherlands with Tele2 internet connection… :’)
3 Likes
Very interesting dude! But isn’t WebRTC DataChannel only available between peer to peer?
Bad network, I guess. I’m not really a networking pro and do also not have any statistics about package loss. Would be great to see some per country based statistics.
But package loss is not the only thing geckos.io protects you. It smooths out huge latency spikes.
Below an packetlosstest.com screenshot taken from my phone. Where I live, package loss seams not to be an issue, however some packages arrived with 100ms (or more) delay.
Now, imagine you send every 16ms (60 times per second) a new update to your client and the 100th package has a delay of 100ms. Even though you may already have received packages 101, 102 and 103, if you use TCP, the client will have to wait for package nr. 100 before it can read 101, 102 and so on. If you use geckos.io (UDP) you can instantly read 101, 102 and drop 100 when it arrives.
Hope this helps
2 Likes
Yes, but peer to peer is not necessarily only browser to browser. One node can be a browser and the second node a server.
Oh I see. That’s awesome dude! Such a brilliant idea!
1 Like
Cool, someone had to do it one day. By the way, maybe you will interested to read this topic:
https://news.ycombinator.com/item?id=13266692
1 Like
@yannick great stuff - I bump into your post in my quest for the ultimate html5 multi user server speed.
I have a question how your library is different from this here ?
The PDF:
The talk:
QUIC is not yet supported in any browser. See https://caniuse.com/?search=quic.
WebRTC on the other hand is very well supported (https://caniuse.com/?search=webrtc).
Geckos.io uses Client/Server WebRTC DataChannels. But once quic will be widely available, it will use it and just fallback to WebRTC if needed.
1 Like
so the second scenario with UDP between the server and browser.
Great stuff thanks 
For the future I see that we can play with QUIC/HTTP3 as an experimental feature for now:
firefox > about:config > http3 > network.http.http3.enable > true
chrome > chrome://flags/ > quic > experimental quic protocol > enable
Yes, exactly! Using ICE, DTLS and SCTP. Where geckos.io handles all the difficulties for you.
Yes, you can already test quic, but I personally have not used it so far. Seams to me a bit too early.