Java SSLSocketChannel/SSLSelector?

[Andi Mullaraj]

Thanks David,

> That is the case today.  I can use one selector event loop today to
> support TCP (including SSL) as well as UDP, even SCTP.  The point of
> selectors is to combine many things into one event loop.

Is this (to use one Selector class only for all protocols) a requirement in
JDK? I haven't seen it, but even if it were (such requirement):
1. I mentioned that the SSLSelector that I am proposing would be able to
select on whatever the default Selector is able to, plus the SSL socket
channels.
2. It would also be able to perform everything without the need for any
extra threads.
3. It would not be anymore an obstacle to additions (such as SCTP) than the
current one (plain sockets) is (if it were to make it to JDK, obviously)

> It is definitely not OS-dependent; something in the end has to call
> selector.select(), and that thing is indeed a thread.

I am beginning to think we might be on different pages here. Someone from
outside the selector calls selector.select(), and all selector's
functionality is handled within the context of the calling thread. So where
is the need for the extra thread here? More specifically, in the
SSLSelector case, a call to its select, ends up usually to a call to its
inner selector.select(), always in the context of the calling thread ... so
same thing again. Why do you think another thread is necessary here (within
the selector itself)?

> I understand the urge to make SSL with Selectors easier, because right
> now it is very painful.

Total agreement. I have one full year of development notes to show how
painful it is. I am talking about a fully functional, completely compatible
Selector, (down to the lock obtention order -- sometimes 6 to 8 locks to be
always kept in order) to vouch for that.

> But this approach is unlikely to succeed, at least in the JDK.

Would you mind clarifying which part doesn't fit the bill? Let's understand
well what is proposed first: A JDK enhancement of
Selector/SocketChannel/ServerSocketChannel able to provide the same exact
functionality across all existing channels (UDP/TCP) as well as SSL. It can
be implemented in pure Java, with no extra threads for selection, with
minimal cpu and memory impact (only for SSL channels) over the current
implementation.

If I were the JDK steward, I wouldn't know what to ask for more. Am not,
and thats the reason I am putting all this under
SSLSelector/SSLSocketChannel implementation, instances of which provide the
same proposed functionality.

Thanks,
--Andi



On Mon, Feb 18, 2019 at 5:47 AM David Lloyd <david.lloyd at redhat.com> wrote:

> On Sat, Feb 16, 2019 at 4:19 PM Andi Mullaraj <andimullaraj at gmail.com>
> wrote:
> > 2. What if someone decides to take the exact same approach to solve some
> other higher-OSI-layer protocol decoding? Now you have to choose which kind
> of protocol you want your selector to support.
> >
> > They create their own selector. I have hard time imagining one selector
> implementation being able to support various protocols at once.
>
> That is the case today.  I can use one selector event loop today to
> support TCP (including SSL) as well as UDP, even SCTP.  The point of
> selectors is to combine many things into one event loop.
>
> > 3. Note that with a plain selector and plain sockets, you *need* a
> thread to support the event loop anyway, I mean it has to run somewhere.
> >
> > I don't have enough knowledge here, but I am thinking it will depend on
> the OS ... if the OS provides similar hooks, then I'd say no other threads
> are needed -- the thread selecting would be entering a wait() until some
> notifier wakes it up ... not vital to the SSL part though.
>
> It is definitely not OS-dependent; something in the end has to call
> selector.select(), and that thing is indeed a thread.
>
> I understand the urge to make SSL with Selectors easier, because right
> now it is very painful.  But this approach is unlikely to succeed, at
> least in the JDK.
>
>
>
> --
> - DML
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20190218/e67fdcd0/attachment.htm>