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

From: Maxim Yegorushkin (e-maxim_at_[hidden])
Date: 2005-04-15 04:30:23

On Thu, 14 Apr 2005 06:27:06 -0700 (PDT), Don G <dongryphon_at_[hidden]>  
wrote:

[]

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

Consider a proxy server for example. It accept a connection and then  
connects to destination. If accept/connect block, it won't be possible to  
handle in one thread multiple clients. But AFAIK performance proxy servers  
are actually single threaded.

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

My experience is opposite.

One of my previous project was a soft realtime VoIP softswitch. It has  
only one thread of execution and is capable of handling 1000+ simultaneous  
calls (2000-4000 sockets). It scales up by just starting additional  
processes on the same box, no recompilation needed, no locking, simple and  
immensely powerful.

[]

>> I hope this won't happen. There are several I/O patterns
>> in use out there.
>
> But, honestly, how many do we need?

This is the main questions. I doubt we can ever answer this. So, I see no  
reason in dictating a style.

[]

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

I see no problem with this. As soon as you cross a compiled library bound  
it does not matter whether it's C or C++ under the hood. You've got a  
binary interface and there is only syntax difference between  
function<void()> and void(*)() + void* callbacks - they both always make  
you allocate. IMO, there is little difference between C and C++ binary  
interfaces.

[]

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

I'm pretty much sure I'm in the minority on this, but the the first two  
things are just noise for me.

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

Try implementing H.323 family. (Although it dies, but it does not die as  
fast as I want it to).

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

Yes, I'm familiar with and used OpenSSL a lot. It exposes a good C object  
model. Would you like to make it expose C++ interface? I doubt that it  
makes any sense, sinse IMO OpenSSL interface is good enough. The same  
point of view I have for sockets.

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

No.

At application level we operate on PDUs (which are HTTP messages here). No  
sockets exposed. All the socket manipulation is done inside HTTP protocol  
library.

Here I attached an async protocol layer abstractions I've been using in my  
current project.

-- 
Maxim Yegorushkin