On Thu, Oct 26, 2000 at 01:58:03PM -0700, David Schwartz wrote:
>> You have to include that BIO_write(bio_io, ...) in this loop!
> Why? I have to data to write. If I had data to write, I would have already
> written it before I entered the loop. If I get more data to write later,
> I'll en
Hi there (again),
On Thu, 26 Oct 2000, David Schwartz wrote:
> > You have to include that BIO_write(bio_io, ...) in this loop!
>
> Why? I have to data to write. If I had data to write, I would have already
> written it before I entered the loop. If I get more data to write later,
> I'll e
> You have to include that BIO_write(bio_io, ...) in this loop!
Why? I have to data to write. If I had data to write, I would have already
written it before I entered the loop. If I get more data to write later,
I'll enter the loop again.
> Either check if data is available from the net
Hey there,
On Thu, 26 Oct 2000, David Schwartz wrote:
> > The connection setup phase shouldn't need to be "special" - but of course
> > I don't know what interesting things you may be doing :-) If your model
> > requires that this is unique and otherwise you've got I/O logic built
> > around the
On Thu, Oct 26, 2000 at 12:01:58PM -0700, David Schwartz wrote:
> [...](this is the code I would call _after_ any case where I did a BIO_write
> to the SSL code):
>
> bool done;
> char buf[768];
>
> done=false;
> while(!done)
> {
>done=true;
>
>// Does the SSL library want to
> > My own code uses bio pairs. We special case the connection
> > setup phase.
> > Otherwise, we basically just manage the four I/O streams and
> > the SSL code
> > does its part without any special effort. Of course, it's
> > multithreaded, but
> > then it has to run on high-end SMP machine
Hi there,
On Mon, 23 Oct 2000, David Schwartz wrote:
> > This is not true. Session caching is independant of the IO mechanism you
> > choose to use.
>
> Then how does the client code know which session to reuse? It doesn't know
> what server it's talking to.
In the case of an SSL server,
Glenn Horton wrote:
>
> Has anyone ever considered providing a GSS-API interface into OpenSSL?
Yes, the Globus GSI is a GSSAPI implementation using SSL.
See http://www.globus.org/security/v1.1/
This has been in operation for over two years, originally using SSLeay, and now
OpenSSL.
> On Mon, 23 Oct 2000, David Schwartz wrote:
>
> >
> > > Some of the difficulties that I'm having revolve around the
> > > fact that the socket I/O code is
> > > integrated into the protocol code.
> >
> > It really isn't. You can very easily use the SSL code just
> to do the SSL
> > stuff a
On Mon, Oct 23, 2000 at 02:36:56PM -0700, David Schwartz wrote:
>
> > > stuff and do all the I/O yourself. The only feature you lose when you do
> > > this is client connection reuse.
> >
> > is it really so? i allways thought that session caching is implemented
> > completely in ssl statemachine
> > stuff and do all the I/O yourself. The only feature you lose when you do
> > this is client connection reuse.
>
> is it really so? i allways thought that session caching is implemented
> completely in ssl statemachine.
Yes, it's really so. The problem is that if you do all the networ
Hi there,
On Mon, 23 Oct 2000, David Schwartz wrote:
>
> > Some of the difficulties that I'm having revolve around the
> > fact that the socket I/O code is
> > integrated into the protocol code.
>
> It really isn't. You can very easily use the SSL code just to do the SSL
> stuff and
> stuff and do all the I/O yourself. The only feature you lose when you do
> this is client connection reuse.
is it really so? i allways thought that session caching is implemented
completely in ssl statemachine.
> server while the read completes? If your server is 100% CPU and no blocking
> I
> Some of the difficulties that I'm having revolve around the
> fact that the socket I/O code is
> integrated into the protocol code.
It really isn't. You can very easily use the SSL code just to do the SSL
stuff and do all the I/O yourself. The only feature you lose when you do
th
14 matches
Mail list logo
