[boost] Re: [network] An RFC - updated

From: Don G (dongryphon_at_[hidden])
Date: 2005-04-21 23:53:56

Hi Boris,

> on what part of the network library are you working? It
> seems like you are in level 1 without I/O streams -
> whatever this part could be called. :)

If I understand the levels right:

1 - Socket API wrappers (RAII, type-safety mostly;
    minimum overhead)
2 - Connector, Acceptor, Connection
3 - iostream integration

Then, I guess I would place the ideas I proposed at level 1.5 :)

> If I look at the extremes - wrapper classes for the
> C API and an acceptor-connector pattern with service
> handlers like in ACE - where is your library? You are
> somewhere in between if I am right: I don't see any
> socket class but see classes reminding me of network
> functions.

The crux of what I am proposing is a layer that encapsulates sockets
behind an abstraction, which would place it between sockets and
ACE-like designs or whatever else.

Many, but not all, implementations of that abstraction would be based
on sockets, select, epoll, kqueue, etc.. At my work, where this
design was born, we have a direct serial implementation and an
HTTP-tunnel implementation. We have also implemented the stream
abstraction for NT named pipes and SSL (using OpenSSL). By virtue of
the abstract nature of things, we can use SSL over named pipe for
example. Or SSL over serial line (you get the idea<g>).

> Do you think we need another layer?

Personally, I think the layer I proposed is vital to higher level
designs that can be reused (on different platforms or over different
network implementations). Not only designs, but also protocol
libraries.

For example, (if it weren't for proxy servers<g>) the code needed by
an HTTP client to support HTTPS would be something on this order of
complexity:

  void http_get (net::network_ptr net,
                 const net::url & url)
  {
    net::stream_ptr  stream;

    stream = net->new_address(url)->new_stream();
    stream->connect();

    // handle SSL:
    if (url.get_scheme() == "https")
        stream = ssl::new_client_stream(stream);

    // now using SSL - or not!
  }

Lower level ideas (like socket and fd_set) imply an implementation
that may be completely inappropriate. A bidirectional stream is an
idea; it is not a socket.

So, yes, I do think we need this layer or one much like it. And it
must be much lower level than <iostream>. The abstraction I proposed
is a direct rendering of general network concepts (influenced by
TCP/IP, which might mean it needs some further generality). It
imposes only the overhead necessary to adapt sockets to C++ ways of
thinking.

> Shall we drop the acceptor-connector pattern?

I have acceptor in my proposal, but connector didn't seem (to me) to
be an entire class/object. I have an address object as the Abstract
Factory for a stream object, which is similar to a connector concept
except that the connection process begins with a method on the stream
object. In other words, the stream is created in an unconnected state
and it is that stream that we want to connect. This felt like a much
better fit to the problem at hand (again, to me<g>).

> Is your library which belongs to level 1 a neighbour
> of an acceptor-connector based package with different
> goals?

My goal is to iron out a behavior contract that satisfies various
possible and desired implementations, so that a library user can know
what are safe and portable practices. One could say that the sockets
API does this, but there are two central issues: one cannot create a
new type of socket (to layer protocols); not all forms of I/O
completion are portable.

So, underneath my proposal are many implementation choices. Likewise,
on top of it can be abstract ideas about services or request/response
patterns and the like.

The layer is conceptually complete (or should be made so by adding
new abstractions). The only reasons I see for going around the layer
I propose would be: use of platform-specific features or performance.

I believe it is too early for performance conclusions of what I am
proposing. That is a job best left for measurement, which is why I
wanted to proceed with things at SourceForge. I can say that based on
my previous implementation of this design, I know it can perform very
well. Perhaps not as well as some direct-sockets approaches.
Certainly not as well as feeding the network driver directly from the
file system driver's disk cache, but life is full of trade-offs. :)

I hope I have answered your questions.

Best regards,
Don

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com