Geoff Thorpe wrote:
>
> 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.
I'm not sure I get the point of this - why shouldn't peek change the
state? Surely the idea is that peek does a read without dequeueing the
data, not that it doesn't change the state?
> 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.
Right, and this could happen slightly lower down.
> 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 just don't see why this should be so!
> 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 agree that it is hard, which is probably another good reason not to
expect that behaviour.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
