Hey there,
On Thu, 30 Nov 2000, Ben Laurie wrote:
> Bodo Moeller wrote:
> >
> > On Wed, Nov 29, 2000 at 11:30:03AM -0500, Tom Biggs wrote:
> >
> > > I guess my main question is, does anyone use it?
> >
> > Yes, but it does not work. The next release will contain a bugfix
> > (not yet written). What SSL_peek is supposed to do is behave like
> > SSL_read, except that the data written to the application buffer
> > is not removed from the internal buffers -- i.e., a subsequent
> > SSL_read (or another SSL_peek) will get the same data again.
>
> Hmm. What I do in the state_machine demo is have a one byte buffer and
> do an SSL_read into it (if it is not already full) - since SSL_read will
> return zero if there's nothing to read, this does the job. Presumably
> SSL_peek could be implemented in a similar fashion. I guess there's more
> elegant ways.
But if your SSL_read does return 1 byte then the state has changed and you
have a byte that you can't really just "give back for a future operation"
can you? (That's not rhetorical, it's quite conceivable amidst the
spaghetti of code I've seen and failed in many places to follow!). Also,
if it's in the midst of a renegotiate, just calling the SSL_read
operation, even if it can't return data, may cause the SSL's state to
advance - and one would hope that SSL_peek() does not change the internal
SSL state, otherwise you could develop heisenburgs where behaviour changes
depending on whether you do peeks or not.
Well, it's quite easy to do in one sense. The state machine model in the
tunala demo whips round shoving data into, and pulling data out of, the
SSL state machine into 4 surrounding buffers. Processing of those buffers
happens at a higher layer - and at that layer it is obviously possible to
do any amount of "peek" logic. In the demo's case, it tries to read() or
write() the buffer data to/from a socket (dependant on select()s of
course) and only when it knows 'n' bytes have been read in, or sent out,
does it actually adjust the buffers accordingly (effectively turning a
"peek" into a "read"). So in this situation, you can peek on the data just
by reading it - until you actually inform the state machine's buffers that
the data is *consumed*, it stays the way it was.
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. I wouldn't be surprised
however if that was quite hard - and using an abstraction around the
outside of the SSL state machine (as is done in "tunala") does not (and
can not) achieve this - whether the outside layer does "read"s or "peek"s
doesn't matter - the inside of the code only does "read"s on the SSL
object which can result in the SSL state changing. Of course in this
non-blocking model, the state of the internal SSL object is in some sense
irrelevant - because of the encapsulation, it manifests itself only based
on the activity that can be seen in the outside buffers and if that is
undergoing "peek"s instead of "read"s, then the state will still be
observed to be "frozen".
I think. :-)
Cheers,
Geoff
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
