Re: [RFC idea] DTLS support in ext/openssl (Openssl\Dtls)
| From: | Rowan Tommins [IMSoP] | Date: | Wed, 24 Jun 2026 21:07:32 +0000 |
| Subject: | Re: [RFC idea] DTLS support in ext/openssl (Openssl\Dtls) | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-131520@lists.php.net to get a copy of this message | ||
Hi Gianfrancesco,
I don't have any expertise of the actual protocol, but do have an opinion on the PHP surface
design. I apologise if the below feels too much like bikeshedding...
On 24 June 2026 12:45:05 BST, Gianfrancesco Aurecchia <gianfri.aur@gmail.com> wrote:
> Should the constructor also accept
> OpenSSLCertificate/OpenSSLAsymmetricKey
> objects in addition to PEM?
I would say *instead of* a string. Accepting a string means the constructor has to document the
expected format, produce appropriate parse errors, etc; accepting an object reduces that to a
standard type check. And if the user already has an object, serialising it and then reparsing it is
duplicated effort.
In general, I would prefer a design which used "real" types throughout instead of strings
and ints, except where performance is critical:
> public const int HANDSHAKE_ERROR = -1;
> public const int HANDSHAKE_CONTINUE = 0;
> public const int HANDSHAKE_FINISHED = 1;
These should be cases on an enum; probably unbacked, unless there's some reason applications
need to work with these integer codes.
> public function getFingerprint(?string $digestAlgo = null): string
Perhaps the supported algorithms could be an enum as well, backed by string.
> public function feed(string $datagram): int {}
> public function pull(): ?string {}
If $datagram has to be in a specific format, would a lightweight DtlsDatagram object be useful?
Again, it would delegate the parsing/validation to a specific factory, and give flexibility for
extra ways of creating or reusing material without going via strings and revalidating.
> public function read(): string|false {}
> public function exportKeys(string $label, int $length):
>string|false {}
If the false case here is an expected condition, like EOF, "?string" might be better. If
it's just a signal for unexpected errors, throwing an exception would be better.
Hopefully someone with more knowledge of the problem space can comment more on the core idea.
Thanks,
Rowan Tommins
[IMSoP]