On Sat, Dec 18, 2010, Allon wrote:
>
> >> You're looking for a BIO_s_mem.
>
> >No, he is looking for BIO_new_bio_pair(3) and SSL_set_bio(3).
>
> I have read this thread and others, and it is not clear yet why
> BIO_new_bio_pair should be preferred over 2 BIO_s_mem's. Anyone knows the
> answer?
>> You're looking for a BIO_s_mem.
>No, he is looking for BIO_new_bio_pair(3) and SSL_set_bio(3).
I have read this thread and others, and it is not clear yet why
BIO_new_bio_pair should be preferred over 2 BIO_s_mem's. Anyone knows the
answer?
Allon
--
View this message in context:
http://old
> In the case I get an epoll-triggered recv() from the socket, do I dump
> that data into the BIO via BIO_write, and follow that with a
> SSL_read()?
> -Aaron
No, you are still trying to treat it like a pipe. It is not. It has four
*INDEPENDENT* ports.
The fact that you received encrypted data
Hello Victor,
Just want to clarify. Should the complete code look like this ?
ctx = SSL_ctx_new();
myssl = SSL_new(ctx);
BIO_new_bio_pair(app_bio, 0, net_bio, 0);
SSL_set_bio(myssl, app_bio, app_bio);
n = SSL_write(myssl, buffer, len);
err = SSL_get_error(myssl, n);
BIO_read(net_bio, buf, size
AM
To: openssl-users@openssl.org
Subject: Re: nonblocking implementation question
On Tue, May 26, 2009 at 5:27 PM, Victor Duchovni
wrote:
> On Tue, May 26, 2009 at 05:02:59PM -0400, Aaron Wiebe wrote:
>
>> >> You're looking for a BIO_s_mem.
>> >
>> > No,
On Thu, May 28, 2009 at 3:32 PM, Victor Duchovni
wrote:
> NO! You call
>
> n = SSL_write(myssl, buffer, len);
> err = SSL_get_error(myssl, n);
>
> "err" may be SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE, in which case
> you must retry the write again later, after there is room.
>
>
On Thu, May 28, 2009 at 02:48:34PM -0400, Aaron Wiebe wrote:
> On Tue, May 26, 2009 at 5:27 PM, Victor Duchovni
> wrote:
> > On Tue, May 26, 2009 at 05:02:59PM -0400, Aaron Wiebe wrote:
> >
> >> >> You're looking for a BIO_s_mem.
> >> >
> >> > No, he is looking for BIO_new_bio_pair(3) and SSL_set
On Tue, May 26, 2009 at 5:27 PM, Victor Duchovni
wrote:
> On Tue, May 26, 2009 at 05:02:59PM -0400, Aaron Wiebe wrote:
>
>> >> You're looking for a BIO_s_mem.
>> >
>> > No, he is looking for BIO_new_bio_pair(3) and SSL_set_bio(3).
So, apologies for hammering this down, but I'm still a little fuzz
> Basically, I don't really want any calls to require more than a
> context that needs to be maintained - I don't want to hand my data off
> to the API and have to come back to it at some arbitrary later time,
> having it buffered and/or queued by mechanisms built into the openssl
> api. I expect
On Tue, May 26, 2009 at 05:02:59PM -0400, Aaron Wiebe wrote:
> >> You're looking for a BIO_s_mem.
> >
> > No, he is looking for BIO_new_bio_pair(3) and SSL_set_bio(3).
>
> And this is where I'm running into confusing bits of information.
> Bluntly, the documentation that I can find is nearly usel
On Tue, May 26, 2009 at 4:46 PM, Victor Duchovni
wrote:
> On Tue, May 26, 2009 at 01:13:33PM -0700, Kyle Hamilton wrote:
>
>> You're looking for a BIO_s_mem.
>
> No, he is looking for BIO_new_bio_pair(3) and SSL_set_bio(3).
And this is where I'm running into confusing bits of information.
Bluntly
On Tue, May 26, 2009 at 01:13:33PM -0700, Kyle Hamilton wrote:
> You're looking for a BIO_s_mem.
No, he is looking for BIO_new_bio_pair(3) and SSL_set_bio(3).
> > In short, I don't really want SSL doing my writing or buffering. ??I
> > just want the library to do my negotiation and encryption -
You're looking for a BIO_s_mem.
-Kyle H
On Tue, May 26, 2009 at 7:33 AM, Aaron Wiebe wrote:
> Greetings All,
>
> I've gone through various levels of documentation to see if there is a
> method available to implement SSL as I have envisioned, but I haven't
> been able to find what I'm looking for
On Tue, May 26, 2009 at 10:33:11AM -0400, Aaron Wiebe wrote:
> Greetings All,
>
> I've gone through various levels of documentation to see if there is a
> method available to implement SSL as I have envisioned, but I haven't
> been able to find what I'm looking for. Perhaps someone here could
>
14 matches
Mail list logo
