> Hello
>
[quoted text clipped - 20 lines]
> choice (after the login procedure, encryption is done with a
> proprietary mechanism).
You don't need that, you just need to read the SSLSocket at the server
until you get EOF, then read the raw socket at the server and you should
get 'bla2', if you've set it up the same way as above (i.e. SSLSocket
wrapping an existing socket with autoClose=off). (If you haven't, there
is no point in what you're trying to do, just keep using SSL.)
Elian Kool - 10 Mar 2005 08:11 GMT
> You don't need that, you just need to read the SSLSocket at the server
> until you get EOF, then read the raw socket at the server and you should
> get 'bla2',
Well, the problem is
a) The server has different SSL implementation (ILE C on IBM iSeries)
and handles this a little different
b) Is has to be compatible with the existing Windows client which uses
OpenSSL.dll (and doen't send a close_notify...)
Any idea how to "fix" this on the client side?
> if you've set it up the same way as above (i.e. SSLSocket
> wrapping an existing socket with autoClose=off). (If you haven't, there
> is no point in what you're trying to do, just keep using SSL.)
Sure I did, otherwise it wouldn't work at all :)
elian
Esmond Pitt - 11 Mar 2005 05:44 GMT
The question seems to be whether or not to close the client SSLSocket.
This depends on what the mainframe does, which you haven't described.
Have you tried just flushing the SSLSocket instead of closing it?