Re: [boost] [asio] Higher order operations and concepts

From: Mats Nilsson (mats.nilsson_at_[hidden])
Date: 2005-12-24 08:55:39

Hi

Christopher Kohlhoff wrote:
> If the calls are too fine-grained then yes, performance could be
> adversely affected. I suspect the ideal involves a combination
> of stream layering and operation composition. Some possibilities
> might include:
> 
> - A line_buffered_stream class template that can be wrapped
>   around stream_socket (or other implementations of the Stream
>   concept). This would optimised for line buffering but without
>   the need for pushing back data on to the buffer. It would
>   issue reads to the underlying stream in large chunks.
>   Line-oriented protocols can be layered on top of this using
>   operation composition.

Note that some protocols switch out of line mode, for instance HTTP, FTP/TLS
and SSH. So unless there is a way to push data back to the buffered stream
it would be difficult to account for this.

> - An http_connection class template (again wrapped around a
>   Stream) that minimises calls to the underlying Stream, but
>   uses a buffering strategy optimised for HTTP. Higher level
>   functions like a single async_http_get_content function would
>   be implemented in terms of this.

Maybe a combination of asynchronous and synchronous strategies here. The
buffered stream layer leads its own async life requesting large buffers as
needed, while providing services for the layers above it using an async
interface, but which may be carried out without a roundtrip to the
dispatcher unless more data is actually needed.

> The Dispatcher concept is for general handler dispatching, and
> the demuxer is one implementation (locking_dispatcher is
> another). However the classes that refer to a demuxer_type do so
> because they specifically need a demuxer, not just any old
> dispatcher.

What aspect makes demuxer_type different from Dispatcher? Could this Demuxer
concept derive from Dispatcher?

Or do you mean that they specifically need a particular demuxer instance, or
need to refer to the very same class as some other entity? 

> Portable cancellation is achieved by closing the socket. Any
> higher level abstraction would need to offer some sort of
> cancellation function that forwards the calls to the underlying
> socket, timer etc.

Another concept? "CancelableOperation"?

Mats