Re: [boost] asio networking proposal

From: Christopher Kohlhoff (chris_at_[hidden])
Date: 2005-08-18 17:44:33

Hi Thorsten,

--- Thorsten Ottosen <nesotto_at_[hidden]> wrote:
> 1. I hate cryptic short names like
> 
> dgram_socket.
> recv
> 
> why not write datagram and receive?
> (the other short names seems ok and quite standard)

Ok, fair enough :)

> Looking at the Daytime1 example, I wounder why
> 
> 2.
>     asio::ipv4::host host;
>     host_resolver.get_host_by_name(host, argv[1]);
> 
> is not written
> 
>   asio::ipv4::host host =  host_resolver.host_by_name(argv[1]);

Basically for consistency with the rest of the library, in particular:
 
- Consistency with a future asynchronous version of the same function.
As a rule, in async versions of the functions complex structures or
buffers need to be passed as arguments, andthe only difference between
the sync and async functions is the callback handler, i.e.:

  void operation(parameters);

  template <typename Handler>
  void async_operation(parameters, Handler handler);

- Consistency with other functions that take a complex structure
argument (where those functions might need to be member templates and
deduce the argument type, e.g. socket.get_local_endpoint).

> 3. why is everything public in a host?

Only because the host represented data without behaviour, but if a
class with member functions is preferred I can do it that way.

> 4. why does both the stream_socket and the socket_connector need to
>    know about the demuxer? Can't the socket_connector ask the
> stream_socket
> for its demuxer (I want to simplify usage if possible)

This may be moot if asio is changed to use connect/async_connect
functions on the socket itself. What do you think of that change?

However I originally had it this way so that you can have a pool of
demuxers (e.g. one demuxer per CPU) and "load balance" your objects
across them. So you might have one demuxer where all connections are
performed, but once the connection is established the socket is run on
a different demuxer.

> 5. can't socket.recv() use something more highlevel than void* and
> size_t
> arguments?
>     Why not std::vector<char> ? (The same applies to all the
> interface
> functions)

As others have commented, vector<char> can introduce a performance hit
due to default construction of the elements. Also, some applications
need to send data structures directly, to avoid additional copies. So
I'd prefer to keep the operations on the socket class itself using
void*.

However, IMHO the place for supporting high level types is in
non-member functions like asio::send and asio::recv. E.g.

template <typename SyncStream,
          typename InputIterator,
          typename Handler>
size_t send_range(
  SyncStream& s,
  InputIterator begin,
  InputIterator end,
  size_t* total_bytes_sent = 0);

template <typename AsyncStream,
          typename InputIterator,
          typename Handler>
void async_send_range(
  AsyncStream& s,
  InputIterator begin,
  InputIterator end,
  Handler handler);

I believe that it's in these sorts of functions that asio offers the
most extensibility. Would it be useful to add functions like this to
the library itself, and what form should they take?

Cheers,
Chris