Sounds to me like a case of a pending renegotiation or other alarm signal happening and application level code not allowing this due to your particular implementation of read/write loops, but that is a long shot, as it may be due to several other issues as well.
To quickly get that Win32 item out of the way: I've been using OpenSSL on Windows for almost a decade now: no issues that differ from UNIX (unless you count a few very subtle TCP/IP protocol stack buggers which are most definitely irrelevant here). Sorry, I did/do not have time to have a close look at your code (and FTP is disabled in the corporate firewall). You did not mention in email if you are using blocking or non-blocking I/O, so here's the general idea that applies to both cases: Check your code; compare to the implementation of s_client and the other samples provided with OpenSSL (yeah, yeah, I know, it sometimes looks a bit cluttered in there, but heck, it's sample code, not production quality ready to go) and particularly look at the way the OpenSSL sample code checks for pending incoming data and permission to send additional data. Also check how your code compares to s_client et al when it comes to handling WANT_READ and other particulars (renegotiation, handshaking, ...); I've met a few issues like yours when code did not care about those error codes when they appeared, barging on into a lockup a while later in the process. Best advice I can give you this morning (when time to answer email is almost over for me): get the O'Reilly OpenSSL book; pay particular attention to the chapters discussing blocking and non-blocking I/O. Keep in mind that you should best code your SSL I/O using a single loop handling both read & write operations at the same time, especially when using non-blocking I/O. On the subject of 'end of transmission': sounds like you're using a HTTP Keep-Alive 'persistent' connection here on top of SSL/TCP: in that case the plaintext should contain a header which informs you how many bytes will follow in the answer from the server. When using custom 'persistent' protocols, the same sort of thing applies as well: if an 'exchange' is not terminated by an 'end of connection', you (a) have to inform the receiver upfront how much will follow, so you can cut the incoming data into proper 'pieces' (messages), and (b) you may run into additional 'fun' with TCP as it is a stream-based and /not/ a message-based protocol, so there's a big chance the last few raw bytes are lingering in the buffers at the server side, waiting to be bundled with additional data to follow. Which will only happen when you request more, or when a (rather long) timeout expires. When subsequent requests (client-side transmit) are not dependent on each other, you're safe, but should remind yourself at all times, in both blocking and non-blocking I/O cases, that response data comes in asynchronously: do NOT expect to receive all data for request N-1 before sending request N when you are still sitting on top of the very same TCP connection. That's a TCP thing, not SSL, BTW. Even though OpenSSL does some additional buffering on it's own as well. Heck, you don't have any guarantee whatsoever the data for request N-2 (N-3, ...) will have arrived by the time you transmit request N: if the reponses are small enough, they'll be bundled in the server-side TCP stack buffers before transmission (to reduce network load due to otherwise flooding the pipe with small TCP packets and consequently extra, useless, message and header overhead), meaning you're going to wait a bloody long time for them if you don't ask the server to send more data still (or close the connection). Lovely beasts, persistent connections. :-) (And just to warn you up front if you persue the 'TCP is stream, not messages' thing mentioned above: I can guarantee you the 'Nagle' option is /not/ a proper solution, though it may look like one. Just a friendly warning. Stay clear of Nagle et al, unless you know /exactly/ what you are doing, protocol-wise. ) HTH Ger On Wed, Jul 30, 2008 at 5:38 AM, petekolle123 <[EMAIL PROTECTED]> wrote: > > > Thank you for the fast answer. :-) > > On > ftp://erbse:[EMAIL PROTECTED]/ > there is the request/response string and the function SSL_WR_RD().C > > but SSL_read says "there is no more to read" stops the loop > because SSL_get_error give SSL_ERROR_NONE and return from function. > The request/response data must end with "...</soap:Envelope>" > > All the source examples I found use SSL_get_error to find out > "there is no more to read". > > But this obviously doesn't work. Perhabs doesnt work on w32 machines. > > You are right I have to make the next request when all is read. > The question is, how can I detect the read has finished ? > > > thanks Peter > > > > > > > -- > View this message in context: > http://www.nabble.com/Last-portion-SSL_read-only-after-a-SSL_write-.--Please-Help.-tp18717834p18725602.html > Sent from the OpenSSL - Dev mailing list archive at Nabble.com. > > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > Development Mailing List [email protected] > Automated List Manager [EMAIL PROTECTED] > -- Met vriendelijke groeten / Best regards, Ger Hobbelt -------------------------------------------------- web: http://www.hobbelt.com/ http://www.hebbut.net/ mail: [EMAIL PROTECTED] mobile: +31-6-11 120 978 -------------------------------------------------- ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [EMAIL PROTECTED]
