[boost] Re: Network library: What we have until now

From: Don G (dongryphon_at_[hidden])
Date: 2005-04-12 23:39:24

Hi Boris,

> I updated 
>
http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostNet
> to document why what decisions were made.
> We have until now:

> * The network library should support four I/O models
> which are known to many programmers as blocking,
> non-blocking, multiplexing and asynchronous.

Personally, I don't think the multiplexing interface is appropriate
or necessary. Essentially the same style can be achieved with
multi-threaded async and a boos::function queueing solution. In other
words, it is not a group of network objects that is being
manipulated. It is a portable dispatcher that gets
boost::function<>'s queued to it. It therefore suffers none of the
portability issues that a direct wrapper to select would have.

I also believe that non-blocking is an I/O only thing; it is not
needed for connect or accept.

> * It should be possible to switch between I/O models at
> runtime (which means you have one socket class supporting
> all I/O models instead of different socket classes each
> of them supporting only one I/O model).

Perhaps "switch" isn't the best term. On a per-operation basis, the
user should chose between styles.

> * There should be an asynchronous I/O library as other
> libraries might want to do asynchronous I/O, too.

I don't see this as practical. There is no such thing as async I/O
that can be portably described. This means that each kind of async
object has to provide the right implementation. Perhaps the scope of
portability needs to be stated and agreed upon. When I implemented
async pipe I/O on Windows NT/9x, I could not use the same code for
I/O as I did with sockets or as I would for files (subtle
differences).

I think a common pattern for async behavior should be agreed upon and
if some implementation details turn out to be reusable, that's a good
happenstance. My prediction is that on Unix platforms, there will be
more to reuse between sockets, pipes, files, etc.. On Windows, there
will be little.

> * There should be an asynchronous design pattern which
> should be used by all Boost libraries which support
> asynchronous operations.

I agree completely on this one :)

> * On a low level the network library should be close to
> what is known as Berkeley sockets to many programmers.

I think sockets should be hidden. They are not universally used, for
example Mac OS9 doesn't and I just assume others exist. They don't
have any magical powers; they are just a C abstraction. A C++
abstraction should replace them.

> * On a high level there should be I/O streams support.

I agree again ;)

> As far as I can see from all the discussions that's
> what we agree on. There have been some ideas like
> event handlers and dispatchers but I am not sure 
> where to put them - have a look at
> http://www.highscore.de/boost/net/packages.png
> please (which is also in the Wiki page). This is the
> overall architecture of the network library. If you
> want me to change or add something please tell me.

We have a couple straw men started (Michel's and mine). Perhaps it is
just as good to start just throwing darts at them? I could probably
have a full implementation of the interfaces I propose in a small
number of weeks (2-3). Having done it once before really helps<g>,
but I wanted to get to some common ground on the philosophy before
going to that step.

The philosophy I have on this may be out of sync with some (pun
intended), but IMHO, we need to hash over the philosophy as much as
anything. We have a lot of folks that are very comfortable with the
sockets interface, but I don't believe that exposing its
idiosyncrasies is the right approach. Everyone that writes sockets
code runs into the same problems, and solves them in varying degrees
of sophistication and completeness. A robust solution is not as
difficult as some might think. It's certainly easier than getting
agreement on philosophical matters. ;)

Best regards,
Don

                
__________________________________ 
Do you Yahoo!? 
Yahoo! Small Business - Try our new resources site!
http://smallbusiness.yahoo.com/resources/