These are wrappers over virStreamRecv and virStreamSend so that
users have to care about nothing but writing data into / reading
data from a sink (typically a file). Note, that these wrappers
are used exclusively on client side as the daemon has slightly
different approach. Anyway, the wrappers allocate this buffer and
use it for intermediate data storage until the data is passed to
stream to send, or to the client application. So far, we are
using 64KB buffer. This is enough, but suboptimal because server
can send messages up to VIR_NET_MESSAGE_LEGACY_PAYLOAD_MAX bytes
big (262120B, roughly 256KB). So if we make the buffer this big,
a single message containing the data is sent instead of four,
which is current situation. This means lower overhead, because
each message contains a header which needs to be processed, each
message is processed roughly same amount of time regardless of
its size, less bytes need to be sent through the wire, and so on.
Note that since server will never sent us a stream message bigger
than VIR_NET_MESSAGE_LEGACY_PAYLOAD_MAX there's no point in
sizing up the client buffer past this threshold.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
