43 lines
1.2 KiB
Text
43 lines
1.2 KiB
Text
|
=pod
|
||
|
|
|
||
|
|
=head1 NAME
|
||
|
|
|
||
|
|
bio - I/O abstraction
|
||
|
|
|
||
|
|
=head1 SYNOPSIS
|
||
|
|
|
||
|
|
#include <openssl/bio.h>
|
||
|
|
|
||
|
|
TBA
|
||
|
|
|
||
|
|
|
||
|
|
=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.
|
||
|
|
|
||
|
|
As its name implies a source/sink BIO is a source or sink of data,
|
||
|
|
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
|
||
|
|
end BIO then traverses the chain to the end (normally a source/sink
|
||
|
|
BIO).
|
||
|
|
|
||
|
|
=head1 SEE ALSO
|
||
|
|
|
||
|
|
TBA
|