Thin wrapper over SDL3_net's NET_DatagramSocket. More...

#include "PacketHeader.hpp"
#include <SDL3/SDL_stdinc.h>
#include <SDL3_net/SDL_net.h>
#include <cstdint>
#include <vector>

Include dependency graph for UdpEndpoint.hpp:

This graph shows which files directly or indirectly include this file:

Go to the source code of this file.

Classes
struct	net::UdpEndpointAddr
	A UDP datagram address (server's view of a remote peer). More...
struct	net::UdpReceivedMessage
	One framed UDP message ready to dispatch to upper layers. More...
class	net::UdpEndpoint
	Wraps a NET_DatagramSocket with header-prefixed I/O. More...

Namespaces
namespace	net

Detailed Description

Thin wrapper over SDL3_net's NET_DatagramSocket.

Phase 3d-1 introduces this as the foundation for the UDP transport. It owns one UDP socket (server-bound or client-bound), provides header-prefixed send/receive of payloads, and tracks connection IDs for the server-side address ↔ client mapping.

Why not just use NET_SendDatagram / NET_ReceiveDatagram directly? Because every datagram needs the 16-byte PacketHeader prepended (with magic/version/connectionId/sequence/channel) and validated on receive. UdpEndpoint does that automatically so callers work with payloads, not raw datagrams.

Threading: the SDL_net docs state datagram sockets are safe to call from one thread at a time. The Server's existing network thread is the natural owner; the game thread enqueues sends and pops received messages via stateMutex_-protected paths in Server.cpp.

Connection IDs: established over the existing TCP path during notifyPlayerClientId. The TCP handshake hands the client a 32-bit random connectionId and the client stamps every UDP datagram with it. The server demuxes incoming UDP by connectionId → ClientId. This skips the full 4-step UDP handshake from the original plan; works because TCP is already establishing the connection. The full handshake is a Phase 3d-future enhancement (NAT traversal, no-TCP support).

Classes

Namespaces

Detailed Description