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]
