Re: [boost] [async] messages threads and networks

Subject: Re: [boost] [async] messages threads and networks
From: Scott Woods (scott_at_[hidden])
Date: 2010-04-24 16:28:34

> > I am interested in a Boost review of this library but suspect it is
> > too large. It also overlaps with several existing boost components.
> > But good to get further opinions.
>
> I have read your last posts about your mega library. I'm interested on the 
> kind of services the library could provide.
>

Perhaps MegaMessaging.lib?

> I don't think people would spent time to inspect code without the Boost 
> license that reinvent a lot of Boost libraries.

Sorry this is a little confusing. I can understand that Boosters will be 
less inclined to review a library
that replicates some existing Boost components. Even if there is 
differentiation in the implementations
I am resigned to the natural reluctance.

But it is the sum of the parts that I have hopes for. I am willing to 
substitute reinventions with the
appropriate Boost component as necessary.

But you also mention the lack of a Boost license. Are you suggesting that 
all code offered for
review must first hand over all rights? With some effort I can see 
justification for such a position
but it leaves me (and others like me) with a difficult question.

> Is there more documentation that the one contained on the link?

Yes but they are internal and extremely abstract. Peer reviews have 
suggested that these docs are
probably not useful to users of the library.

This library is an internal development. It is/will be used for product 
development. All the materials
that you have seen were created at the expense of that development. And in 
the full knowledge that
organizations such as Boost are less than likely to accept/adopt/integrate.

> Could you show how the objects read the messages?

I'm not entirely sure what you are asking for. If I give a quick description 
perhaps you can
highlight the section of interest?

Objects are read by calls to codec_base::decode (lhc/codec_base.h). This is 
a virtual member that
invokes the parsing implementation for whichever encoding type has been 
selected. Those implementations
are generally a combination of lexical analysis (manually defined state 
tables) and actual parsing
(simple stack manipulation for simple encodings, BNF tools for XML). Some 
related files are;

* lhc/lean_text.h - declaration of Lean Text codec incl. output of that 
encoding.
* lhc/word_parser.h - declaration of simple object parser
* lhc_parser/word_markup.h - declaration of Word Markup (XML) codec incl 
output

You can see how the lex and parse activity is managed in codec<T>::decode 
(lhc/codec.h).

The whole process is made much more complex by the requirement for encoding 
independence.
The solution is based on a stack that deals with (top to bottom) I/O of 
objects, buffering strategy
and block device operations. The proper use of codecs is demonstrated in 
load (lhc/codec_object.h).

But maybe your question is about how messages are detected on network 
connections, routed and
dispatched? There is a thread object (lhc/socket_processor.h) that is 
dedicated to the handling of winsock
FD_xxxx events and client winsock calls (listen, connect). It arranges for 
creation of session objects
(lhc/socket_transport.h) that manage actual I/O. These objects are the 
network equivalent of the objects
created by load for reading of flies. Both socket_transport and load 
(actually file_transfer::read_existing)
ultimately call codec_base::decode.

The dispatching of messages once they reach an object is demonstrated in the 
samples, e.g.
sample-t_trip-inter-process-client\trip_controller.cpp.

Does this roadmap help to focus your question?

>
> Note that async is already used by a library under developement 
> https://svn.boost.org/trac/boost/wiki/LibrariesUnderConstruction#Boost.Async

Ah OK. Will check this out (pun unintended).

>
> A last point, to request interest on a library maybe the best could be to 
> put "Request for interest" in the title, and show some motivating use 
> cases.

Yes. Thanks for this. I will try out a few ideas while also considering your 
other points. The level of
interest so far is a concern. Not unexpected but silly to ignore.

Cheers,
Scott