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

From: Maxim Yegorushkin (e-maxim_at_[hidden])
Date: 2005-04-14 02:29:08

On Tue, 12 Apr 2005 21:39:24 -0700 (PDT), Don G <dongryphon_at_[hidden]>  
wrote:

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

Rather it's vital.

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

None of the calls should block. Otherwise you won't be able to build  
single threaded applications with select/poll/epoll-based loops.

[]

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

I hope this won't happen. There are several I/O patterns in use out there.

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

Was not Mac OS Classic been buried long ago?

IMO, sockets are abstractions out of the scope of any language. Their  
interfaces can be implemented using any general purpose programming  
language, but still you'll have to call an underlying OS C API. That's a  
fact of life and I don't think this is bad - C is the most portable  
programming language ever.

> A C++ abstraction should replace them.

With this kind of attitude you might end up rewritting the whole world  
you've been living in <g>

>> * On a high level there should be I/O streams support.
>
> I agree again ;)

What kind of streams?

If those are std::iostream's, than that is a bad idea. Binary read/write  
like interface will suffice and can be trivially wrapped in std::streambuf  
-> std::iostream.

[]

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

Here is my two philosophy cents.

You propose another set of concepts over socket concepts just to  
send/receive a bunch of mere bytes. Geez, another glue layer over sockets  
that adds nothing but syntax sugar. Aren't we already tired of software  
bloated from glue layers over glue layers over...? You don't just send  
bytes, rather you execute protocols. Sockets have the right implementation  
level and complexity to build *efficient* protocols upon. Protocol is the  
only glue layer you really always need, the layer that binds your  
application logic with network transport layer (sockets) providing the  
right C++ or whatever interface.

-- 
Maxim Yegorushkin