Hi Jakub Il giorno sab 27 giu 2026 alle ore 19:09 Jakub Zelenka <[email protected]> ha scritto: > > Hi, > > please don't top post. >
I apologize for top-posting in my previous replies, bad habits. > > I thought about this and one thing to note is that this should be future proof solution that will support DTLS 1.3 which is currently in works and should be part of OpenSSL 4.1. Currently it doesn't look that it will support DTLSv1_listen so I would recommend to study it's implementation to make sure that the design is good for 1.3 as well. See feature/dtls-1.3 and this PR (handling the listen logic) for more details: https://github.com/openssl/openssl/pull/31137 . > Good call. I'll study the feature/dtls-1.3 branch and the listen PR (#31137) before settling on any shape > > Definitely not do both of them together as it would be too much to review and I don't think the low level solution is optimal anyway (see below). > Agreed. With offloading heading this way, a parallel low-level class doesn't earn its keep, let's scope this to the dtls:// stream wrapper first and treat offloading as the follow-up, with the stream as its prerequisite. I'll drop the standalone engine from the proposal. > > We are actually looking to the IO hooks where we plan to add support for IO offloading which would basically need to use custom SSL BIO . It was initially meant for io_uring but if allowed limitation per stream, then it should cover your use without exposing some extra unnecessary class. > Works for me in principle: if the offloading hooks let the application provide the I/O for an individual stream, my case is covered without a separate API. > > I'm not sure it would be overlapping that much. > Fair. And if offloading covers the app-driven case anyway, there's no second surface left for it to overlap with. > > Yeah and that's exactly what will be possible to do with IO offloading without any need for any extra API. > Good, then I'll drop my architecture entirely and go with your approach: a single dtls:// stream wrapper, with the multiplexed case handled later through offloading rather than a separate low-level surface. No second class to maintain or review. > > I'd prefer to start only with stream and then we can discuss the offloading but for that stream implementation is prerequisite. > On process: would you rather I open a formal RFC now, or hold off until I've prototyped the dtls:// wrapper on top of the polling/offloading primitives and we've agreed on the shape? Since the wrapper depends on those landing first, my instinct is to settle the design and get a working prototype before formalising an RFC rather than opening a concept-only one now, but I'll follow whatever sequencing you prefer. And since you maintain ext/openssl and own the stream rework this sits on: if I take on the dtls:// wrapper once the primitives are far enough along, would you be open to steering the design and reviewing the implementation? I'm glad to do the implementation work myself — I'd just want your direction and review so it fits the streams architecture you have in mind. > Kind regards, > > Jakub > > Thanks, Gianfrancesco
