Re: [boost] Re: Re: State of giallo, (sockets and demultiplexing)

From: Carlo Wood (carlo_at_[hidden])
Date: 2004-09-15 16:28:38

On Wed, Sep 15, 2004 at 04:55:05PM -0400, Hugo Duncan wrote:
> documentation is sorely lacking... but giallo adds a level of indirection
> to what I have understood of your current thinking:
> 
> reads, writes etc are not directly initiated by the demultiplexer,
> rather by the connection class, which is responsable for
> combining the socket (pipe, or whatever else) class with the
> demultiplexer, hiding the details of which demultiplexer is
> used and ensuring the socket is in the correct blocking/non-blocking/
> asynch mode.

Ok, I considered that to be obvious.

Consider the abstract Source 'device'.  This device is capable to
delivering a (byte) stream of data and/or a stream of data in the
form of 'packets'.  Also the byte-stream will will be delivered
in packets (significantly more than 1 byte at the time) but in
that case the size of a 'message' or packet is unknown.

Then what is needed is the following:

1) An object that encapsulates the 'device' abstration.
2) A way to request more data (this exists of a function
   call to which the user provides a buffer pointer, and
   the size of that buffer)
3) An entry point for a thread to call to 'sleep/wait'.
4) A callback (or completion) function that is called
   when a new packet was received.

It should be possible that point 4) is *entirely* handled
in the user code, the only thing that the user wants it
get control of the thread again once data is available.
The user then can examine the received data, manage its
own buffering and decide to either decode a message and
handle it - or to leave the partial message in the buffer
and request for more data.

Only once we have this interface we can provide "convenience"
classes that do buffering for the user as well.  And even
think about providing protocol decoders too for common types
of protocols (text, envelloped binary, fixed message sizes etc).

The most frequently used name for the function mentioned
in point 2 above that I have seen for sockets is 'async_recv'.

Note that async_recv cause its completion routine to be
called as soon as new data is available and additional
data would cause more delay (blocking).

A function async_recv_n, that requests *precisely* 'n'
bytes, and not less, can be easily implemented on top of
async_recv - or by means of the OS in some cases.

-- 
Carlo Wood <carlo_at_[hidden]>