I’ve hacked together a first shot at a 3.0 redesign of SDL_net.

Nothing is final, so feedback is welcome here (including “this is terrible, don’t do this at all.”)

The general idea:

The pull request with the current state of this:

Feel free to comment here, or the issue link or the PR link, I’ll see them all.


As you know I can’t migrate to SDL3 for other reasons (principally the loss of an OpenGLES 1 backend) but I’m very supportive of this.

I note the comment “Someone asked for built-in encryption, but adding an OpenSSL or whatever dependency is a huge hassle”. I expect that was me!.

It’s precisely because it’s a hassle that having it available in a cross-platform library would be so valuable! Insecure net communication is increasingly uncommon.

The redesigned SDL3_net has been merged!

Brief discussion of the history and motivations are on my Patreon.

This new API is not locked down until we make some sort of official release, so if you play around with it, and hate it, definitely let me know!

The wiki has a pretty good start on documentation. The SDL2_net docs are still available, too.

I totally agree, and building this into the library (and I mean building it, not just slapping OpenSSL into there) is a big, audacious goal of mine, for when I’m not buried under SDL3 work…but this first shot is meant to be a humble improvement over the previous version, which is good enough for now.

1 Like

How about adding TLS support with SDLNet_CreateTLSClient / SDLNet_CreateTLSServer api that will accept a context struct with TLS callbacks (handshake/verify/encrypt/decrypt/etc), where the end user has to implement this themselves using any suitable backend?
I don’t think encryption can be applicable for datagram streams due to the complexity of implementing handshake requiring reliable packets.