Hi Jakub, Quick follow-up:
Small change of plan from my last message: instead of validating for DTLS 1.3 first, I used some free time these days to get a working 1.2 draft up. DTLS turned out to be a bit trickier than I'd imagined, but something sensible came out of it, and I'd really value your read on the direction before I invest in 1.3 (which needs OpenSSL 4.1, still unreleased). If you'd rather I sort out 1.3 first as I said, just tell me. I already have something you can build and test (branch below). In the meantime let me walk you through the choices, and whenever you think it's the right moment I'll prepare the draft PR. Approach A single 'dtls://' wrapper (plus 'dtlsv1.2://'), as you suggested, no dedicated class. It lives in a self-contained 'xp_dtls.c': I don't touch 'xp_ssl.c'. I reuse the naming and conventions of 'xp_ssl.c' as much as possible (the 'GET_VER_OPT' macros, the 'sockop_*' handlers, the passphrase callback, the same struct with 'php_netstream_data_t' as the first member), so the file feels familiar to anyone who already knows 'xp_ssl' and the review is quicker. But isolated: everyone's TLS path stays at zero risk and the diff is small and reviewable. Another reason I didn't put it inside 'xp_ssl.c': that one belongs to the TCP context (byte stream), while DTLS lives over UDP (datagrams). It's a different transport context, so a dedicated file is its natural home. Architectural choices In short: - Stream-only, no new PHP functions: just constants, context options and metadata; everything goes through existing functions. - Server: one peer per accepted socket, to avoid 'SO_REUSEPORT' (I'll leave the multi-peer case to the offloading work, as you mentioned). - Floor at DTLS 1.2 (1.0 is deprecated, RFC 8996). I'll add DTLS 1.3 before the PR (I still have to get my hands on it), but I'd rather have your feedback on the 1.2 setup first, so I don't invest in 1.3 on a base you might want different. - Session resumption: I plan to align with the RFC ( https://wiki.php.net/rfc/tls_session_resumption_api) extending it to DTLS. Here too I'll dive in after your first feedback, like for 1.3, so I don't build on it before knowing whether the direction works for you. - 'local_cert'/'local_pk' as PEM file paths, consistent with 'tls://'. The only point worth expanding on is the core change: to make 'enable_crypto' work over a 'udp://' (the way 'ext/openssl' overrides 'tcp://' for TLS) you need the 'STREAM_CRYPTO_METHOD_DTLS_*' constants in 'main/streams/php_stream_transport.h'. They're purely additive (no existing logic touched) and it's the only point outside 'ext/openssl'. I've already implemented it, but I'm not 100% sure it's the right approach: I'd lean toward deferring it and keeping the first round to the 'dtls://' scheme only (zero core), leaving the 'enable_crypto' over 'udp://' layer for later. But if you take a look and it convinces you, all the better to keep it in. The branch is here: https://github.com/GianfriAur/php-src/tree/feature/openssl-dtls-stream (branch 'feature/openssl-dtls-stream'). Where I'd like your input 1. The additive core touch for 'enable_crypto' over 'udp://': I've implemented it but I'm not 100% sure it's fine. I'd lean toward deferring it (first round 'dtls://' scheme only), but if you take a look and it convinces you, all the better to keep it in. What do you think? 2. Does the 1.2 approach look right to you? (I'll add DTLS 1.3 and OpenSSL 4.1 before the PR, I just wanted your OK on the direction before investing in it.) 3. On certs/keys: do I stay on PEM paths like 'tls://', or is it worth going for objects right away? No rush given the summer, and honestly I won't be as lucky with free time myself in the coming days either: I'll take my cue from your feedback before formalizing anything. Thanks again for offering to take a look. Kind regards Gianfrancesco
