I'm not at a location to access the account that receives the subscription
mail today so please CC this account on a reply, [EMAIL PROTECTED]

I'm kind of delving over which way I should implement buffering.
I looked through some of the source code and found in bf_buff.c

#define DEFAULT_BUFFER_SIZE 1024

the code appears to use this as the buffer size before calling the
underlying routine ( SSL_write ) in my case.

What is the reasoning for 1024?  Or do the encryption routines like a 1024
data segment?  "openssl.cnf" configuration file has a name=value pair of
"default_bits=1024" is there an association here?  Or simply this has worked
best in the past.  If my memory serves me right doesn't each of the
encryption algorithms dictate there own max memory size that it will encrypt
in each message it sends over the network.

Before asking my original question and then learning about BIO I did a
little recoding to try to make my output to a plain socket unbuffered to try
to make use of the same code as I was doing with SSL_write().  But I had an
idea to call getsockopt() to find out the socket's SND buffer size and make
send() calls using data segment sizes based off of the buffer size (although
I'm don't know a simple way to confirm that this is a more efficient method
than just buffering the socket).  If BIO is simply using 1024 (or some other
value I can figure out in run-time) I could make SSL_write() calls using
that fixed size in the same code; and if/else whether it is an
encrypted/unencrypted socket.

Yeah, I know I'm being difficult, but then again I could be doing this whole
web app in a scripting language in a week and not deal with any of this.

Much thanks for the pointers on the last question, and thanks for putting up
with this question.





_______________________________________________________
Send a cool gift with your E-Card
http://www.bluemountain.com/giftcenter/


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [EMAIL PROTECTED]
Automated List Manager                           [EMAIL PROTECTED]

Reply via email to