A separate reliable UDP transport class/channel is obsolete.
Retransmission and fragmentation can be handled transparently by an
updated version of SSLEngine's Handshaker using regular unreliable
DatagramChannels for transport. My first sketch was a little hasty.
I've started coding on a copy of SSLEngineImpl called DTLSEngineImpl.
In the end I should be able to merge the changes almost seamlessly
into SSLEngineImpl, though. But threading issues need careful testing
first.
As it turned out SSLEngine's class diagram is not as transport
independent as I'd have liked. SSLEngines are created through
SSLContexts (which are also reusable for DTLS), which still have some
dependencies to SSLSockets. I'm planning to return null in those cases.
Right now I'm still figuring out how to get a call to
SSLContext.getInstance("DTLS") connected to the correct setup of my
own code's classes for DTLS. The backend classes contain less comments
and some legacy workarounds which make it harder to read. But I'm
getting there.
I'll keep you updated...
Christian
Am 29.01.2008 um 14:56 schrieb Christian Uebber:
I've finished a first sketch. The application knows about when the
engine is handshaking by checking SSLEngineResult.HandshakeStatus.
All we need to do is to provide a reliable UDP transport class
(including fragmentation and reassembly) as defined in the DTLS
spec, which MUST be used for transporting when the engine is not in
the state of NOT_HANDSHAKING. Anything else could be seamlessly
integrated into SSLEngine.
It would be nicer if this transport class wasn't specific to DTLS as
current and future connectionless protocols could provide comparable
features, but for DTLS 1.0 compliance I don't see a better way right
now. We are not forced to make this specific class mandatory, so
future implementations could just plug in alternatives when the
standard evolves.
Christian
