Boost logo

Boost :

Subject: [boost] Extending asio (SCTP support)
From: Hal Finkel (half_at_[hidden])
Date: 2009-02-24 23:15:43


I've started implementing SCTP support in asio. I would like some
feedback on what methodology is preferred. Although I had originally
wanted to provide SCTP support as a pure add-on to the current
framework, unfortunately, I don't think that can be done.

For example, SCTP supports multi-homed endpoints, and the standard API
provides a function sctp_bindx which can add and remove endpoint
addresses from an active association (connection). While I can provide a
subclass of socket_acceptor_service with this extended interface, there
is no way of changing the wrapper (detail::reactive_socket_service) used
to implement socket_acceptor_service's service_impl_type, and since
socket_, protocol_, etc. are private members of
detail::reactive_socket_service, I think that there is no way a subclass
of socket_acceptor_service can access the underlying socket object.

This seems to leave two options:
1. Patch the missing functionality into the existing classes. What
worries me is that this approach does not seem to "scale" well with
respect to the addition of new protocols. (what happens if someone needs
TIPC support, for example).
2. Provide some kind of protocol-specific extension mechanism (templated
base classes for example) for detail::reactive_socket_service and other
such classes so that it is possible to provide protocol-specific
extensions to the base asio interface.

Does anyone have a preference on how I proceed? (or is there an option
I've missed?) And if some extension mechanism is desired, is there a
preference on the technique used for its implementation?

Thank you in advance,
Hal Finkel

P.S. For anyone looking for a quick introduction to SCTP and its
associated socket API, I've found HP's SCTP Programmer's Guide
( to be pretty good.

Boost list run by bdawes at, gregod at, cpdaniel at, john at