2000-09-07 08:22:31 +08:00
|
|
|
=pod
|
|
|
|
|
|
|
|
=head1 NAME
|
|
|
|
|
2016-06-10 04:39:19 +08:00
|
|
|
bio - Basic I/O abstraction
|
2000-09-07 08:22:31 +08:00
|
|
|
|
|
|
|
=head1 SYNOPSIS
|
|
|
|
|
2016-11-11 16:33:55 +08:00
|
|
|
=for comment generic
|
|
|
|
|
2000-09-07 08:22:31 +08:00
|
|
|
#include <openssl/bio.h>
|
|
|
|
|
|
|
|
=head1 DESCRIPTION
|
|
|
|
|
|
|
|
A BIO is an I/O abstraction, it hides many of the underlying I/O
|
|
|
|
details from an application. If an application uses a BIO for its
|
|
|
|
I/O it can transparently handle SSL connections, unencrypted network
|
|
|
|
connections and file I/O.
|
|
|
|
|
|
|
|
There are two type of BIO, a source/sink BIO and a filter BIO.
|
|
|
|
|
2000-09-07 16:07:55 +08:00
|
|
|
As its name implies a source/sink BIO is a source and/or sink of data,
|
2000-09-07 08:22:31 +08:00
|
|
|
examples include a socket BIO and a file BIO.
|
|
|
|
|
|
|
|
A filter BIO takes data from one BIO and passes it through to
|
|
|
|
another, or the application. The data may be left unmodified (for
|
|
|
|
example a message digest BIO) or translated (for example an
|
|
|
|
encryption BIO). The effect of a filter BIO may change according
|
|
|
|
to the I/O operation it is performing: for example an encryption
|
|
|
|
BIO will encrypt data if it is being written to and decrypt data
|
|
|
|
if it is being read from.
|
|
|
|
|
|
|
|
BIOs can be joined together to form a chain (a single BIO is a chain
|
|
|
|
with one component). A chain normally consist of one source/sink
|
|
|
|
BIO and one or more filter BIOs. Data read from or written to the
|
2000-09-11 01:36:15 +08:00
|
|
|
first BIO then traverses the chain to the end (normally a source/sink
|
2000-09-07 08:22:31 +08:00
|
|
|
BIO).
|
|
|
|
|
2016-06-10 04:39:19 +08:00
|
|
|
|
|
|
|
Some BIOs (such as memory BIOs) can be used immediately after calling
|
|
|
|
BIO_new(). Others (such as file BIOs) need some additional initialization,
|
|
|
|
and frequently a utility function exists to create and initialize such BIOs.
|
|
|
|
|
|
|
|
If BIO_free() is called on a BIO chain it will only free one BIO resulting
|
|
|
|
in a memory leak.
|
|
|
|
|
2017-12-12 23:56:50 +08:00
|
|
|
Calling BIO_free_all() on a single BIO has the same effect as calling
|
|
|
|
BIO_free() on it other than the discarded return value.
|
2016-06-10 04:39:19 +08:00
|
|
|
|
|
|
|
Normally the B<type> argument is supplied by a function which returns a
|
|
|
|
pointer to a BIO_METHOD. There is a naming convention for such functions:
|
|
|
|
a source/sink BIO is normally called BIO_s_*() and a filter BIO
|
|
|
|
BIO_f_*();
|
|
|
|
|
|
|
|
=head1 EXAMPLE
|
|
|
|
|
|
|
|
Create a memory BIO:
|
|
|
|
|
|
|
|
BIO *mem = BIO_new(BIO_s_mem());
|
|
|
|
|
2000-09-07 08:22:31 +08:00
|
|
|
=head1 SEE ALSO
|
|
|
|
|
2015-08-18 03:21:33 +08:00
|
|
|
L<BIO_ctrl(3)>,
|
|
|
|
L<BIO_f_base64(3)>, L<BIO_f_buffer(3)>,
|
|
|
|
L<BIO_f_cipher(3)>, L<BIO_f_md(3)>,
|
|
|
|
L<BIO_f_null(3)>, L<BIO_f_ssl(3)>,
|
|
|
|
L<BIO_find_type(3)>, L<BIO_new(3)>,
|
|
|
|
L<BIO_new_bio_pair(3)>,
|
2016-10-20 16:56:18 +08:00
|
|
|
L<BIO_push(3)>, L<BIO_read_ex(3)>,
|
2015-08-18 03:21:33 +08:00
|
|
|
L<BIO_s_accept(3)>, L<BIO_s_bio(3)>,
|
|
|
|
L<BIO_s_connect(3)>, L<BIO_s_fd(3)>,
|
|
|
|
L<BIO_s_file(3)>, L<BIO_s_mem(3)>,
|
|
|
|
L<BIO_s_null(3)>, L<BIO_s_socket(3)>,
|
|
|
|
L<BIO_set_callback(3)>,
|
|
|
|
L<BIO_should_retry(3)>
|
2016-05-18 22:16:40 +08:00
|
|
|
|
2016-05-18 23:44:05 +08:00
|
|
|
=head1 COPYRIGHT
|
|
|
|
|
2017-06-20 09:27:02 +08:00
|
|
|
Copyright 2000-2017 The OpenSSL Project Authors. All Rights Reserved.
|
2016-05-18 23:44:05 +08:00
|
|
|
|
|
|
|
Licensed under the OpenSSL license (the "License"). You may not use
|
|
|
|
this file except in compliance with the License. You can obtain a copy
|
|
|
|
in the file LICENSE in the source distribution or at
|
|
|
|
L<https://www.openssl.org/source/license.html>.
|
|
|
|
|
|
|
|
=cut
|
2016-06-10 04:39:19 +08:00
|
|
|
|