Hi guys,
the way we handle incomming SSL data on the server will not work if the
data are fragmented.
Let's say we are receiving some Handshake data. This is typically a few
hundreds of bytes, that usually comes in one block. In this case, we are
all good. But if those data aren't read in one
+1
I think we shall rewrite the code and let be driven by the underlying
SSLengine status.
Now, if after processing there are still remaining data in the input
buffer, we must keep it until the next buffer is received.
In order to preserve performances, as we need to assemble the input buffer
Le 5/3/13 3:40 PM, Jeff MAURY a écrit :
+1
I think we shall rewrite the code and let be driven by the underlying
SSLengine status.
Absolutely. I have created a branch to play a bit with SSL.
Now, if after processing there are still remaining data in the input
buffer, we must keep it until
On Fri, May 3, 2013 at 3:47 PM, Emmanuel Lécharny elecha...@gmail.comwrote:
Le 5/3/13 3:40 PM, Jeff MAURY a écrit :
+1
I think we shall rewrite the code and let be driven by the underlying
SSLengine status.
Absolutely. I have created a branch to play a bit with SSL.
Now, if after
Le 5/3/13 4:45 PM, Jeff MAURY a écrit :
On Fri, May 3, 2013 at 3:47 PM, Emmanuel Lécharny elecha...@gmail.comwrote:
Le 5/3/13 3:40 PM, Jeff MAURY a écrit :
+1
I think we shall rewrite the code and let be driven by the underlying
SSLengine status.
Absolutely. I have created a branch to play
On extending java.nio.ByteBuffer : it's not doable because the constructor
is private :(
On Fri, May 3, 2013 at 3:40 PM, Jeff MAURY jeffma...@jeffmaury.com wrote:
+1
I think we shall rewrite the code and let be driven by the underlying
SSLengine status.
Now, if after processing there are
