Re: [boost] asio networking proposal

From: Mr Minh (m_phanivong_at_[hidden])
Date: 2005-08-18 21:38:30

Chris,
 
how would the iostreams source/sink fit into your design and would you consider using signal/slots to handle the events.
 
Minh

Christopher Kohlhoff <chris_at_[hidden]> wrote:
As discussed in the "surveying async network io libraries" thread, I'd
like to turn asio (asio.sourceforge.net) into a proposal for a boost
networking library. As promised, here is a list of areas where asio
could use some refinement.

I'd appreciate input on:

- What people think of the relative importance of the items. For
example, what would be required for an initial implementation vs
what could or should be left until a later revision.

- Whether the proposed changes are of any value.

- Any other things that should be on the list.

What's Missing
==============

* Asynchronous DNS operations. I think it would be reasonable to say
that any operation that can block should have an asynchronous
equivalent. Should these operations be cancellable (not necessarily
portably implementable anyway)?

* IPv6 support. I have no experience with IPv6, so it would be great
if someone with experience could help out with the design here.

* Asynchronous socket close. In certain circumstances closing a socket
can block, so it would be reasonable to expect an asynchronous close
operation.

* Scatter-gather operations (sendv and recvv).

* The BSD socket functions sendmsg/recvmsg (which I believe are
necessary to support protocols such as SCTP).

* SSL/TLS and DTLS support. This would require an external library,
and how does that fit in with boost?

* Other protocols (PF_UNIX, ...)?

* Some type of integration (or support for) a higher-level
iostreams-based socket library.

* More examples.

* Documentation on design and rationale.

What Should Be Included and What Shouldn't
==========================================

* Obviously asio::thread should not be part of a boost proposal,
since that functionality is already covered by Boost.Thread.

* The asio::time class should probably not be included, and
wherever it's used replaced by Boost.Date-Time.

Naming and Structure
====================

* The use of the word "Stream" can be confusing because its existing
association in C++ with iostreams. Can anyone suggest an
alternative?

* Should stream_socket and dgram_socket be merged into a single socket
class? There other types of sockets (e.g. sequenced packet) that
would require additional classes if the current approach is
retained. This would not be required if the BSD socket APIs were
covered by a single class. Alternatively, should additional classes
be added for the other socket types?

* The current separate socket_connector implementation does not
correspond to an OS resource, unlike socket_acceptor. This can
be problematic, e.g. it prevents a Windows implementation using
ConnectEx, and doesn't allow you to set socket options before the
connection is established. Therefore I propose adding connect and
async_connect operations to socket classes. Should the separate
socket_connector be retained?

* In designing asio I considered that people may want to customise
the demultiplexing strategy associated with each resource. For
example the basic_stream_socket template looks like:

template 
class basic_stream_socket;

where Service is a "facet" of the demuxer that provides
demultiplexing facilities for the socket. The typedef for
stream_socket specifies the Service type based on the target
platform.

However in practice I don't believe this level of customisation is
required (to the best of my knowledge no existing asio user
customises it), particularly if asio uses the "best" demultiplexing
mechanism for each platform. Or another way of looking at it:
developers who need this level of control might not use a general
purpose networking library anyway.

An alternative approach would to have the only template parameter be
an allocator (since there is often memory allocation associated with
asynchronous operations). For example:

template 
class basic_demuxer;

template 
class basic_stream_socket;

where a stream_socket can only be used with a demuxer that has the
same allocator type. The typedefs for demuxer and stream_socket
would just use the default allocator.

Cheers,
Chris

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Minh Phanivong
[phone] (NZ)

"Instead of living in the shadows of yesterday, walk in the light of today and the hope of tomorrow. "

–é’·–²‘½
Send instant messages to your online friends http://uk.messenger.yahoo.com