> Of course it is sane; it is sane for OpenSSL to provide clear > demarkation of exactly which data is committed and which data is > uncommitted.
Consider the following scenario: 1) You ask OpenSSL to send 16 bytes. 2) OpenSSL accepts/encrypts those 16 bytes. 3) This results in a 24 byte record. The other end cannot decrypt any of the 16 input bytes until it gets all 24 output bytes and every output data byte depends upon all the input bytes mixed together. 4) OpenSSL goes to send the output bytes, but only 12 of them are sent. What data is committed? None? All? Even though not all of it has actually been sent yet. The other side will receive no data. What should OpenSSL return in this case? Ponder: If it returns '16', you may not call into OpenSSL again and assume the other side will get the data. If it returns '0', you may assume none of those bytes will get to the other side. But they must! > It is conceivably possible for an application to implement a priority > queue just above the SSL layer so that its possible for the application > data to change between a previously failed call and the next successive > SSL_write() call. It is after all possible to do this with direct > send() calls to a socket since the kernel provides clear demarkation. But the kernel doesn't face a situation where byte X affects bytes X and X+1. In the situation above, there is no return value OpenSSL can possibly give you that accurately reflects the situation. Telling you it took all the data might mean you don't call any OpenSSL function again for quite some time, in which case the other side will get *NONE* of the data. Telling you it took some or none of the data might make you think that it isn't irrevocably committed to sending those exact 16 bytes. You are asking for the impossible. DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
