[boost] Re: [network] An RFC posted to the sandbox

From: Don G (dongryphon_at_[hidden])
Date: 2005-04-13 09:56:18

Hi Maxim,

Thanks for taking a look. Again, though we disagree more than
agree<g>, I appreciate your input.

Maxim wrote:
> I skimmed through you stuff. It confused me a lot.

Anything specific other than below?

> What kind of applications is that targeted for?
>
> For a heavy duty high performance server you don't
> want to use it, because the abstractions you provide
> do have a price, and I'm not sure about the quality
> of implementation.

That's why it is _open_ source :) The only price I can see that is
absolutely built in, is the overhead of boost::function<> calls vs.
other choices (possibly vanilla virtual or C-style).

> What you need when doing such a server is to stick
> close to the metal, not paying for (I'm pretty sure
> you know that) useless context switches, lock
> contention, memory allocations and data copies.

That's why in my proposal, callbacks are made from the I/O threads.
There is no context switch. Locks are minimally contended because a
given object is managed entirely by one thread. There is no buffering
provided; data is read directly into the buffer you would supply.

That leaves memory allocation. In the current proposal, that is the
realm of boost::function<>. I have not looked at the internals to
know whether or not a copy of a boost::function<> requires memory
allocation (which would be very unfortunate for such a facility). If
it does, it may mean hashing over that topic with the
boost::function<> author(s) :) Otherwise, there need be no additional
memory allocation.

> One really don't care about Linux/Windoze portability
> for this kind of servers just because Windoze is not
> an option for it's poor network performance and inherent
> security breaches.

That totally depends on the nature of your application. If you want
to sell it to customers, some will want to run it on Windows 2003
Server. In my book, if possible, I would want to support as many
possible target platforms as I can. The performance is up to the
system of choice.

> For a simple portable application one would probably
> stick to BSD nonblocking sockets + select() or blocking
> sockets + threads. The resulting code size will
> probably close to that of the code using your stuff, but
> code transparency and complexity will be in favor of the
> former for sure.

I guess we will have to agree to disagree. Those API's are C. The
first thing a C++ programmers does (I have seen it many times), is
write a C++ wrapper over it. This is done with varying degrees of
skill and completeness. If you have looked at the examples I posted,
you can see how much simpler the use cases are than programming
directly to sockets. For example:

   stream_ptr strm;
   strm = net->new_address("http://www.boost.org")->new_stream();
   strm->connect();

Compared to ...

   ... just kidding (no room<g>)

> Aside from this, I'm rather skeptical about the library
> you are working on guys. IMO, the root of all problems
> and complexity is its intended portability.

Indeed, portability is a major issue.

> The target platforms' APIs are too different to make
> implementation efficient and usable for any kind serious
> network application.

Again, I disagree, and not based on philosophy. The abstraction I
proposed can be _very_ efficient. It has minimal "built in" cost,
with the biggest variable being boost::function<>. In my
implementation at work, we use our own boost::function-like mechanism
and we ensure no deep copies are made.

The efficiency will approach the limit of the host OS, with extra
overhead as we explored above. That overhead will eventually need to
be measured and optimized. At present, I am not concerned with it.

> If M$ does not care about its network APIs portability,
> why would anyone else care about it?

Because there are potential customers out there that run Windows? ;)

Best regards,
Don

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