How geckos.io use WEBRTC? Is there anything you do with P2P?

[obbaeiei]

Hi there.

According to my understanding. Geckos.io is not a peer-to-peer model. Which geckos.io application will act as a signaling server for auth clients and then only connect to clients via UDP (skip NAT by ICE server)

So, my question is about geckos. Is there anything you do with P2P?

Thank you.

#213

[ClosetGeek-Git]

I'm new to Geckos as well, however I believe I can answer your questions.

First, WebRTC allows for connections to go in any direction and this is done by using signalling to transmit SDP and ice candidates between two clients to facilitate a connection within the WebRTC stack. This mainly takes place when initializing the peer connection, and then datachannels and media tracks are then initialized within that connection context. each of these connections happen within a peerconnection, and a single peerconnection can facilitate thousands of datachannel objects within it. This allows one node to act as a server, and to multiplex each datachannel within a peerconnection in a way that facilitates both a typical client-server relationship such as request-reply patterns as well as server push and relaying/broadcast between connected peers such as with an SFU.

A while ago people started experimenting with what was generically called WebUDP ( such as here https://github.com/seemk/WebUDP) which typically used trimmed down in house WebRTC datachannel implementations. It's not overly hard to imperilment DTLS, and when exact UDP behavior is acceptable, ie non-reliable non-ordered packets, SCTP is fairly simple as well. These implementations would use shell SDP/ICE/STUN and no TURN, again limiting complexity and staying in line with UDP behavior.

This is not how Geckos works. Geckos is based on libdatachannel which provides full ICE, STUN, and TURN, as well as full SCTP. Full SCTP means that it can still have reliable, ordered UDP with flow control, and full TRUN means that it can still use TCP when needed.

Full ICE/STUN/TRUN allows geckos to correctly handle NAT, including bypassing NAT when needed via TCP over TURN.

As far as true peer to peer goes, a user can use Websocket to signal between clients such as "typical" WebRTC. Once the connection is made between each other these connection wont depend on geckos any longer, although with each peer also maintaining a datachannel with geckos each client can still rely on geckos for mediation or any other role that may require something more centralized and out of the each peer's control and therefor more secure and potentially authoritative. Also, if each client has already connected to geckos, the geckos datachannel can act as a signalling layer as well.