> > 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. > I agree the compatible model should exist, the jury is out on the > default behavior. Your kernel-socket-like paradigm should be just a > usage case but it should not be the only usage case My two cents: it should be the default behavior. From a usability perspective, you'll have the general population of application writers up and running with much less support/headache. The 10% (or whatever) that are worried about a memcpy or two (yes I'm oversimplifying) can use the advanced methods. > One interesting performance case is there any margin to be gained from > having application space hand over the data buffer (like for OVERLAPPED) > to the next layer down. But this buffer has a known amount of headroom > (at the start) and tailroom at the end... My two cents: I probably wouldn't use that in my application where I'm using OpenSSL for signaling (relatively low bandwidth), but I can see where others might. I have a media server serving AES encrypted audio and I do exactly what you suggest: pass buffers with room for RTP headers and authentication tailers to avoid memcpys for each media packet.
