SSL Engine - Ideal Buffer sizes for inbound and outbound buffers ?

Hi

Could anyone let me know what should be the ideal sizes for the inbound and outbound buffer sizes for the following?

1. Outbound buffer - application data (before wrap)

2. Outbound buffer - net data (after wrap)

3. Inbound buffer - application data(after unwrap)

4. Inbound buffer - net data(before unwrap)

by default it allocates 16K if it is given as <code>sslEngine.getSession().getPacketBufferSize() and sslEngine.getSession().getApplicationBufferSize()</code>. This is also per client, which is huge. (so 4 buffers = 4 * 16K) if we need to cater to > 35K clients, then it will consume lot of memory..Anybody has any clue?

[687 byte] By [shannaraa] at [2007-11-26 22:43:47]
# 1

What the SSLSession is telling you is correct. The application send buffer can be as small or large as you like, but the maximum size of the other three depends on the cipher suite and encryption algorithm. The combination of SSL and the cipher suite set bounds on the maximum SSL record size, and thus on the maximum plaintext message you can receive, and these are all in the neighbourhood of 16k. You can't really allocate less to the receiving buffers without risking receiving ciphertext that can't be decoded.

You could reduce the net send buffer in accordance with the app send buffer size but it's not a straightforward relationship.

ejpa at 2007-7-10 12:00:19 > top of Java-index,Security,Java Secure Socket Extension (JSSE)...
# 2
So how to manage the memory allocation then...? is there any specific pattern that needs to be followed if it needs to be catered to tens of thousands of users?
shannaraa at 2007-7-10 12:00:19 > top of Java-index,Security,Java Secure Socket Extension (JSSE)...
# 3

The net-send and net-receive buffers need to be allocated specifically to the SSLEngine instance, which in turn needs to be allocated specifically for the SocketChannel, i.e. the client session. You can probably do some trickery to share the app-send and app-receive buffers if you're very careful but it's difficult.

ejpa at 2007-7-10 12:00:19 > top of Java-index,Security,Java Secure Socket Extension (JSSE)...
# 4

I am facing a problem while writing data into the channel from server to client. The total data length is 43731 that is to be written. I have the outnetBB size as 32K. But when I wrap as below

outNetBB.clear();

SSLEngineResult result = sslEngine.wrap(src, outNetBB);

retValue = result.bytesConsumed();

System.out.println("***********The Bytes consumed is " + retValue);

outNetBB.flip();

the bytes consumed is returning only 16K. Not all thedata is wrapped in one go. but I need all the data to be written to the channel at one go, since the client on the other side (an applet based app) expects all the data in one shot. The client side cannot be modified for code changes. What should be done at the server to overcome this issue?

Thanks

shannaraa at 2007-7-10 12:00:19 > top of Java-index,Security,Java Secure Socket Extension (JSSE)...
# 5

And when I do something like this (not sure if it is correct or wrong technically though)

SSLEngineResult result =null;

outNetBB.clear();

while(src.hasRemaining()){

result = sslEngine.wrap(src, outNetBB);

retValue = result.bytesConsumed();

System.out.println("***********The Bytes consumed is " + retValue);

}

outNetBB.flip();

...

I get the below result..So somewhere, during the wrap operation, the remaining data is getting lost. Any help please?

***********The Bytes consumed is 16384

***********The Bytes consumed is 0

***********The Bytes consumed is 0

***********The Bytes consumed is 0

***********The Bytes consumed is 0

***********The Bytes consumed is 0

***********The Bytes consumed is 0

shannaraa at 2007-7-10 12:00:19 > top of Java-index,Security,Java Secure Socket Extension (JSSE)...
# 6
There is no room in the output for any more data from the input even though the input has data remaining. You need to test for this condition too.
ejpa at 2007-7-10 12:00:19 > top of Java-index,Security,Java Secure Socket Extension (JSSE)...