I'm glad this works for you, but be warned: the fact that that cute
hack works in your environment now will not guarantee it will work
elsewhere. The fact that you need to transmit another few ('faked')
bytes to get the data you want is a clear sign there's a TCP stream
(or SSL BIO) issue underlying it all.As I mentioned before, TCP is a stream protocol, not a message protocol, so when you expect to receive all data before sending another request over the same TCP socket, that is plain *wrong*, though some people here appear to think this is possible. (It is only possible when you actively 'tweak' your TCP stack into forcing it NOT to buffer any data. Which is not part of any standard and thus highly os dependent, but I digress.) If you really NEED to receive *complete* answers before you can transmit the next request (and watch these words: 'on the same SSL/TCP socket'!) the only proper way of doing so is by using single transactions (no pipelining). In HTTP terms that means you should transmit the header Connection:close along with your request, thus requiring the HTTP server to close the connection - which will result in its buffers being flushed for sure and you receiving all your data. (Another way which can accomplish the same thing is a TCP write-side half-close, but I am not sure that'll work with SSL sitting in between, though it has SSL_shutdown(). Never tried and tested it extensively in my own code so I can't say.) If you don't want /that/ (one connection per request), the only alternative is pipelining multiple requests on a single SSL/TCP connection, which is harder to accomplish and as you found out will never guarantee you will receive all data for request N-1 before you send request N at application layer of the network stack. With or without SSL sitting in that network stack. The statement 'TCP is a stream-based protocol, /not/ a message-based protocol' is not just words to fill a page. It has some very far-reaching implications that you should be aware of at all times. What I'm saying above may sound odd or condescending to some. If so, sorry for that. But try running this kind of code on different network infrastructures (switch from LAN over Gigabit Ethernet to, say, TCP over PPP on a dial-up on TCP over ADSL and you will find out that on some of those networks the code acts 'weird' or not at all. That's because you didn't treat TCP as the stream protocol it is and when the network has a different MTU you may well end up back at square one. Adding SSL on top does not change any of this. And note that when you are talking HTTP, generally that includes InTERnet usage of said protocol, where you do not have /full/ control over the MTU and other network factors which /will/ impact your code when you treat SSL/TCP as a message-based protocol. Which, I can't repeat this often enough, it isn't. (And if you consider improving the quality of your solution, check out the books written by W. Richard Stevens. They don't cover the hottest stuff (IPv6), but sure as hell do cover TCP and all the other protocols in a very good way.) Sorry to stick a stick in the works like this, but it's rather better to spend time on it while in development than having someone (or yourself) attempting to 'service' a production server with such code while people are breathing down your neck. Test your code with different TCP and SSL buffer sizes (see setsockopt(SO_SNDBUF / SO_RCVBUF) or ioctl/fcntl equivalents on your system) and test again: the code should perform correctly with all buffer sizes and settings, Take care, Ger On Fri, Aug 1, 2008 at 5:11 AM, petekolle123 <[EMAIL PROTECTED]> wrote: > > Hurrey > I have the solution! > :clap::-D > > If SSL_get_error give SSL_ERROR_NONE > I test with strcmp ( at the end, "</soap:Envelope>") . > because all data from the server must end with "</soap:Envelope>". > If my data is not complete I send CR LF and the last 975 Bytes appeared > SSL_write(mySSL->ssl,"\r\n", 2); > > Thanks Peter > > > > -- > View this message in context: > http://www.nabble.com/Last-portion-SSL_read-only-after-a-SSL_write-.--Please-Help.-tp18717834p18767511.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]
