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

From: Don G (dongryphon_at_[hidden])
Date: 2005-04-14 08:27:06

Hi Maxim,

> Don G wrote:
>> Personally, I don't think the multiplexing interface
>> is appropriate or necessary.
>
> Rather it's vital.

I agree that it is vital to use such a mechanism internally, but I
see no reason (other than preference) to expose the grouping of
connections to the user.

> None of the calls should block.

But the sync ones _must_ block. All of the logical operations can be
invoked sync/async. The non-blocking approach, from my definition<g>,
is like this:

- try the operation
- get back a "would block" state
- flag interest in change to "won't block"
- wait for the state to arrive
- repeat the operation (it won't block)

I think this has a place for I/O, but not for connect/accept. These
are binary steps whereas I/O can be viewed as a continuous march to
completion.

> Otherwise you won't be able to build single threaded
> applications with select/poll/epoll-based loops.

One can write in a single threaded style using what I am proposing,
but it is not, IMHO, the way to go for optimal performance. What I am
suggesting is that this style can be achieved by not basing the main
loop on select/et.al.. Those API's will be used internally. Things
like the Windows limit on connections/select and leverage of multiple
CPU's would be details.

This will not be the solution for _everyone_. But, I believe it will
go a lot farther than you might think.

[]

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

But, honestly, how many do we need? I think all that we need is a way
to achieve concurrent operations in C++. One technique would satisfy
this. It would have advantage of allowing different libraries to
communicate, as each would not be using an incompatible style.

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

Hopefully :) It was offered as an existence proof. There is more to
the world than Unix and Windows.

> IMO, sockets are abstractions out of the scope of any
> language.

But they are realized as a C artifact. They were born as a C library.
They are not sacred :)

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

Yes, C is portable. C++ is also. I will resist the C vs. C++ debate.

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

Actually, I believe that is the point. Sometimes (often) these are
just C++ facades over C libraries, but C++ offers a different idiom
that many find attractive for various reasons. This is especially
true when the C interface is as tedious as sockets. Whitness the
level of interest in this topic. :)

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

Not "just". It is to handle life-cycle safely, type safe control
flow, non-portable aspects of sockets, to name a few.

> You don't just send bytes, rather you execute
> protocols. Sockets have the right implementation
> level and complexity to build *efficient*
> protocols upon.

How hard should it be to write a protocol? How reusable should it be?
Have you ever tried to use, say, OpenSSL? Everyone that wants to
write a protocol today must grapple with these issues and all they
have to begin with is a concrete API for sockets. But that is a
bottom-only facility. Just try to expose SSL as a socket to your
user!

FWIW, openssl exposed their protocol implementation in a generic way
so as not to tie one to sockets. That is, they created a C I/O
mechanism (BIO's) that are unique to it.

A C++ version could be written to use the net::stream I proposed and
_be_ a net::stream implementation. Thanks to the BIO interface of
OpenSSL, this could also be done using that library.

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

So, let's say we have an HTTP library. How do we wait for responses?
Expose the socket(s) it uses? I think the async pattern we are
talking about is the right answer.

Best regards,
Don

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