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]>
>> 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
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
>> 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
> 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
> 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?
At application level we operate on PDUs (which are HTTP messages here). No
sockets exposed. All the socket manipulation is done inside HTTP protocol
Here I attached an async protocol layer abstractions I've been using in my
-- Maxim Yegorushkin
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk