>The latter is the problem with 
>just putting the compression layer inside >the SSL/TLS layer, you need an 
>out-of-band (read: application) mechanism >to decide when to use it or 
>not.
I must admit I didn�t think in this problem when I posted my message (I�m not an 
expert :-( ), because I have used this kind of BIO only with PKCS7 files and then 
PKCS7 attribute "Type Of ContentData" (I dont remember exact OID)  gives that 
"out-of-band" decission telling me how to read the file when I receive it, uncompress 
or not.
I suppose SSL has some way to extent negotiation to fit future new features, so this 
"out-of-band" could fit there.

>perhaps buffering/flushes 
>would be the problem when applications >use non-blocking sockets?
I think ZLIB allows partial reads/writes with its internal enqueing mechanics, as you 
can see looking at gz_read( )/gz_write( ) functions. In fact, what this functions do 
is very similar to what BIOs do to handle partial reads/writes (to wait another 
invocation and then see if stream can go on)
In the implementation I mentioned before, this logic is taken outside gz_read/gz_write 
and put on a BIO.
So I suppose that if a socket return less bytes than expected this layer would return 
not the new bytes received, but the already avilable uncompressed or nothing until a 
new uncompress can take place.
I'm not sure, but Is not this way how BIOs work?. Then, this is the same and should 
work.
About flush, I just can say it works whit file,zBIO,MD5,Cipher,base64 bios all chained 
together.


>I assume you ment to chain it with a >memory/buffer 
>BIO? Ie. going from;

>      --> write_BIO -->       >-- \
>[app]                   [SSL]      socket_BIO
>      <-- read_BIO  <--       <-- /

>to;

>      --> write_BIO --> zlib_BIO -->       >--\
>[app]                                [SSL]    socket_BIO
>      <-- read_BIO  <-- zlib_BIO <--       <--/

>?

Yes , the first BIO must be something taking "plane compressibe data" that the second 
"zBIO" can easily compress.



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

Reply via email to