> One more question: I'm working on an ansynchronous framework, and > there's a "poll" method that gets called in each iteration. In our > sockets, this method's supposed to do whatever needs doing, and return > how many bytes are waiting to be read from the socket, so the return > value should be the value of SSL_pending, if I want SSL to be > transparent. The problem is that SSL_pending might return 0 if there's > stuff on the socket, but isn't enough to decode a full record. And as > long as poll() returns 0, no calls to read() which triggers a call to > SSL_read() will be made, so I need to call SSL_read() in the calls to > poll(), or to find some other way to force SSL to process a little bit > of data. Should I call SSL_read() with a num value of 0? will that > work? or is there something else I'm missing here?
This seems like a strange and inefficient architecture. Why receive the data twice, once in a some kind of 'poll' operation and then again in a 'read' operation. Either the 'poll' operation should just say "do something" or the 'poll' operation should provide the data. Why not just call SSL_read in the 'poll' operation and if the return value is non-zero, stash the data in a buffer and return the number of bytes you read? That way you won't need to call into the SSL engine again to get the data you knew you needed anyway. If the purpose of the 'poll' operation is just to say "yes, there's something to do", then you should not be calling the 'poll' operation unless directed to by the SSL framework. If the SSL framework returns 'WANT_READ', then you know that no further progress will be possible until either you can read more data from the socket or something else happens. In that case, your 'poll' can check the real socket. Otherwise, it is a mistake to wait since the data may already be there. In sum: 1) Check the socket for readability only if the SSL engine last gave you a WANT_READ and you've made no further progress since then. Otherwise, just call SSL_read. 2) Don't try to figure out how many bytes there are, just get them, and then not only will you know how many there are, but you'll know what they are too. You'll definitely need that later, so don't force the SSL engine to do the work of processing them twice. DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
