This is a workarround to get NIO+SSL with java 1.4:

1. You can get a Socket from a SocketChannel with SocketChannel.getSocket() (Always).
(SocketChannel created with SocketChannel.open() or ServerSocketChannel.accept())

2. Next, you can upgrade the Socket to a SSLSocket with:
http://java.sun.com/j2se/1.4.2/docs/api/javax/net/ssl/SSLSocketFactory.html#cre ateSocket(java.net.Socket,%20java.lang.String,%20int,%20boolean)

3. Now, you can do select operations whith the SocketChannel if it is in non-blocking mode
and write/read with socket.getOutputStream() / socket.getInputStream() if it is in blocking mode.

4. You need to change the blocking mode each time you want to select or read/write.
(It implies register / deregister the SocketChannel with the selector each time)


Vicen?

 

 

Excellent posting.

What about SSL server sockets?

 

 

If you want a SSLSocket that works in server mode in its first handshake (like the SSLSockets obtained from SSLServerSocket.accept()) you only need to call SSLSocket.setUseClientMode(false) before any read or write.

Vicen?

 

 

The following code works for me per above advice:

/**
 * This demonstrates how to use Java NIO to access a remote via an SSL connection.
 */
public class NioSSL
{
	public static void main(String[] theArgs)
	{
		try
		{
			SocketChannel aSocketChannel = SocketChannel.open();
			Socket aSocket = aSocketChannel.socket();
			aSocket.connect(new InetSocketAddress("192.168.104.4", 443));
			Socket anSSLSocket = ((SSLSocketFactory)SSLSocketFactory.getDefault()).createSocket(
				aSocket,
	            "192.168.104.4",
                443,
                true);
			SocketChannel anSSLChannel = anSSLSocket.getChannel();
			System.out.println("anSSLChannel = " + anSSLChannel);
			if(anSSLChannel != null)
			{
				anSSLChannel.close();
			}
		}
		catch(Exception anException)
		{
			anException.printStackTrace();
		}
	}
}

 

 

Hard to see exactly what the point of this is really. The point of NIO is to save threads, and as soon as you go into blocking mode for I/O you need a dedicated thread for that socket, otherwise you are starving any other sockets.

 

 

You go into blocking mode for I/O because you know that there are available data to be read (information provided by the selector). So, the socket is in blocking-mode, but your thread never block because there are available data in the socket.

- Vicen?

 

 

Well if you're only going to read what's available there's no point in going into blocking mode is there? you can do that from non-blocking mode.

 

 

Sorry, I lost the thread a bit there, but you will find that the read can indeed block, because SSL reads and decrypts in chunks (SSL Record protocol) and there can't be any guarantee that available() represents a whole chunk.