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

From: Boris (boris_at_[hidden])
Date: 2005-04-13 04:03:58

Don G wrote:
> 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.

The multiplexing interface can be used in a single-threaded application 
while the async stuff will be multi-threaded. There might be network 
developers (like me for example :-) who don't want to synchronize callbacks 
but just want to build the whole application around a blocking call to 
select (or any other multiplexing operation).

> [...]
>> * 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).

Basically I like the idea to have an async I/O library just like 
std::iostreams which supports synchronous I/O. However I don't know how 
difficult it is to implement such a library but isn't POSIX aio exactly 
about this?

> [...]
>> * 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.

Opinions seem to vary on this. When I once proposed to build a C++ network 
abstraction with I/O streams I got complaints that it should be possible to 
use sockets directly in a lower level. Whatever you write the other group 
will join the thread and complain. :)

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

Yes, that's why I am trying to find a design the majority agrees with. If we 
end up with several network libraries implemented by different people noone 
will do the effort to understand and compare design decisions.

> [...]
> 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. ;)

Absolutely, as we can see. :)

Boris