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

From: Hugo Duncan (hugoduncan_at_[hidden])
Date: 2004-09-16 10:15:19

On Wed, 15 Sep 2004 Carlo Wood wrote:

> On Wed, Sep 15, 2004 at 04:05:00PM -0400, Hugo Duncan wrote:
>> The proactor and reactor classes in giallo know nothing of sockets
>> etc, and they can run in whichever thread you want.
>
> I cannot imagine at the moment how this would work :/ (see my previous  
> post)

On Wed, 15 Sep 2004 Carlo Wood wrote:

> 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.

Ok, so I seem to have misunderstood what you were asking.

> 1) An object that encapsulates the 'device' abstration.

   in giallo, this is the socket class.

> 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)

   in giallo, this is "connection<>::recv".

> 3) An entry point for a thread to call to 'sleep/wait'.

   in giallo, after calling send/recv the calling function
   just returns. notification is always of completion and
   is not necessarily in the same thread.

> 4) A callback (or completion) function that is called
>    when a new packet was received.

   in giallo, user callback is attached to connection

> 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.

   that is how the connection class in giallo works. it contains
   no "buffer management".

> 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).

   agreed.

Hugo