I knew I had not explained myself well enough given your last response.
I did not mean to attempt to abort the "current chunck", but rather to
be able to read the cancel between chunks so I could do just what you
suggest. Of course, the definition of "current chunk" is part of my
problem. I was thinking of the fact that when I do an SSL_write on a
very large buffer, OpenSSL breaks it up into 16k pieces. Can I somehow
do a read in between writing those 16k pieces or do I have to step back
and do it between just between the "chunks" I sent to OpenSSL through
SSL_write?
BTW, we are using non-blocking sockets so I could clearly read from the
socket between socket writes, but if I SSL_read from the socket during a
long SSL_write operation, I am asking for trouble (with the internal
state) so I don't think I can do the synchronization down at the BIO
level unless I am still missing a big piece of the puzzle.
Thanks again for taking the time to respond to my questions. Your
feedback is very helpful.
I apologize that this discussion has taken on a "user" tone rather than
a "developer" tone. That was not my original intent.
Verdon
>>> [EMAIL PROTECTED] 3/19/2003 5:54:04 PM >>>
On Wed, 19 Mar 2003 16:53:32 -0700, Verdon Walker wrote:
>First, thank you for your responses. I appreciate the feedback, but
>I don't think I understand the points you are making in your last
>email.
>Perhaps, I did not explain myself well enough, but the idea of
>allowing
>long operations to be cancelled is hardly rare. Suppose for example,
>you
>want to search for a friend in the phone book. Whatever criteria you
>specify you are going to want to stop excessive search results from
>continuing once you have found the person you are looking for.
>Supporting that in a clear text mode, but not in an SSL mode doesn't
>make sense.
You try to send 2Mb but then interrupt it. 1,503,257 bytes have
been
sent.
Now what do you do? Do you go back retrospectively and say, "oh, I'm
39 bytes into a 512 byte protocol structure, I'll have to send 473
bytes to recover synchronization so I can start another block?
I have written code layered on top of TCP for more than 16 years
and
I've never seen anything like this.
Much more common is to stop feeding data to the socket by not
sending additional chunks to the sender. In other words, you finish
the current 'chunk' and don't send anymore chunks.
This requires no special support from the socket code and will
work
fine with OpenSSL.
>It would seem that the SSL structure could be shared between reads
>and
>writes if we could guarantee that they didn't use the same members
>of
>the structure. Does anyone know which members are shared between
both
>reads and writes. I know the "rwstate" is, but I'm not sure what
>else.
You are barking up the wrong tree. Sending on an SSL link can
require receiving from the underlying TCP stream and vice versa. You
can't easily make them independent and I don't think you should want
to.
If you must, you can write your own send and receive functions
that
acquire a single lock while they're waiting for the send or receive
to be possible using non-blocking sockets or BIO pairs.
DS
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
