Implementation of RFC 2920 PIPELINING extension, client side only for now.

This restructures the client_* API internals significantly.  The code becomes
pipelining in nature.  All SMTP commands are put on the output queue and
dequeued as quickly as possible.  Once dequeued, they're moved to the receive
queue so that replies can be matched with previous commands.

Dequeuing commands from the output queue halts when the count of commands
currently in-pipeline (``cmdi'') is equal to the command send window (``cmdw'').
There are three cmdw values useful in practice:

0               clear pipeline, ie. inhibit all future sends
1               disable pipelining, ie. use old ``one-request-one-reply`` mode
SIZE_T_MAX      enable pipelining, ie. dequeue as many commands as possible

At the beginning of session cmdw is 1.  When it is found that peer supports
PIPELINING, it grows to SIZE_T_MAX.  After dequeing DATA it is again 1.  After
sending QUIT it is 0.

Each command dequeued from the output queue becomes a buf in a msgbuf.  The act
of combining multiple commands into a single send operation did not need to be
implemented: buf_write() already combines bufs using iovec and sends them at
once using sendmsg(2).

Tested by todd@ and oga@

"looks good" to gilles@

0 files changed, 0 insertions, 0 deletions