directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Wallace <>
Subject Re: [OT] Non-blocking file I/O and TLS/SSL support
Date Tue, 14 Dec 2004 03:30:23 GMT
Quoting Berin Loritsch <>:

> Alex Karasulu wrote:
>> Richard Wallace wrote:
>>> Hey guys,
>>> This is only slightly off topic, but I was wondering if anyone knew 
>>> the current status of non-blocking file I/O and support for TLS/SSL 
>>> with channels in Java.  I had been hoping that it was going to be 
>>> in the last version released (1.5 or 5 or whatever), but it wasn't.
>> Yeah Santa never made it that time :(.
> The SEDA folks (read Matt Welsh and co.) had put together something of
> that nature for TLS/SSL.
> TLS/SSL is generally the same basic protocol with a different set of
> ciphers (at least this is my current
> understanding).  I used to have a bit more info on the handshaking
> protocol when I put PKS support
> in JMeter--but I'm a bit rusty right now.  I have a book on Java
> encryption, which might have some
> clues.
> It can/should be implemented a sort of subprotocol (if you can embed
> protocols).  Perhaps it can be
> implemented in a MINA/SEDA agnostic manner.  Will look into it.

Thanks Berin.  I knew that the SEDA folks had the NBIO package but my
understanding was that that is not 100% pure Java, which is what I'd like for
better compatability.  I've been wondering what it would take to 
implement this
using the existing java libraries.

> As far as async file IO, the SEDA folks faked it.  They used a random
> access file object and sent
> events to it through the "stage" interface.  Essentially they made it
> behave as if it were async, but
> it really wasn't.

I didn't know that's how they did that. =P  That's pretty much how I was
thinking of "faking" it.  I thought they used JNI and native methods for this
stuff too.

> We might be able to fake enough of it using Futures. (Doug Lee
> concurrent/Java 1.5 concurrent)

That sounds interesting.  I'll have to take a look into it.  My hope was, of
course, to be able to do this without having to have any threads just sitting
waiting for reads and writes to complete.  Otherwise, you could just create a
couple of stages in a pipeline that do the reading and writing and it's pretty
much the same thing.  But that would use extra threads too. *sigh* Guess you
can't have everything you want all of the time.


This message was sent using IMP, the Internet Messaging Program.

View raw message