Darryl Miles wrote: > int SSL_write(SSL *ssl, const void *buf, int buflen, int *committedlenptr);
This is an interesting suggestion. This way if *committedlenptr was returned as 0 or as buflen then the application is free to change buf/buflen/contents at will for the next call without worry of messing up the write stream. As it stands today with the current implementation, even if nothing was "really" committed, the application has no way of knowing that and is forced to provide the same buffer and contents. If something was committed, i.e 0 < *committedlenptr < buflen, then basically everything MUST be committed as David points out, and we've got the "special situation". >From here there are a few options: 1) require that the application continues to come back later with buf/buflen/contents intact until all is sent (current implementation, except with new parameter that can help you when nothing is committed and is more clear to the application writer in general as to what's going on under the covers) 2) require that application advance buf/buflen by *committedlenptr until all is sent (there's not really a need to do this from what I gather of the implementation, except it's logical from an application perspective... worse though, it's error prone, and more difficult for the stack to error check, not to mention the stack probably has most or all of the data encrypted, buffered and ready to send anyway I'd think) 3) have the stack save the data and don't require anything further from the application except servicing the write code e.g. via SSL_write(ssl, NULL, 0, NULL) like suggested (probably the best option with this approach). I suppose if the application tried to write more data while servicing was expected you could get a EWOULDBLOCK or something. David Schwartz wrote: > Honestly I think a better job of mimicking TCP's semantics is preferable. > OpenSSL should be able to handle its own send buffer flushing and receive > buffer filling, in the background without me having to ask it, just like TCP > does. This is actually what I thought it was doing until you informed me otherwise. It wasn't at all clear to me that error/retry meant "we may have used some of your data and we expect to get it all back later"... I figured, like I stated before, it consumed it all, or consumed none. Yes, I understand your point about the partial underlying TCP write, but I was expecting the stack saved the unwritten data to make it transparent to the application. David Schwartz wrote: > Another example is OpenSSL prohibiting a concurrent SSL_read and SSL_write > on the same connection. Yes, this is consistent with what other libraries > do, but it's not what TCP does. Yes I unexpectedly ran into that before as well. David Schwartz wrote: > I think a library should be capable of making SSL look as much like TCP as > possible and that this should probably be the default behavior. Totally agree... this whole thread would have been avoided... :) Mark. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [EMAIL PROTECTED]
