Re: [RFC idea] DTLS support in ext/openssl (Openssl\Dtls)
| From: | Gianfrancesco Aurecchia | Date: | Sun, 05 Jul 2026 09:44:13 +0000 |
| Subject: | Re: [RFC idea] DTLS support in ext/openssl (Openssl\Dtls) | ||
| References: | 1 2 3 4 5 6 7 8 9 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-131775@lists.php.net to get a copy of this message | ||
Hi Jakub
Il giorno ven 3 lug 2026 alle ore 23:43 Jakub Zelenka <bukka@php.net> ha
scritto:
>
> So the reason why I mentioned to check DTLS 1.3 is because DTLSv1_listen
> is not currently supported there so it would be probably better to go
> through SSL_accept (with SSL_OP_COOKIE_EXCHANGE)). So the same should be
> used for DTLS 1.2 if possible.
>
Good point, you're right. I'll remove DTLSv1_listen and switch the server
to SSL_accept with SSL_OP_COOKIE_EXCHANGE, so the same accept path works
for DTLS 1.2 now and 1.3 later.
>
> I can see the reasoning for separating but there seems to be lots of
> duplications so it might be good to have some xp_common.c with some shared
> helpers and restructure it a bit. But this can be probably added later.
> Makes sense to start with this and then we can see what could be shared.
>
>
Great, I'll proceed like this: after this PR is approved, I'll move on to
xp_common.c in a separate PR.
> It's not necessary but might be better to include it or at least research
> to get an idea about the whole design.
>
>
I’ll look into it and see if it’s feasible without risking regressions,
major changes, or core modifications. If it is feasible, I’ll include it
directly in this PR; otherwise, it can wait for the future.
> Please create a draft PR for this so we can discuss it there. It's much
> easier than here.
>
>
Sure, I'll prepare the draft as soon as I wrap up the final details and get
it ready for DTLS 1.3, I don't think it will take too long.
>
> I guess it would be good to support so it's consistent but it's not
> necessary if it would be a pain to do.
>
>
I’ve already tried doing that; it’s a somewhat lengthy task, especially
since the risk of regression is very high. I’d prefer to include it in a
future PR that I’ll create after this one.
> Keep it consistent with tls to not over complicate it.
>
Great, then I'll leave it as it is now (exactly like tls://).
Thank you again for your valuable time and advice.
Kind regards,
Gianfrancesco