Re: [boost] [review] Asio formal review.

From: Christopher Kohlhoff (chris_at_[hidden])
Date: 2005-12-22 17:09:41

Hi Jody,

--- Jody Hagins <jody-boost-011304_at_[hidden]> wrote:
> Note that each is good for specific things.  I have tests and
> numbers that show select() and epoll() running circles around
> each other in performance, depending on the way they are used.
> Mixing the different types of use-cases causes both methods to
> degrade.  Thus, I think it is very reasonable to put some
> sockets into a select-based method, and other sockets in an
> epoll-based method.

I guess you must be doing some pretty hard-core networking to be
concerned about this level of detail. Can you describe a use
case that would make such a feature widely useful? Some hard
numbers on performance differences would be quite interesting.

> BTW, I've yet to have time to do a review (I have a major
> deadline Dec 23, then xmas stuff for a few days).
> 
> However, I've tried to follow some of the comments.
> 
> One of my biggest problems with asio, when I tried it several
> months ago, was the poor support for datagram/multicast apps.
> I've seen that you have addressed some concerns (at least
> according to some comments). Could you please specify some
> details of the mcast improvements?

The standard multicast socket options are implemented in the
asio::ipv4::multicast namespace. They are:

  add_membership (IPPROTO_IP/IP_ADD_MEMBERSHIP)
  drop_membership (IPPROTO_IP/IP_DROP_MEMBERSHIP)
  outbound_interface (IPPROTO_IP/IP_MULTICAST_IF)
  time_to_live (IPPROTO_IP/IP_MULTICAST_TTL)
  enable_loopback (IPPROTO_IP/IP_MULTICAST_LOOP)

> Also, the motivation for your own thread implementation is an
> all-header implementation of asio.  Why do you need an
> all-header implementation? In the earlier requirements for a
> boost network library, NOT having an all-header implementation
> was one of the requirements.
> 
> Personally, I do not like all-lheader implementations,
> especially for system related components.  They pull way too
> much junk into the namespace, especially under any flavor of
> Windows (though linux has its own problems there as well).
> Lots of macros, and other junk to pollute and cause problems
> -- not to mention the additional compilation time...
> 
> What's wrong with a library-based implementation?

>From comments, you'll seed that some people prefer header-only
and others don't.

It's on my to-do list to investigate a library implementation,
but this would be an option, not mandatory. The goal of the
library implementation would be to hide away the system headers.

However, a few things need to be considered:

- Much of the library is implemented in templates, so it is
  likely that only the lowest level OS wrappers would be in a
  library.

- I am very concerned that any compilation firewall technique
  used does not introduce additional memory allocations. I am
  not yet sure about the best way to achieve this. Some
  declaration of system types may be required (albeit in a
  namespace), for example.

> While I haven't played, I assume it works under BCB ;-)

Yes, mostly :)

Cheers,
Chris