Eric Young wrote:
> On Fri, 15 May 1998, Christian Starkjohann wrote:
> > this must be a frequently requested feature, but I have not found
> > much about it in the archives. The basic functionality of SSL
> > should be implementable with the following simple interface
> > structure:
> ....
> > With this structure, the flow control is governed by the transport
> > layer, not by the application. This is usually what is desired.
> >
> > The usual socket interface is the other way around: The
> > application layer calls the transport layer. This creates all
> > kinds of problems with blocking vs. non-blocking I/O etc.
> >
> > Now my question: is such an interface available in SSLeay?
>
> Funny you should ask :-). Basically you have descibed the
> non-blocking model so popular in Winsock :-).
I don't know Winsock at all, but I have used this interface model in several
protocol stack implementations with great success. I like it for its simple
interface and good efficiency.
> The way SSLeay supports this interface is that any call to
> SSL_read/SSL_write, if it would block, returns -1 and a call can
> determine if it was a 'no data' available situation.
> The application has to determine when to call SSL_read/SSL_write.
>
> It is a little ugly, but at least the event driven model can be
> implemented on this but it is hard to do the reverse.
Yes. I thought there might be an underlying API that can be used to
implement any of the models. Implementing the event driven model on top of
the non-blocking call interface looks a bit inefficient, but if it's the only
way, that's OK.
--
Christian Starkjohann
mail: <cs -AT- obdev.at> or <cs -AT- hal.kph.tuwien.ac.at>
web: http://www.obdev.at/
+-------------------------------------------------------------------------+
| Administrative requests should be sent to [EMAIL PROTECTED] |
| List service provided by Open Software Associates, http://www.osa.com/ |
+-------------------------------------------------------------------------+
