
Hello, 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 (http://docs.hp.com/en/5992-4578/index.html) to be pretty good.

I'm curious - are you trying to provide an Asio-like abstraction over a native SCTP stack, or provide an SCTP API for OS's that don't provide an SCTP stack (using Asio as part or all of the implementation)? I think this basic goal would determine much of the design. (Providing a full SCTP implementation seems like an ambitious task, while an Asio-like abstraction over a native stack seems much less so.) The HP doc on SCTP is excellent, btw (thanks for the link). How about providing your proposed API (with specifics on how it differs from Asio), then we can provide suggestions on the best way to implement it in conjunction with Asio? Or show code alternatives for the functions / methods you want to extend? (Your option 2 seems like the best way to go, but it's hard to tell without specific details.) Cliff

Cliff, I'm trying to provide an asio abstraction layer over the native SCTP stack, in much the same way as asio currently provides TCP support. At this point the same core API is supported by Linux, FreeBSD, Solaris, HP-UX, etc., and it is being standardized by the IETF, so I think providing a wrapper for this interface is reasonable. Lacking strong opinions favoring just extending the existing classes, I'll provide an implementation based on providing some kind of extension mechanism to the existing socket-related classes. Then we can all decide whether we like it :) -Hal On Wed, 2009-02-25 at 10:28 -0800, Cliff Green wrote:
I'm curious - are you trying to provide an Asio-like abstraction over a native SCTP stack, or provide an SCTP API for OS's that don't provide an SCTP stack (using Asio as part or all of the implementation)? I think this basic goal would determine much of the design. (Providing a full SCTP implementation seems like an ambitious task, while an Asio-like abstraction over a native stack seems much less so.)
The HP doc on SCTP is excellent, btw (thanks for the link).
How about providing your proposed API (with specifics on how it differs from Asio), then we can provide suggestions on the best way to implement it in conjunction with Asio? Or show code alternatives for the functions / methods you want to extend? (Your option 2 seems like the best way to go, but it's hard to tell without specific details.)
Cliff
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
participants (2)
-
Cliff Green
-
Hal Finkel