Subject: [cicm] Channel I/O

From: "Novikov, Lev" <[email-masked]>
Date: Wed, 16 Jun 2010 15:32:28 -0400

Terminology:
- CHANNEL: the most general abstraction for a connection between a module and software.
- CONTROLLER: a channel that has management capabilities.
- STREAM: a channel that has data-passing (sending, receiving or both) capabilities.
- CONDUIT: the channel that has both management and data-passing capabilities 
	(the logical union of a controller and stream).

(See: Section 2.3.3, http://tools.ietf.org/html/draft-lanz-cicm-00#section-2.3.3)

I/O, therefore, is done primarily by a stream or a conduit and consists of two modes:
blocking and non-blocking. BLOCKING refers to a mode where the method does not 
return until the buffer is full. For example, Decrypt::Stream::decrypt()
does not return until the buffer is full (or an error occurs). Similarly,
Encrypt::Stream::encrypt() does not return until the operation completes (or
an error occurs).

NON-BLOCKING refers to a mode where a buffer is registered, and periodically polled
to determine its status. Decrypt::Stream::decrypt_non_blocking() performs the
registration/filling while Decrypt::Stream::decrypt_poll() returns the status.
Encrypt::Stream::encrypt_non_blocking() and Encrypt::Stream_encrypt_poll() 
perform in a similar fashion.

* Are these modes sufficient; are others necessary?
* Are there any implementation issues with these modes?

Lev