Dan Kegel wrote:
Gary Feldman wrote:
and b) should
object-oriented terminology be used in the documentation, as a pedagogical
tool? In other words (for the latter), perhaps the documentation should be
along the lines of: "A BIO is essentially an abstract class, but is
specified in
This makes me wonder whether a) perhaps a native C++ interface is in order
(with the inherent advantages and disadvantages); and b) should
My vote is to keep things in C.
object-oriented terminology be used in the documentation, as a pedagogical
tool? In other words (for the latter),
Gary Feldman schrieb:
specified in C. You can implement your own particular BIO (analogous to
deriving an implementation class from an abstract class), by providing the
following functions (i.e. methods). Since this is C and not C++, you have
to make the methods available as follows,
Hi there,
I was lurking on this thread without replying until now because I'm damned
busy at the moment, and wasn't really sure what the beef was that started
all this ...
On Mon, 21 Aug 2000, Jeffrey Altman wrote:
Maybe, but I'm not sure what you mean exactly. Could you describe
in terms
OpenSSL will do networking for you only if the underlying BIO is a
socket.
The data source/sink for OpenSSL can be anything you choose. The library
comes with a few BIO implementations and if none suit your purpose, then
writing a BIO should not be very difficult as the BIO functions and
their
On Mon, Aug 21, 2000 at 10:48:18AM -0400, Jeffrey Altman wrote:
I'd prefer to bypass all OpenSSL-internal buffering and I/O entirely,
and let the app do all the buffering and I/O.
Maybe, but I'm not sure what you mean exactly. Could you describe
in terms of an approximate example API?
I
Jeffrey Altman wrote:
I think what he would like is the ability to do what the Microsoft
SSPI does. Instead of OpenSSL being a layer between the I/O channel
and the app, he would like the app to provide all I/O functions and
have OpenSSL provide routines that encode and decode buffers
Jeffrey Altman wrote:
I think what he would like is the ability to do what the Microsoft
SSPI does. Instead of OpenSSL being a layer between the I/O channel
and the app, he would like the app to provide all I/O functions and
have OpenSSL provide routines that encode and decode
Jeffrey Altman wrote:
Jeffrey Altman wrote:
I think what he would like is the ability to do what the Microsoft
SSPI does. Instead of OpenSSL being a layer between the I/O channel
and the app, he would like the app to provide all I/O functions and
have OpenSSL provide routines that
Geoff Thorpe wrote:
Anyway, I'm out of here - hope that actually made some sense.
Thanks for the detailed reply, Geoff! It does help.
I've written the loop you described many times for other systems
(including an serial I/O interrupt handler for the IBM PC back in '82)
and there's one in my
Jeffrey Altman wrote:
I'd prefer to bypass all OpenSSL-internal buffering and I/O entirely,
and let the app do all the buffering and I/O.
Maybe, but I'm not sure what you mean exactly. Could you describe
in terms of an approximate example API?
I think what he would like is the
Jeffrey Altman wrote:
Jeffrey Altman wrote:
I think what he would like is the ability to do what the Microsoft
SSPI does. Instead of OpenSSL being a layer between the I/O channel
and the app, he would like the app to provide all I/O functions and
have OpenSSL provide
On Tue, Aug 22, 2000 at 07:44:50AM -0700, Dan Kegel wrote:
It could well just be a lack of documentation and examples.
The code inside OpenSSL and its existing sample apps is
scary enough that it really takes great willpower to sit down
and reverse engineer an understanding of how things
Jeffrey Altman wrote:
I was just attempting to summarize what the original poster was asking
for. I think the primary problem is that there are no example apps
showing how to use the different types of BIOs.
No there isn't much, which is a pity because BIOs are very useful things
and
I'd prefer to bypass all OpenSSL-internal buffering and I/O entirely,
and let the app do all the buffering and I/O.
Maybe, but I'm not sure what you mean exactly. Could you describe
in terms of an approximate example API?
I think what he would like is the ability to do what the
Right on
I also have been asking for this for a year now.
On Mon, 21 Aug 2000, Jeffrey Altman wrote:
I'd prefer to bypass all OpenSSL-internal buffering and I/O entirely,
and let the app do all the buffering and I/O.
Maybe, but I'm not sure what you mean exactly. Could you
Check my original post (I'm copying it below). We're unhappy
with OpenSSL's support for nonblocking I/O on servers; currently,
it either wants you to rewrite your server to let OpenSSL handle
the network I/O, or use BIO pairs to let OpenSSL think it's doing
networking still. Neither
On Mon, Aug 21, 2000 at 04:58:03PM +0200, Nick De Roeck wrote:
Check my original post (I'm copying it below). We're unhappy
with OpenSSL's support for nonblocking I/O on servers; currently,
it either wants you to rewrite your server to let OpenSSL handle
the network I/O, or use BIO pairs to
On Mon, Aug 21, 2000 at 04:58:03PM +0200, Nick De Roeck wrote:
I'm currently writing a multi-platform webserver using openSSL and I do also
experience problems with the fact that the networking code is too tighty
integrated with openSSL. On a unix system this may seem like a non-issue,
but my
Bodo Moeller wrote:
I'm currently writing a multi-platform webserver using openSSL and I do also
experience problems with the fact that the networking code is too tighty
integrated with openSSL. ...
If openSSL would be more of a library that runs on top af a stream (any
stream, being
I'm trying to integrate OpenSSL into a nonblocking
server that already has a firm idea of how it wants
to do its networking. In other words, I want to
use OpenSSL, but *do not* want OpenSSL doing any
networking for me. I also don't want to use any
huge, ungainly abstractions such as BIO pairs.
I agree with you 100% adn I'm in the same boat. I suggest that if we
can't get people on board that we just go our own way. I'll be happy to
work with you on this and you can reply directly and to the list.
The problem is that at this point IMHO the product is designed to fit into
a client
[EMAIL PROTECTED] wrote:
I agree with you 100% adn I'm in the same boat. I suggest that if we
can't get people on board that we just go our own way.
Whatever we come up with, I'm sure the classic OpenSSL API could
be layered on top of it. Perhaps we could consider this effort an
Ben Laurie wrote:
I've obviously missed something ... what problem are you trying to
solve?
Check my original post (I'm copying it below). We're unhappy
with OpenSSL's support for nonblocking I/O on servers; currently,
it either wants you to rewrite your server to let OpenSSL handle
the
On Sun, 20 Aug 2000, Dan Kegel wrote:
[EMAIL PROTECTED] wrote:
I agree with you 100% adn I'm in the same boat. I suggest that if we
can't get people on board that we just go our own way.
Whatever we come up with, I'm sure the classic OpenSSL API could
be layered on top of it.
[EMAIL PROTECTED] wrote:
Whatever we come up with, I'm sure the classic OpenSSL API could
be layered on top of it. Perhaps we could consider this effort an
experimental refactoring of the OpenSSL codebase to improve its
quality and reusability.
I agree with this approach. The
In any event, if we design the proper underlying data structures to
accomodate what we want - then all we need to do is pass this data
structure into the proper state engine and the state engine can find the
parameters the low level subs need and call them. It can even do this in
a
[EMAIL PROTECTED] wrote:
Yup - I think we can contain this quite easily. I'll grab the new source
tree asap and start looking over it with you. WHere we need to start is a
proper design for the datastructures. I like creating a group of function
calls with a not too long mnemonic...
28 matches
Mail list logo
