> From [EMAIL PROTECTED] Thu Nov 30 16:39:15 2000
> Date: Thu, 30 Nov 2000 19:04:36 +0100
> From: Bodo Moeller <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Re: SSL_peek()
> Message-Id: <[EMAIL PROTECTED]>
> Sender: [EMAIL PROTECTED]
>
> On Thu, Nov 30, 2000 at 09:37:29AM -0800, Geoff Thorpe wrote:
>
> > The more tricky issue is one of the SSL state itself ... in theory doing
> > an SSL_peek() should allow some data to be generated but with a guarantee
> > that the internal state is completely unchanged.
>
> Should it? I'd have thought that what counts is that any application
> data stays in the buffer for future SSL_read/peek() calls, whereas if
> the request cannot be satisfied, SSL_peek() would return an error just
> like SSL_read(). This should be OK for applications -- you can use
> SSL_peek() to decide how to process the data sent by the peer, but if
> there's no data because of an error, then you don't have much of a
> choice anyway.
>
> My plans include adding flags to SSL objects that allow disabling
> BIO_read and/or BIO_write. Then instead of calling SSL_pending(),
> applications could disable all BIO operations and call SSL_peek(),
> which unlike SSL_pending() can report errors (so it'll work when
> readahead is enabled, which is a case in which SSL_pending()
> does not work well).
>
Doing a 'peek' type operation correctly IS a bit tricky.
It should have no "apparent" effect on the underlying 'system' -- i.e.,
whatever is beeing 'peeked at'.
When there _is_ something there to be peeked at, this is a 'relatively'
straight-forward issue -- hold said content in a private cache, and have a
subsequent 'read' return from the cache, _if_ cache is non-empty, and execute
the actual processing otherwise. However, this 'simplistic' approach does
not cover the situation where "something else" may affect the underlying
system between the time of the 'peek' and the 'read'. e.g. some sort
of 're-positioning' operation on a "byte-stream". One has to hook _all_
those operations, so that they 'invalidate' the cache, as well.
Secondly, there's the 'nothing to be looked at' scenario. a 'peek' has
to return a 'unique' signal for that condition. A secondary issue is
whether that is the *only* 'error information' that it should report.
If a peek reports only 'nothing to bee seen, then it is critical that
the underlying condition be cached and returned by a subsequent 'read'
invocation (unless 'invalidated' by 'something else' happening, see the
scenario 1 discussion). On the other hand, if a design decision is made
that 'peek' should report any error condition that an actual 'read'
operation could report -- e.g. 'end of file', 'data error', 'protocol
error', whatever -- well, then you're into the 3rd scenario.
Lastly, there's the 'error in underlying system detected' scenario. When
'peek' reports the underlying problem, _that_ error condition should be
cached as well, such that a subsequent 'read' would return _exaclty_ the
same condition information. Assuming the underlying system is 'unchanged',
that is. "What to do" if a 'something else' affects the underlying system
between the 'peek' and the 'read' is where things get *really* messy. A
blanket statement about 'correct' behavior is nigh impossible. One either
propogates the 'cached' error condition, *or* 'suppresses' that (now
"historical") error, and reports the _current_ conditions. It pretty much
takes a case-by-case evaluation of 'what is _appropriate_ in *this*
situation?' to resolve. Sometimes it is of critical import to report _all_
abnormal events 'in sequence'; in other situations, only the 'last' error,
and/or 'current condition' is of import.
The case-by-case consideration is full of alligators. Just enumerating
all the 'possible' events, or COMBINATIONS of two -- or more(!!) -- events,
that could happen between a 'peek' and 'read' is a formidable, if not
impossible task. I strongly suspect it's a "halting problem" issue.
Heizenberg was right!!
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
